我的网站托管在一个位置,也在接受电子邮件的服务器上,我使用Google Apps for mail作为我的电子邮件提供商.在过去的18个月里我没有遇到任何问题,也没有关于电子邮件丢失的报道.

然而,本周,使用Hotmail的人试图通过电子邮件发送给我.他们发送的电子邮件中有25-50％会返回给他们,并显示“550 relay relay allow”消息.

我的MX记录是正确的,并检查我的Web服务器上的Exim日志我发现Hotmail正在尝试将电子邮件发送到A记录,因为此服务器可以接受电子邮件.这似乎是一个known problem与Hotmail.

由于我无法禁止网络服务器接受来自Hotmail的邮件(因为其他人使用网络服务器作为他们的电子邮件托管),是否有解决方案？

Hotmail无法使用正确的DNS规则. Hotmail将始终首先尝试传递到域的A记录,并忽略MX记录.如果域A记录接受连接(例如,它运行邮件服务器),它将尝试传递电子邮件,如果网络服务器和邮件服务器是同一个盒子,在大多数情况下这将不会成为问题.

但是,如果域使用不同的邮件服务器,Hotmail仍会尝试将邮件传递到域的A记录.如果机器提供550 Relay拒绝,Hotmail将无法发送邮件.它不会尝试域的MX记录.

只能解决防火墙端口25,因此Hotmail无法连接到您的端口25.如果失败,hotmail将尝试解析MX记录.

多年来这一直是个问题,但Hotmail一无所知.

我的DNS区域中有以下配置.我想将@记录切换到不同的IP地址,但我希望保持MX记录不变.请注意,IP地址已更改为76.13.141.185以保护隐私.

所以,我想知道的是,我可以改变那么@ record然后
我可以将MX条目主机从@更改为76.13.141.185吗？

我想知道因为当我使用http://www.mxtoolbox.com/并对同一服务器上的其他域进行MX查找时,它会给我4个不同的IP地址,其中没有一个与当前的@ record的IP地址相匹配.

那么我应该将MX部分更改为这样吗？

MX条目指定要将电子邮件发送到特定域的联系服务器. “@”表示基本域,而不是ip地址.

MX记录与同一域的A记录无关,它们是完全独立的.因此,如果您更改“@”的A记录,它通常不会影响任何MX记录.

但是如果你在MX记录中将“@”更改为1.2.3.4,这意味着它指向的服务器(例如mx1)将用于发送发送到something@1.2.3.4而不是发送到something@your.domain的电子邮件.我认为没有必要这样做,它可能根本不起作用.

我正在构建一个应用程序,每个客户都可以拥有自己的子域.
在这个例子中,他将他的子域设置为：威士忌

我在DNS中创建了一个通配符子域：
* .myapp.com A 123.123.123.123

所以当他访问我的webapp时,他会使用url：whisky.myapp.com,它将解析为123.123.123.123.

我的应用程序还使用我的客户选择的相同子域发送电子邮件(电子邮件将由sendgrid处理)：例如customer@whisky.myapp.com

但是当我尝试为sendgrid的服务器设置通配符MX记录时,我的DNS提供商不允许我这样做,理由是违反了一些标准.

例如* .myapp.com MX sendgrid.com

有什么方法可以为两者都有通配符子域名吗？

RFC1912明确承认存在通配符MX记录,但警告说

A wildcard MX will apply only to names in the zone which aren’t listed in the DNS at all.

RFC4592是一个标准跟踪RFC,它阐明了MX通配符的存在(参见2.2.1节中的示例).我很确定你的DNS提供商充满了它.

我可以想象一些DNS软件也遇到问题,或者因为他们根本不支持通配符MX记录,或者因为他们把“没有其他记录”的东西太字面化并且不允许两个通配符MX和通配符A.这个软件不符合标准,但运气好了.

考虑到客户注册时自动设置DNS记录是多么微不足道(或者应该如此),我会完全跳过通配符,让您的应用为每个客户配置DNS记录.

我有几条A记录,如下：

Subdomain             IP Address
example.example.com   198.51.100.0
example.com           203.0.113.0

并且CNAME记录如下所示：

Alias              Destination
www.example.com    example.com

我想让example.com抛出301重定向到www.example.com.

所以我将最后的A记录更改为：

www.example.com       203.0.113.0

并交换CNAME记录中的两个URL,如下所示：

example.com        www.example.com

问题：此更改是否会使example.example.com解析为203.0.113.0而不是198.51.100.0？

如果您有example.foo.com的A记录,则任何其他域的DNS记录都不会影响该记录.所以答案是否定的.

其他要记住的事实：

您不能拥有同一个完全限定域的CNAME和A记录

CNAME与301重定向不同.CNAME将返回与新域相同的IP地址.您的浏览器将转到该IP请求原始域.301重定向将导致您的浏览器对新域进行DNS查找,然后去询问新域.

我们在AWS上有许多服务器组,它们使用三个服务器来提供站点服务.每个服务器或一组服务器位于不同的可用区域内,其中一个是重定向服务器,而另外两个是在弹性负载平衡器后面访问的主服务器.我们最终有一个客户使用Route53,并在弹性负载平衡中查找指向区域顶点域的一些细节.支持此功能的大多数DNS提供商似乎将此称为A记录的DNS别名.然而,有些网站似乎引用了一个名为ANAME记录的类似记录.这不是典型的CNAME,也不是非典型的DNAME记录.这些网站中的大多数还会返回使用它的DNSMadeEasy simplednS.

那么Route53(或其他地方)A记录ALIASes和ANAME记录之间有什么区别？有吗？这些中的任何一个是否已包含在IEFT RFC实现文档中,或者是否包含在所使用的提供程序中实现的别名记录？

[编辑]：为ANAME使用列出了错误的DNS提供商

看起来ANAME只是由 DNS Made Easy组成的标准名称,用于描述他们的服务,与Route 53 Alias的功能非常相似.

我在Stack Overflow最近描述了Alias和CNAME之间的差异,但总结一下：

为给定主机配置了CNAME的DNS服务器发出一个引用,指示正在查找的主机的规范名称,通常需要原始解析器进行第二次查询以查找该备用名称;别名(以及它的外观,ANAME)使用DNS服务器知道的“真实”目的地的内部信息,直接简单地响应请求,而不需要第二次查找,也不需要任何中间信息的可见性. DNS协议交换.

除此之外,Alias提供的功能是能够使用Route 53拥有的有关S3网站端点,ELB和Cloudfront的当前有效IP地址的信息,以响应具有权威信息的A记录查询.近乎实时的准确性,如果您使用这些服务,则不是任何其他提供商可以使用的;当然,情况恰恰相反,Route 53 Alias不能用于查找和返回Route 53本身不具备的信息.您不能只使用“任何”目标作为别名 – 只有我在上面提到的三种服务的端点,或者在Route 53内的同一托管区域中的其他记录.

从这个意义上讲,ANAME和Alias不等效,具体取决于提供后端的服务…除非ANAME指向(内部)静态信息.

如果目标是S3,ELB或CloudFront,则另一个DNS主机服务上的ANAME记录将无法提供与Route 53相同的功能,就像Route 53上的Alias无法返回指向的路径一样另一个CDN提供商的边缘位置使用内部可用信息,因为提供商的基础设施内部无法获得这些信息.否则功能似乎大致相同.