映射郵件系統實際做出的決策
有用的電子郵件依賴關係圖將業務發送服務與其使用的身份、 DNS記錄和傳輸服務連接起來。每一個的列表 TXT記錄 還不夠。該地圖應該讓所有者回答如果提供者、主機名稱、金鑰或策略發生變化可能會出現什麼問題，並在批准該更改之前確定所需的證據。
將出站身份認證和入站傳輸策略作為單獨的分支。他們可能共享管理員和網域，但不保護相同的決策。這裡提出的地圖是一個營運模型，組織必須從自己的授權清單和訊息證據中填充該模型。這並不是說DNS掃描可以發現每個發送者或確定所有接收者行為。
以真實的發送路由啟動每個出站分支
為每項服務和實質上不同的路線建立一個條目，包括定期計費、支援系統和外部管理的活動。記錄其業務所有者、技術所有者、可見作者網域、信封網域、發送基礎設施和觀察到的 DKIM 簽名域名和 選擇器。將每個值標記為觀察到的、由提供者記錄的或仍然未知的。請勿將供應商的通用設定指南轉變為該帳戶配置的證據。
這 SPF 分支從評估的身份開始，並遵循與該路由實際相關的策略條款。包括外部政策參考和控制它們的團隊。 RFC 7208第 2.3 節及 4.6.4 節 解釋身分評估和 DNS 相關限制。依賴關係圖可以顯示外部變更可能影響評估的位置，但節點的靜態計數並不能確定每個連接位址的結果。
DKIM分支以簽署的 d 和 s 值開始，並通往選擇器的驗證記錄。新增任何別名目標、目標區域擁有者和金鑰生命週期所有者。 RFC 6376第3.6.2.1節 定義此尋找名稱空間。將私鑰放在地圖之外；記錄安全操作所有權並參考經批准的密鑰管理系統。
將身份驗證連接到相關DMARC決策
新增作者網域（適用） DMARC 政策記錄以及如何發現政策的證據。將經過身份驗證的識別碼連結到 結盟 決定，確定嚴格或寬鬆模式。在下面 RFC 9989第 4.4 節，有效對齊的SPF或DKIM識別碼可以滿足DMARC ；兩個不相關的身份驗證過程無法建立對齊。
記錄用於策略發現評估的規範和實施上下文。 RFC 9989 描述了一個 DNS樹遍歷，因此應該審查繼承的關於發現的電子表格假設，而不是默默地繼續下去。該地圖應保留有關其實施尚未得到驗證的接收者的不確定性。包括報告目的地及其所有權，但將報告可用性與已觀察到每個合法寄件者的證據分開。
顯示所有者請求的策略和接收者在不同欄位中觀察到的處理。這使得未來的審閱者更難將策略字串誤認為郵件被拒絕、已發送或放入收件匣的證據。
新增獨立運輸分支
對於入站郵件，將收件者網域連接到其MX主機及其位址相依性。如果 MTA-STS 部署後，新增發現TXT記錄、HTTPS 策略主機、憑證維護擁有者、發布模式、允許的MX名稱和策略生命週期。 RFC 8461第 3 節和第 6 節 描述發現和快取。策略生存期與DNS TTL 不是相同字段，更改其中一個字段不會直接重寫另一個字段。
在哪裡 DANE SMTP已部署，映射 DNSSEC 鏈， MX分辨率， TLSA 記錄和相應的TLS服務。 RFC 7672第 2 節 使經過身份驗證的DNS成為核心依賴項。在沒有驗證和證書關係的情況下複製到清單中的 TLSA 記錄是不完整的操作證據。
新增TLS報告作為觀察管道，而不是作為執行機制。 RFC 8460第 3 節 定義報告策略發現。報告目的地需要所有者和審查流程，而實際的運輸政策仍然是一個明顯的依賴項。
提供者遷移的虛構範例
虛構組織「Example Repairs」計畫將發票郵件轉移給新供應商。其提議的地圖將發票服務連結到billing.example.com作為作者網域、單獨的信封網域和透過別名託管的舊DKIM選擇器。遷移所有者註意到，退休的提供者仍然控制著別名目標，並且一些排隊的訊息可能攜帶舊簽名。
因此，審查提出分階段簽署變更、驗證替代路線以及單獨批准的退役決定。同時，入站MX和MTA-STS條目仍然是不同的分支，並且不會作為出站供應商移動的一部分進行自動編輯。這個例子是發明的；身份、批准和訊息結果尚未從真實帳戶獲得。
地圖的好處在於它揭示了一個問題：什麼證據允許在不破壞合法訊息驗證的情況下撤銷該別名？地圖本身並沒有回答這個問題。服務所有者必須提供隊列和簽名信息，審核者必須將這些事實與提議的更改聯繫起來。
使用地圖維護證據和所有權
為每條邊提供最後驗證日期、證據參考、所有者和審核觸發器。在供應商遷移、選擇器輪換、委託更改、傳輸策略編輯或無法解釋的身份驗證失敗後重新存取它。未知的所有者和未經驗證的邊緣應該保持可見，而不是充滿猜測。
在推出之前，建立逐一發送者的準備矩陣、準確的策略差異和批准記錄。授權執行後，附上相關訊息和DNS觀察結果。這些是目錄所需的原始工件，並在此處保持開啟。本手稿提供了地圖設計和虛構的決策練習，而不是填充的租戶庫存或經過驗證的部署。