Check-Host.cc

全球 MX 紀錄檢查器

MX (Mail Exchanger) 紀錄是傳入 SMTP 流量的基礎路由協定。當外部的郵件傳輸代理 (MTA) —如 Google Workspace 或 Microsoft Exchange— 需要將電子郵件傳送到 user@example.com 時,它會對 example.com 區域執行 DNS 查詢,特別請求 MX 紀錄。產生的 Payload 提供了一份被授權代表該組織接收郵件的主機名稱清單。

優先權整數與 SMTP 容錯移轉 (Failover)

與標準 A 紀錄不同,MX 紀錄使用優先權整數(例如 10、20、50)實作了原生的階層結構。此整數決定了連線的偏好。發送方 MTA 始終會嘗試在連接埠 25 上與具有最低數值的伺服器建立 TCP Handshake。如果該主要伺服器拒絕連線、發生逾時 (timeout) 或回傳暫時的 4xx 錯誤,MTA 會自動退回 (fallback) 到具有下一個最低數字的紀錄。將多筆 MX 紀錄設定為完全相同的優先權整數,可為傳入的郵件流啟用基本的 Round Robin 負載平衡。

Bare IP 違規 (RFC 1035)

初階系統管理員最常犯的設定錯誤之一是將 MX 紀錄直接指向 IPv4 位址。根據嚴格的 DNS 標準 (RFC 1035),MX 紀錄的目標必須是標準主機名稱 (canonical hostname),絕不能是 IP。例如,將 MX 指向 192.168.1.50 即違反了協定。它必須指向像 mail.example.com 這樣的主機名稱,然後再透過 A 紀錄解析為 IP。嚴格的企業垃圾郵件過濾器和入侵偵測系統 (IDS) 會積極丟棄來自或路由到具有基於 IP 的 MX 目標之網域的電子郵件。

Null MX 紀錄 (RFC 7505) 與垃圾郵件緩解

如果一個網域嚴格用於網路流量,且從未打算接收電子郵件,那麼它極易受到反彈垃圾郵件 (backscatter spam) 的攻擊。攻擊者會在發送的垃圾郵件中偽造 (spoof) 該網域,導致成千上萬的自動退信訊息湧回該網域。為了緩解這個問題,管理員會部署「Null MX」紀錄。透過設定單一 MX 紀錄,其優先權為 0 且目標為 .(根節點),您在數學上指示了所有全球郵件伺服器該網域不接收電子郵件,迫使它們立即丟棄訊息而無需嘗試遞送。