我注意到我的谷歌应用程序域的一个奇怪的行为。 大部分邮件都像你所期望的那样通过，但是经过一段时间，我发现某些发件人的邮件没有通过。 在确定一个这样的发件人，邮件不通过，我已经请他给我发一封电子邮件，并转发“传递失败” – 回应我的常规Gmail。
传递失败响应包含以下片段：
—–会议logging如下—–
<[email protected]>…延迟：连接超时与ghs.l.google.com。
这帮助我通过快速search来识别问题，并将其引导至Google Apps帮助论坛上的此页面 。 事实上，我查看了我的域名的DNSlogging， @被设置为ghs.google.com。 （CNAME），它不应该。 将其更改为@ 74.125.93.121 (A) *解决了问题。
我知道，在邮件无法通过的情况下，我的域名被CNAME查找的规范名称替代，因此邮件被发送到[email protected]而不是[email protected] 。 但是，为什么它对绝大多数发件人都有效？ 发件人的邮件不通过，使用一些不同types的邮件协议，一些奇怪的DNS设置，或者它可能是什么？
通过研究谷歌的问题，我可以看到，这似乎是一个广泛的问题（很多人抱怨战网的电子邮件没有通过，将是一个stream行的例子），只是人们似乎并不要知道问题出在他们自己的DNS设置上，而不是在发件人那边。
那么如何解释呢？
*我使用这个知识产权，因为我在这里读到，但我认为任何知识产权都可以做到这一点。 任何人都可以确认吗？ 请注意，仅仅删除@logging不能解决问题，必须更改。
从RFC 2821“简单邮件传输协议”，第5节“地址parsing和邮件处理”：
查找首先尝试查找与该名称关联的MXlogging。 如果findCNAMElogging，则会将结果名称处理为初始名称。
一般来说，这就是CNAME的工作原理。 他们经常被误用，误解和错误执行。 🙂
如果您的域是example.com，那么您现在可能已有MXlogging指向通常的Google Apps主机。
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.
第3.6.2节“别名和规范名称”中的RFC 1034“域名概念和设施”规定：
如果CNAME RR存在于一个节点上，则不应该存在其他数据。 这确保了规范名称和别名的数据不能不同。
在发生错误时，发送端的邮件服务器和/或DNS服务器尝试为您的域名example.com查找MXlogging，并find指向ghs.l.google的CNAME。 COM。 然后尝试查找ghs.l.google.com的MXlogging。 该域名目前没有任何MXlogging，因此邮件服务器将会login到ghs.l.google.com的Alogging。 该IP地址未在SMTP端口上侦听，所以导致错误“与ghs.l.google.com连接超时”。
通过删除CNAMElogging，您已经解决了邮件问题。 如果您在Google地址上定义的IP地址发生更改，则可能会遇到问题。
您可以改为为www.example.com定义cname：
www.example.com. CNAME ghs.l.google.com.
然后在你指向example.com的任何IP上运行一个小型的networking服务器，它只需要一个HTTPredirect到http://www.example.com/
它的效果和它的效果一样有些令人惊讶。 我相信Postel的法律在那里得到一些信用。 🙂
回到RFC 1034 2.6.2：
CNAME RR在DNS软件中引起特殊的操作。 当名称服务器在与域名相关的资源集中找不到所需的RR时，它会检查资源集是否包含具有匹配类的CNAMElogging。 如果是这样，则名称服务器在响应中包含CNAMElogging，并以CNAMElogging的数据字段中指定的域名重新启动查询。 这个规则的一个例外是匹配CNAMEtypes的查询不会重新启动。
因此，在这种情况下，可能会认为DNS服务器将不应该跟随MX查找的CNAME，除非找不到MXlogging。
发送邮件时，Sendmail和qmail（以及其他人）默认会尝试将电子邮件地址右侧使用的CNAME重写为规范名称。
事实上，一些网站依赖于这种行为。 djb详细说明了为什么他认为人们应该停止在他的“邮件中的CNAMElogging”文件中依靠它。
BINDlogging中的@符号只是写入域的简写方式。 如果你正在为example.com创build一个logging，那么@就是example.com一个别名。 说@logging必须是一个知识产权是一个缺less重要信息的声明 – 你没有告诉我们是什么types的logging。
从发送报告看来，您似乎可能已经对您的DNS做了一些事情，导致远程邮件服务器将您的域名重写为ghs.l.google.com – 非常奇怪（PS，Alogging必须是IP，CNAMElogging不得是IP或其他CNAMElogging）。
为什么这个人邮件服务器重写你的地址是奇怪的 – 它不应该除非该人做了一些明确的告诉它重写它。 除非找不到任何MXlogging，否则它也不应该关心域的IP是什么，因为MXlogging是邮件服务器如何确定邮件的去向。
鉴于提供的信息非常less，在我看来，您没有按照谷歌关于如何正确configurationDNS电子邮件的说明。 您的区域文件甚至可能有一些错误 – 让他们由有能力的区域pipe理员检查。