為什麼需要 RFC 7505（Null MX）？
IETF RFC 7505描述了明確不應接收電子郵件的域/主機的 MX 記錄。這是通過將 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，同樣指定了“‘的目標’。意味著該服務在此域中絕對不可用。” 所以我想我的問題是：
既然已經提供了這個功能，為什麼還要使用 DNS 根來表示“不可用”
invalid？
因為那不是你應該使用
.invalid的。就像.example它用於本地測試和文件一樣。此外，使用
.invalid仍然會導致其他事情發生 - 額外的 DNS 查找和郵件伺服器上的排隊以重試我的頭頂上的一個。使用該
"."格式應該會導致立即發生硬故障。導致 MTA 立即停止嘗試傳遞。至少 RFC 的介紹是這樣讀的。
整個問題涉及幾個不同的方面，都需要考慮這些方面來回答為什麼 RFC7505 添加了一些有用的東西。
首先，RFC7505 之前關於應該如何進行郵件傳遞的定義沒有辦法清楚地表明不應為具有地址記錄的名稱進行任何郵件傳遞嘗試。 從RFC7505 第 1 節：
SMTP 客戶端具有指定的序列，用於辨識接受域電子郵件的伺服器。第 5 節
$$ RFC5321 $$詳細介紹了這一點；實質上，SMTP 客戶端首先查找 DNS MX RR，如果未找到，則返回查找 DNS A 或 AAAA RR。因此，這會使具有電子郵件服務語義的 DNS 記錄（具有不同的主要任務）過載。 如果域沒有 MX 記錄，發件人將嘗試將郵件傳遞到域的 A 或 AAAA 記錄中地址的主機。如果 A/AAAA 地址上沒有 SMTP 偵聽器，則在發送郵件傳輸代理 (MTA) 放棄之前，將在很長一段時間內重複嘗試郵件傳遞，通常是一周。這將在發送錯誤郵件的情況下延遲通知發件人，並將消耗發件人的資源。
本文件定義了一個空 MX，它將導致向域的所有郵件傳遞嘗試立即失敗，而無需域創建專用於阻止傳遞嘗試的 SMTP 偵聽器。
然後是 RFC7505 如何實現這一點的問題（
IN MX 0 .）。
- 指定空 MX 的 MX 資源記錄
為了表明一個域不接受電子郵件，它會通告一個 MX RR（參見第 3.3.9 節
$$ RFC1035 $$) 的 RDATA 部分由首選項編號 0 和零長度標籤組成，在主文件中寫為“.”，作為交換域，表示不存在域的郵件交換器。自從 ”。” 不是有效的主機名，空 MX 記錄不能與普通 MX 記錄混淆。 指某東西的用途 ”。” 作為一個偽主機名，意味著沒有可用的服務以 SRV RR [ RFC2782 ] 為模型，它具有類似的含義。 通告空 MX 的域不得通告任何其他 MX RR。
（重點補充）
正如這裡所指出的，“空 MX”的實現細節基於
SRVRR 類型中已經建立的模式。模仿這一點是有意義的，因為SRVRR 類型或多或少是 RR 類型的通用版本MX。
SRV因此，在定義RR 類型時，基本上已經做出了決定。那麼，為什麼不使用
.invalid呢？ 來自RFC2606 第 2 節：“.invalid”用於線上建構肯定是無效的、一目了然無效的域名。
從這裡可以看出，這個保留的 TLD 是供人類使用的。沒有在軟體中定義特殊處理的先例。
當然，它可以以某種不同的方式實現，但他們選擇使用最小的 using 方法
.，這不是有效的主機名，因此無論如何都不會干擾正常使用。