IETF RFC 7505描述了明确不应该接收电子邮件的域/主机的MXlogging。 这是通过将MX指向域名系统根目录来完成的。 例如，
nomail.example.com. 86400 IN MX 0 "." 为什么这需要？ 根据我的理解，通过使用顶级域名（TLD） invalid域名可以得到明确的驳回。 例如，
nomail.example.com. 86400 IN MX 0 "spam.invalid." nomail.example.com. 86400 IN MX 10 "null.invalid."
我看到，RFC 2782，DNS SRV同样规定了“A的目标”。 意味着该服务在这个领域决定不可用。“ 所以我想我的问题是：
为什么我们应该使用DNS根意味着“不可用” invalid已经提供这个function？
因为这不是你应该使用。 .invalid的。 就像。 .example它是为了本地testing和文档。
另外，使用.invalid仍然会导致额外的事情发生 – 在邮件服务器上进行额外的DNS查找和排队，以便重试一次。
使用"." 格式应该导致立即严重失败。 导致MTA立即停止尝试交付。 至less这就是RFC的介绍。
整个问题涉及到几个不同的方面，都需要考虑到为什么RFC7505增加了一些有用的东西。
首先，关于如何进行邮件递送的RFC7505之前的定义没有办法清楚地表明不应该为具有地址logging的名称进行邮件递送尝试。
从RFC7505第1节 ：
SMTP客户端具有规定的序列，用于标识接受域的电子邮件的服务器。 [RFC5321]的第5部分详细介绍了这一点。 本质上，SMTP客户端首先查找一个DNS MX RR，如果没有find，则返回查找DNS A或AAAA RR。 因此，这将使用电子邮件服务语义重载DNSlogging（具有不同的主要任务）。
如果某个域没有MXlogging，发件人将尝试将邮件传递到域A或AAAAlogging中地址的主机。 如果A / AAAA地址上没有SMTP侦听器，则在发送邮件传输代理（MTA）放弃之前，邮件传递将长时间（通常为一周）反复尝试。 这会在发送错误的邮件的情况下延迟通知给发件人，并且会消耗发件人的资源。
本文档定义了一个null MX，它将使所有向域的邮件传递尝试立即失败，而不需要域创build专门用于阻止传递尝试的SMTP侦听器。
然后是RFC7505如何实现这个（ IN MX 0 . ）。
从RFC7505第3节 ：
MX资源logging指定空MX
为了表明一个域不接受电子邮件，它通过一个包含首选号码0和长度为零的标签的RDATA部分来通告一个MX RR（参见[RFC1035]的第3.3.9节），在主文件中写为“”。 “作为交换域，表示域中不存在邮件交换器。 由于“。” 不是有效的主机名，空的MXlogging不能与普通的MXlogging混淆。 指某东西的用途 ”。” 作为伪主机名，意味着没有可用的服务在SRV RR [ RFC2782 ]上build模，其具有类似的含义。
发布null MX的域必须不通告任何其他MX RR。
（强调加）
如此处所述，“null MX”的实现细节基于来自SRV RRtypes的已经build立的模式。 这样做是有道理的，因为SRV RRtypes或多或less是MX RRtypes的通用版本。
所以，这个决定基本上是在定义SRV RRtypes时已经采用的。
那么，为什么不使用.invalid呢？
从RFC2606第2节 ：
“.invalid”意在用于在线构build一定会无效的域名，而且一目了然的域名无效。
从这里可以看出，这个保留的TLD是供人类消费的。 在软件中没有定义特殊处理的先例。
当然，它可能已经以某种不同的方式实施，但他们select了最小的使用方法. ，这不是一个有效的主机名，因此不会干扰正常的使用。