我注意到我的 Google 应用域的行为有些奇怪。大多数邮件都按预期发送，但一段时间后我发现，来自肯定发件人无法送达。在确定了一位这样的发件人（其邮件无法送达）后，我要求他尝试给我发送电子邮件并将“送达失败”响应转发到我的常用 Gmail。
投递失败响应包含以下片段：
----- 会话记录如下 ----- ... 延期：与 ghs.l.google.com 的连接超时。
<[email protected]>
通过快速搜索，我找到了问题所在这一页在 Google Apps 帮助论坛上。事实上，我检查了我的域名的 DNS 记录，它@被设置为 ghs.google.com。（CNAME），它不应该是这样的。将其更改为@ 74.125.93.121 (A)* 解决了问题。
我理解，在邮件无法送达的情况下，我的域名会通过 CNAME 查找被其规范名称替换，因此邮件会发送至[email protected]而不是[email protected]。但为什么它对绝大多数发件人都有效呢？邮件无法送达的发件人是否使用了不同类型的邮件协议、某些奇怪的 DNS 设置，或者其他什么原因？
从我在 google 上研究该问题的结果来看，这似乎是一个普遍存在的问题（很多人抱怨 battle.net 的电子邮件无法发送，就是一个常见的例子），只是人们似乎没有意识到问题出在他们自己的 DNS 设置上，而不是发件人方面。
那么这该如何解释呢？
* 我使用这个 IP 是因为我读到这里，但我认为任何 IP 都可以解决问题。有人可以证实这一点吗？请注意，简单地删除记录@并不能解决问题，必须进行更改。
答案1
摘自 RFC 2821“简单邮件传输协议”，第 5 节“地址解析和邮件处理”：
查找过程首先尝试查找与名称关联的 MX 记录。如果找到的是 CNAME 记录，则将结果名称作为初始名称进行处理。
总体而言，CNAME 的工作方式如下。它们经常被误用、误解和错误实施。:-)
如果您的域名是 example.com，您可能已经有指向常用 Google Apps 主机的 MX 记录。
example.com. MX 10 ASPMX.L.GOOGLE.COM.
example.com. MX 20 ALT1.ASPMX.L.GOOGLE.COM.
example.com. MX 20 ALT2.ASPMX.L.GOOGLE.COM.
example.com. MX 30 ASPMX2.GOOGLEMAIL.COM.
example.com. MX 30 ASPMX3.GOOGLMAILE.COM.
example.com. MX 30 ASPMX4.GOOGLEMAIL.COM.
example.com. MX 30 ASPMX5.GOOGLEMAIL.COM.
听起来你也有一个这样的条目：
example.com. CNAME ghs.l.google.com.
RFC 1034“域概念和设施”在第 3.6.2 节“别名和规范名称”中指出不要采用这种配置：
如果节点上存在 CNAME RR，则不应存在其他数据；这确保了规范名称和其别名的数据不会有所不同。
就您粘贴的错误而言，发送端的邮件服务器和/或 DNS 服务器尝试查找您的域 example.com 的 MX 记录，并找到指向 ghs.l.google.com 的 CNAME。然后，它尝试查找 ghs.l.google.com 的 MX 记录。该域目前没有任何 MX 记录，因此邮件服务器将转到 ghs.l.google.com 的 A 记录。该 IP 地址未在 SMTP 端口上监听，因此结果为错误“与 ghs.l.google.com 的连接超时。”
通过删除 CNAME 记录，您已修复邮件问题。如果您在其位置定义的 IP 地址在 Google 端发生更改，您可能会遇到问题。
您可以改为定义 www.example.com 的 cname：
www.example.com. CNAME ghs.l.google.com.
并在你指向 example.com 的任何 IP 上运行一个小型网络服务器，它只是简单地将 HTTP 重定向到http://www.example.com/
令人惊讶的是，它竟然能发挥如此大的作用。我认为 Postel 定律在这方面也发挥了一定作用。:-)
回到RFC 1034 2.6.2：
CNAME RR 会导致 DNS 软件采取特殊措施。当名称服务器无法在与域名关联的资源集中找到所需的 RR 时，它会检查资源集是否包含具有匹配类的 CNAME 记录。如果是，名称服务器会在响应中包含 CNAME 记录，并在 CNAME 记录的数据字段中指定的域名处重新启动查询。此规则的一个例外是，与 CNAME 类型匹配的查询不会重新启动。
因此，在这种情况下，可以说 DNS 服务器不会/不应该在 MX 查找中遵循 CNAME，除非没有找到 MX 记录。
发送邮件时，Sendmail 和 qmail（以及其他邮件）将默认尝试将电子邮件地址右侧使用的任何 CNAME 重写为规范名称。
确实，有些网站依赖这种行为。djb 在他的文章中详细阐述了为什么他认为人们应该停止依赖它。“邮件中的 CNAME 记录”文档。
答案2
BIND 记录中的符号@只是域名的简写方式。如果您要为 创建一个记录example.com，那么@只是 的一个别名example.com。说@记录必须是 IP 的说法缺少关键信息 - 您没有告诉我们它是什么类型的记录。
从投递报告来看，你可能对 DNS 做了一些操作，导致远程邮件服务器将你的域名重写为 ghs.l.google.com - 非常奇怪（PS，A 记录必须是 IP，是 CNAME 记录必须不是 IP 或其他 CNAME 记录）。
那个人的邮件服务器为什么要重写您的地址很奇怪 - 除非那个人做了一些明确告诉它重写地址的事情，否则它不应该这样做。除非它找不到任何 MX 记录，否则它根本不应该关心您的域的 IP 是什么，因为 MX 记录是邮件服务器确定邮件去向的方式。
鉴于提供的信息非常少，我感觉您根本没有遵循 Google 的说明来正确配置电子邮件的 DNS。您的区域文件中可能甚至存在一些错误 - 请有能力的区域管理员检查一下。