[ DNS和網域 ]

DNS MX記錄:郵件路由、優先權和依賴性

透過MX優先權和位址依賴性追蹤接收郵件路由,而不將其視為寄件者授權。

由EmailAuth研究團隊提供

[ 重點 ]

  • 較低的MX偏好受到青睞;相同的值並不能保證分裂。
  • 缺少MX 、損壞的明確路由和 null MX具有不同的意義。
  • DNS路由和SMTP接受不是最終的郵件傳送。
在此頁面上

MX記錄 告訴SMTP客戶端網域在哪裡接收郵件。他們本身並不授權服務作為該網域發送。可靠的接收設定需要可用的交換主機名稱、可存取的SMTP端點和臨時故障計劃,而不僅僅是綠色MX查找。

正確解釋偏好

參考: RFC 5321 §5.1, RFC 2181 §10.3.

每個MX記錄都包含一個數字首選項和一個交換主機名稱。先嘗試較低的優先數字,然後再嘗試較高的數字。當沒有明確的理由支持一個同等偏好的目的地時, RFC 5321要求隨機化它們的順序以分散負荷。它們在DNS應答中的順序不是穩定的主伺服器指定。所有公佈的路線都應該是預期的且可操作的。

交換主機名稱必須具有可用的 A 或 AAAA 記錄,且不能是 CNAME。請勿將 IP 文字放入MX交換欄位中。分別解決每個交換,然後測試公佈的SMTP服務。僅地址答案無法顯示端點是否接受收件者網域的郵件。

區分不存在、不可用和空MX

參考: RFC 5321 §5.1, RFC 7505 §3.

當成功尋找未傳回MX記錄時, SMTP具有隱含 MX 規則:它將網域本身視為目標並尋找其位址記錄。這並不是忽略損壞的明確MX記錄並改用網域的網站位址的權限。臨時DNS錯誤也不同於明確的缺失,通常會導致排隊和重試。

空MX是網域不接受郵件的明確聲明:優先順序為零且根標籤為交換的單一MX ,通常顯示為 0 .。 RFC 7505規定不要與它一起發布其他MX記錄。因此,無MX和空MX是不同的配置。

透過佈線裝置進行工作

合成夾具A有 example.com. MX 10 mx1.example.com. 和 example.com. MX 20 mx2.example.com.。第一個主機有 A 192.0.2.10;第二個有 A 192.0.2.20。預期的優先順序是 mx1 在 mx2 之前。與 mx1 的連線失敗可能會導致另一次允許的傳送嘗試;它並不能證明 mx2 接受了該訊息。

夾具 B 刪除兩筆MX記錄,但保留 example.com. A 192.0.2.30。在隱式 MX 規則下,該位址將成為潛在的SMTP目標。夾具 C 僅發布 example.com. MX 0 .;預期的解釋是該網域不接受郵件。夾具 D 保留 A 的MX記錄,但刪除兩台交換器的位址。預期結果是不可用的顯式路線,而不是回退到頂點 一個記錄.

透過查詢每個隔離裝置的MX和每個返回交換的 A/AAAA,在實驗室中重現DNS部分。記錄選擇的順序和分類。如果需要,請使用受控SMTP伺服器來測試重試和接受。文件地址和描述的結果是說明性的,而不是生產測量。

驗證業務路線

參考: RFC 7208 §5.4, RFC 5321 §4.2.5.

將入站路由與 SPF 政策。 SPF MX 機制可以明確地使 MX 關聯位址與SPF評估相關,但單獨發布MX並不會建立該授權。因此,更改入站提供者也可能會影響使用的現有SPF策略 MX 並值得單獨審查。

在遷移期間,請在刪除舊路由之前驗證所有活動交換器上的收件者設定、 SMTP回應和傳輸安全性。如果配置不同,備份交換可以接受垃圾郵件或拒絕合法收件者。記錄每個端點的擁有者以及結束變更的證據;不要將SMTP接受與收件匣放置或人員閱讀郵件等同起來。

捕獲的隔離路由運行

保留的歷史捕獲(針對本次審查進行了檢查但未重新運行)記錄了 2026 年 11 月 7 日20:34:42 UTC 執行的環回裝置返回了MX集 10 mx1.example.com. 和 20 mx2.example.com. 來自127.0.0.1埠 42125。使用 dnspython 2.9.2 的 Python 3.12.14 用戶端對這些首選項進行了排序。明確實驗室端點映射將 mx1 傳送至127.0.0.1連接埠 45271,將 mx2 傳送至連接埠 37481;此連接埠對應僅取代固定裝置內的公共連接埠 25 路由。

當兩個監聽器都運作時,mx1 返回 220, 已接受 EHLO 和 250, 已接受 郵件來自 和 RCPT TO 與 250,輸入數據 354 並返回 已接受 250 則合成訊息;本地丟棄。仅关闭主侦听器后,记录下一次运行 連線拒絕錯誤 對於 mx1 和 mx2 具有相同的接受序列。不涉及外部郵件、真實收件者或郵件信箱傳遞。

要重現,請啟動兩個環回SMTP裝置,查詢實驗室MX回應程序,將其交換名稱對應到偵聽器,並使用 Python smtplib 發送無害的合成訊息。關閉主控制器後重複此操作。保留線路回應、端點對應、客戶端/伺服器記錄、時間戳記和工具版本。捕獲的裝置使用故意較小的SMTP伺服器,並僅演示首選項驅動的重試;這不是產品的一致性測試 MTA 或生產故障轉移的證據。

保持證據範圍明確

存檔的記錄僅確認上述環回裝置行為,包括其自訂連接埠對映和本機丟棄。來源擷取與利用保持不變;本次審查沒有重複SMTP流量,也沒有從歷史測試推斷生產故障轉移。

[ 外帶 ]

較低的MX偏好受到青睞;相同的值並不能保證分裂。缺少MX 、損壞的明確路由和 null MX具有不同的意義。 DNS路由和SMTP接受不是最終的郵件傳送。

[ 按角色 ]

這對您意味著什麼

選擇您的角色以執行後續實際步驟。

IT/郵件管理員

追蹤MX直至SMTP

首選項值和位址解析只是入站測試的第一階段。

後續步驟

  1. 將每次交換解析為 A 和 AAAA。
  2. 分別測試顯式、不存在和空MX 。
  3. 在更改之前檢查SPF mx 依賴關係。

CISO / SecOps

將替代交換保留在範圍內

每個通告的路由都可以在故障期間成為活動處理路徑。

後續步驟

  1. 查看所有公佈的SMTP端點。
  2. 需要一致的收件人和濫用控制。
  3. 驗收與交貨索賠分開。

創辦人/非技術人員

保護每條接收路徑

備份交換器是客戶通訊路徑的一部分,而不是可以忽略的備用配置。

後續步驟

  1. 識別每條入站路由的擁有者。
  2. 需要郵箱遷移測試。
  3. 將備份路由行為保持在範圍內。

[ 常見問題解答 ]

常見問題

MX優先順序越大是否意味著優先順序越高?

不會。數字越小越好。

RFC 5321 §5.1

相同的數量能否保證準確的流量分配?

不。他们没有指定保证的分配百分比。

RFC 5321 §5.1

交換字段可以包含 IP 位址嗎?

使用帶有位址記錄的主機名,而不是 IP 文字。

RFC 2181 §10.3 RFC 5321 §5.1

交換主機名稱可以是別名嗎?

不需要。引用的規則需要位址記錄而不是CNAME目標。

RFC 2181 §10.3

沒有MX就代表沒有郵件嗎?

未必。 SMTP可以使用指向網域本身的隱式MX 。

RFC 5321 §5.1

0 . 是什麼意思?意思是?

當發佈為網域的單一MX記錄時,它為空MX ,聲明不接受郵件。

RFC 7505 §3

損壞的明確MX是否會回退到網站 A 記錄?

不會。當MX記錄不存在(並非不可用)時,隱含 MX 回退將適用。

RFC 5321 §5.1

MX是否授權出站郵件?

不是靠它自己。顯式SPF機制可以引用它,但接收路由和發送者授權是不同的。

RFC 7208 §5.4

[ 來源 ]

來源

  1. RFC 7208

    部分 §5.4

  2. RFC 5321

    部分 §4.2.5 · §5.1

  3. RFC 7505

    部分 §3

  4. RFC 2181

    部分 §10.3

[ 詞彙表 ]

詞彙表

MX偏好
用於對候選交換進行排序的數字,優先考慮較小的值。

RFC 5321 §5.1

空MX
具有preference0 和exchange 點的唯一MX記錄,聲明不接受郵件。

RFC 7505 §3

企業出處

為什麼頂級金融機構和政府 退役了他們的電子郵件安全儀表板。

傳統的電子郵件驗證平台會向您出售儀表板並要求您的工程師來完成這項工作。在高風險環境中,手動監督意味著延遲執行、配置漂移和不受監控的影子域。

EmailAuth是代理電子郵件來源平台。 我們的代理人強制執行 p=reject,保持第三方寄件者一致並將您的網域移至完整狀態 RFC 9989 合規性、新的DMARC標準,以及人機互動審核能力。

政府 大型企業 一級金融機構

SaaS · 專用租賃 · 氣隙本地部署 · BYOK 加密

知識庫