[ DNS和網域 ]

用於電子郵件身份驗證的DNS記錄和擁有者

在更改SPF 、 DKIM或DMARC之前,將每個身份驗證身份對應到其確切的DNS所有者、記錄類型和負責的操作員。

由EmailAuth研究團隊提供 · 6 分鐘閱讀

[ 重點 ]

  • 從實際協定身分派生SPF 、 DKIM和DMARC問題。
  • 確認委託的權限,而不僅僅是註冊商或熟悉的DNS控制台。
  • 保留TXT記錄邊界並將別名與區域委派區分開來。
在此頁面上

從接收者將檢查的身份開始

電子郵件身份驗證變更從名稱開始, 一個記錄 類型和負責的操作員。 「為我們的網域新增身分驗證」太廣泛,無法辨識正確的DNS編輯器或接收者所需的答案。行銷服務可以使用一個網域進行簽名,使用另一個網域作為其SMTP信封,並在「寄件者」欄位中顯示第三個網域。在任何人編輯區域之前,清單應該保留這些差異。

為了 SPF,取得SMTP使用的域名 郵件來自 身份;這 HELO身份 有自己的檢查,包括空反向路徑情況。查詢TXT的適用網域。不要僅透過讀取可見的寄件者地址來選擇SPF所有者。 RFC 7208 ,第 2.3–2.4 節和 3.1 節.

為了 DKIM,取 選擇器 從 s= 和簽章域來自 d= 在簽名中。鍵找名稱是selector,那麼 _domainkey,然後是簽章域。為了 DMARC,策略發現從下面的TXT查詢開始 _dmarc 位於作者域並且可以繼續使用指定的 DNS樹遍歷。缺少初始記錄本身並不表示政策不適用。 RFC 6376 ,第 3.6.2 節; RFC 9989 ,第 4.5 和 4.10 節.

將所有者姓名與擁有變更的人員分開

在DNS中,記錄的擁有者是網域名稱。在變更票中,其所有者通常是個人或團隊。記錄兩者。網域註冊商、權威DNS主機、發送平台管理員和批准網域所有者可以是不同的各方。註冊訪問並不是特定DNS控制台控制當今公共答案的證據。

識別包含所請求名稱的區域的委派權威伺服器。子網域可能有自己的委託,因此正確的編輯器可能與父域的編輯器不同。將區域、完整所有者名稱、請求的類型、建議的資料和負責的操作員保存在一起。 DNS委派定義權限變更的位置;它不遵循組織的支援團隊界限。 RFC 1034 ,第 4.2 和 4.2.1 節.

請寄件者管理員提供帳戶所發出的值並解釋所有別名。供應商的 CNAME 指令將一個名字指向另一個名字;它與用 NS 記錄委派子區域的操作不同。捕獲誰維護別名目標以及誰可以更改客戶端記錄。

閱讀已發表的記錄集而不是編輯的外表

DNS控制台通常接受相對主機標籤並附加區域名稱。因此,以錯誤模式輸入的複製的完全限定名稱可能會落入非預期所有者手中。驗證最終的絕對名稱,包括每個子網域和底線標籤。編輯的保存價值是準備證據;權威的DNS答案是發布證據。

TXT演示也需要小心。一條TXT資源記錄可能包含多個字串。對於SPF這些字串連接在一起而不插入空格。這與發布兩個單獨的 SPF記錄 屬於同一所有者,這是禁止的。在查看匯出或螢幕截圖時保留記錄邊界,而不是計算引號。 RFC 1035 ,第 3.3.14 節; RFC 7208 ,第 3.2–3.3 節.

MX記錄 識別用於接收郵件的郵件交換器。他們不獨立證明哪個出站服務被授權或哪個金鑰對訊息進行簽署。 SPF策略可以透過某種機制引用MX ,但該關係必須來自實際策略,而不是來自所有與郵件相關的DNS記錄都驗證傳送的假設。 RFC 1035 ,第 3.3.9 節; RFC 7208 ,第 5.4 節.

處理虛構的所有權清單

假設一個虛構的服務發送帶有 From 的郵件 news@example.com, 郵件來自 bounce@mail.example.com,和一個 DKIM簽名 含有 d=example.com; s=nov26。初始清單包含三個獨立的TXT問題: mail.example.com, nov26._domainkey.example.com, 和 _dmarc.example.com。這些是說明性名稱和標識,而不是觀察到的訊息或建議的生產值。

電子郵件管理員確認預期的路由和選擇器。 DNS管理員檢查哪個區域包含每個名稱以及是否有任何提供者所需的別名更改了查找路徑。域所有者批准範圍。如果選擇器是由廠商發佈的,則廠商必須保留對應的私鑰;只有公鑰資料才屬於DNS 。絕不能將私鑰複製到票證或公共TXT記錄中。

庫存行應區分「由服務提供」、「存在於權威DNS 」和「在收到的郵件中觀察到」。讓其中一列未知比過早檢查單一「經過身份驗證」的方塊更有用。

在結束變更之前收集證據

提議的檢查是 挖掘@AUTH_IP nov26._domainkey.example.com 。 TXT +norecurse 和 挖掘@RESOLVER_IP nov26._domainkey.example.com 。 TXT。將大寫佔位符替換為核准的端點。對每個實際所有者和相關權威伺服器重複此操作。保留 UTC 時間、伺服器位址、問題、回應代碼、標誌、答案和權限部分、TTL 和任何別名鏈。本文中尚未執行這些命令。

如果權限和遞歸不一致,請在新增重複記錄之前調查發布一致性、快取和解析器路徑。 DNS應答仍無法證明簽章已驗證、 SPF授權實際發送 IP 或DMARC對齊。使用受控接收訊息和可信任接收者結果來結束這些問題。帶時間戳的權威和遞歸記錄仍然是這份紀錄片草稿的開放原始證據之門。

[ 外帶 ]

將協議身分、 DNS所有者名稱和責任運營商保留在一起,然後分別驗證發布和接收的郵件。

[ 按角色 ]

這對您意味著什麼

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

DNS管理員

驗證實際發佈點

請求的擁有者可以位於委託的子區域中或指向提供者控制的目標。

後續步驟

  1. 編輯前記錄完整的所有者、類型、區域和操作員。
  2. 保留相關權威伺服器的答案並辨識別名。

電子郵件平台所有者

從發送工作流程提供身份

服務的信封域和DKIM選擇器確定不同的DNS問題。

後續步驟

  1. 提供實際的 MAIL FROM 域和預期的d=/s=對。
  2. 將發布的配置與接收的訊息觀察分開。

安全審查員

批准有界身份驗證更改

已發布的記錄是一種依賴性,並不能證明發送者已對齊或可以安全發布。

後續步驟

  1. 檢查沒有私鑰進入DNS或票證。
  2. 審查受控訊息並保留未解決的身份差距。

[ 常見問題解答 ]

常見問題

如果寄件者地址是news@example.com ,我應該查詢哪個網域的SPF ?

使用適用的SMTP MAIL FROM 身分中的域,以及包含空反向路徑情況的HELO規則。僅可見的寄件者地址並不能識別SPF查詢所有者。

如何建構DKIM查找名稱?

取得簽署的 s= 選擇器和 d= 簽章域,然後查詢選擇器。 TXT的_domainkey.signing-domain 。不要假設每個訊息都使用舊設定票證中顯示的選擇器。

註冊商一定是可以更改TXT記錄的人嗎?

否。確定該區域的委託權威服務以及管理該服務的運營商。註冊和DNS託管可以由不同的服務處理。

MX記錄能否證明出站平台是授權的?

不會MX標識接收郵件交換器。 SPF策略可以明確使用 mx 機制,但單獨的MX發布並不是出站驗證。

TXT中的兩個帶引號的字串是否對應兩個SPF策略?

未必。一條TXT記錄可以包含多個字串, SPF將這些字串連接起來而不添加空格。在確定是否存在重複的SPF策略之前保留資源記錄邊界。

提供者CNAME指令是否委託整個DNS區域?

不會CNAME在名稱上建立別名。 NS 記錄建立區域委派。記錄別名目標的操作員,而不將別名視為區域權限的轉移。

第一個_dmarc名稱中沒有TXT是否表示DMARC策略不適用?

不是靠它自己。當初始查找未找到有效的策略記錄時, RFC 9989策略發現可以繼續進行DNS樹遍歷。

完成庫存的證據門還需要什麼?

針對每個確切所有者和類型的原始時間戳權威和遞歸答案,以及帳戶適用性和受控接收訊息結果。範例庫存是虛構的。

[ 來源 ]

來源

  1. RFC 1034 :網域:概念與設施
  2. RFC 1035 :網域:實作與規範
  3. RFC 6376 :網域金鑰識別郵件簽名
  4. RFC 7208 :用於授權在電子郵件中使用網域的寄件者策略框架
  5. RFC 9989 :基於網域的訊息驗證、報告和一致性

[ 詞彙表 ]

詞彙表

DNS擁有者名稱
DNS資源記錄所屬的域名,與負責更改該記錄的人員不同。
選擇器
DKIM s= 值與簽章域一起使用來定位_domainkey下的公鑰記錄。
郵件來自身份
其域通常提供SPF策略查找的SMTP信封標識;空反向路徑處理使用基於 HELO 的身份規則。
作者域
訊息的RFC5322域。 DMARC 用於DMARC發現和對齊評估的寄件者地址。
TXT字串
TXT資源記錄中的一個長度分隔字串;多個字串可能屬於單一記錄。

企業出處

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

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

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

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

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

知識庫