由于DNS配置，未从某些发件人接收邮件

我已经注意到我的Google Apps域的异常行为。大多数邮件都按您期望的那样通过，但是经过一段时间，我得出的结论是某些发件人的邮件没有通过。确定了这样的发件人后，他们的邮件不会通过，我要求他尝试向我发送电子邮件，并将“传递失败”响应转发给我的常规gmail。

交付失败响应包含以下代码段：

-----会话记录如下：-----
<myusername@GHS.L.GOOGLE.COM>...推迟：ghs.l.google.com的连接超时。

通过快速搜索，这帮助我发现了问题，这使我进入了Google Apps帮助论坛上的此页面。实际上，我检查了我的域的DNS记录，并将@其设置为ghs.google.com。（CNAME），不应该这样。将其更改为@ 74.125.93.121 (A)*可解决问题。

我了解在邮件无法通过的情况下，我的域名通过CNAME查找被其规范名称替换，因此邮件被发送到myusername@ghs.l.google.com而不是myusername@mydomain.com。但是，为什么它对绝大多数发件人有效？发送邮件不会通过的发件人是否使用了某种不同的邮件协议，一些奇怪的DNS设置，或者可能是什么？

从我在Google上研究该问题所看到的情况来看，这似乎是一个广泛存在的问题（很多人抱怨来自Battle.net的电子邮件没有通过，这将是一个受欢迎的例子），只是人们似乎并没有请注意，问题出在他们自己的DNS设置上，而不是发件人一方。

那么如何解释呢？

^{*我使用此IP的原因是我在这里阅读的内容，但我认为任何IP都可以解决问题。有人可以确认吗？请注意，仅删除@记录并不能解决问题，必须对其进行更改。}

从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的CNAME。 com。然后，它尝试查找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/

它工作得如此出色有点令人惊讶。我相信，波斯特尔定律在那里可以得到一些认可。:-)

返回RFC 1034 2.6.2：

CNAME RR在DNS软件中引起特殊动作。当名称服务器无法在与域名相关联的资源集中找到所需的RR时，它将检查资源集是否包含具有匹配类的CNAME记录。如果是这样，则名称服务器将在响应中包括CNAME记录，并以CNAME记录的数据字段中指定的域名重新启动查询。此规则的一个例外是，不会重新启动与CNAME类型匹配的查询。

因此，在这种情况下，可能会争辩说，除非未找到MX记录，否则DNS服务器将/不应在MX查找上遵循CNAME。

发送邮件时，默认情况下，Sendmail和qmail（可能还有其他）会尝试将电子邮件地址右侧使用的所有CNAME重写为规范名称。

确实，某些站点依赖此行为。djb在他的“邮件中的CNAME记录”文档中详细说明了为什么他认为人们应该停止依赖它。

@BIND记录中的符号只是编写域的一种简便方法。如果您要为创建记录example.com，则@仅仅是的别名example.com。说@记录必须是IP就是说缺少关键信息的声明-您没有告诉我们记录的类型。

从送达报告中，您似乎可能对DNS做了一些操作，导致远程邮件服务器将您的域重写为ghs.l.google.com-非常奇怪（PS，A记录必须是IP，CNAME记录一定不能是IP或其他CNAME记录）。

那个人的邮件服务器为什么要重写您的地址，这很奇怪-除非那个人做了一些明确地告诉它重写的操作，否则应该不会。除非找不到任何MX记录，否则它也不应该在乎您域的IP，因为MX记录是邮件服务器确定邮件去向的方式。

在我看来，鉴于所提供的信息很少，您根本就没有按照Google的说明来正确配置电子邮件的DNS。您的区域文件中甚至可能存在一些错误-由合格的区域管理员对它们进行检查。