SPF, DKIM 和 DMARC 提供有關電子郵件的不同證據。 SPF根據評估網域的傳送策略評估連線來源。 DKIM驗證涵蓋的訊息材料上的網域關聯簽章。 DMARC將傳遞的經過驗證的身份與 From 中的網域相關聯，並應用其策略框架。
他們一起工作是因為沒有一個單一的綠色結果可以回答所有的身份問題。有用的實作遵循訊息透過發送服務、 DNS依賴項和接收系統，保留每次檢查實際建立的內容。
給每張支票提出自己的問題
- 機制： SPF ；回答的問題：該連線來源是否符合所評估身分的發送策略？重要邊界：該身分不必是可見的 From 域
- 機制： DKIM ；回答的問題：此網域相關簽章是否與其涵蓋的訊息資料進行驗證？重要邊界：驗證並不能確定訊息或請求的每個部分都是安全的
- 機轉： DMARC ；回答的問題：合格的通過身分是否與寄件者一致，適用什麼評估政策？重要邊界：接收器處理包括DMARC以外的證據
這些檢查是相關的，但它們不是同一測試的三個副本。系統可以發布所有三種DNS記錄，而應用程式仍然在沒有預期簽名的情況下發送或 域對齊.
Follow SPF from the sending connection
對於 郵件來自 檢查具有非空信封回傳地址的普通訊息， RFC 7208 §2.4 指定SPF使用 MAIL FROM 身分評估發送來源。接收者查閱該網域的已發佈策略，該策略可能引用其他策略資料。
這就是為什麼在任何DNS編輯之前身份很重要。在example.com新增服務 SPF記錄 無法修復實際上在其他地方使用服務控制域的SPF評估。首先確定訊息和路由的用途。
在下面 RFC 7208 §2.3 和 RFC 7208 §2.4, SPF can also evaluate HELO，其規範定義了空反向路徑的處理。這些情況並不能證明從訊息的顯示欄位中取代任意域是合理的。保留評估結果與評估的一致性。
SPF通行證不會在訊息內容上建立簽名。它的證據是關於在該接收點評估的來源和身分。
遵循DKIM從簽章到驗證
A sending system applies a DKIM簽名 使用私钥。在下面 RFC 6376 §3.6.2.1，驗證使用透過該簽署的簽名域找到的公共材料，並且 選擇器。私鑰屬於授權簽章系統，而不是公共DNS 。
簽名和發布都必須有效。名稱正確的公鑰並不能證明應用程式用它簽署了訊息。相反，目前簽章並不能證明其金鑰可以被檢索或在交付後驗證成功。
在下面 RFC 6376 §3.7， DKIM保護其定義的簽章計算所涵蓋的材料。簽名後更改相關內容的網關可能會影響驗證。這 body-hash investigation guide 解釋如何在不猜測每個DKIM錯誤都需要新密鑰的情況下追蹤特定故障。
使用DMARC將證據連接到 From
DMARC使用適用的政策和對齊關係評估寄件者地址中的網域。在下面 RFC 9989 §5.3.5，具有適用策略和已完成檢查的訊息級傳遞可以來自傳遞對齊的SPF身份或傳遞對齊的DKIM簽章。
此通過條件並不建議僅配置一種機制。 RFC 9989 §8 全面參與要求包括協調SPF和DKIM 、報告和政策發布。在下面 RFC 9989 §7.4, domains publishing p=reject 不得僅依賴SPF ，且必須套用有效的DKIM簽章。
郵箱提供者也可以強加自己的寄件者要求。 Google 大量寄件者指南，例如呼叫SPF 、 DKIM和DMARC 。將協議的訊息層級結果與提供者的整個發送策略的合規性分開。
了解為什麼路徑能夠以不同的方式生存
以下是一個綜合範例，而不是帳戶測試。通知服務為其直接路由產生通過對齊的SPF結果和透過對齊的DKIM簽章。
現在考慮對該路線的兩項變更：
- 轉發服務改變最終接收者看到的連線來源。較早的SPF結果並不能保證以後的評估。如果保留相關簽名內容，則原始對齊的DKIM簽章仍可驗證。
- 網關在簽名階段後更改簽名內容。 DKIM可能會在下一個接收器處失敗，而SPF取決於最終的連線路由和評估的身份。
對每個中介機構來說，這兩種結果都不是不可避免的。檢查實際路線、身份和驗證結果。這種差異解釋了為什麼這兩種機制提供了有用的不同路徑，但沒有使所有轉送或修改都普遍可靠。
將配置證據與訊息證據分開
小型服務等級記錄比無法解釋的網域範圍狀態更有用。這個虛構的接受矩陣說明了這個差異：
- 服務觀察：員工郵件具有公共DKIM金鑰；還需要證據：所選網域透過其真實路由進行簽署和驗證的證明
- 服務觀察：計費郵件通過提供者網域的SPF ；仍需證據：它與 From 以及任何對齊的DKIM路徑的關係
- 服務觀察：行銷郵件具有有效的DMARC策略；仍需要證據：實際簽名、身分驗證和策略情境證據
- 服務觀察：收到的訊息通過相關檢查；仍需證據：其企業主和批准用途，單獨評估
對於每項服務，保留支援的配置、重要身分和代表性的原始接收訊息。在下面 RFC 8601 §7.1，使用可信任接收系統結果；由不受信任的發送者插入的通過斷言不能代替接收者的工作。
這 寄件者庫存 將這些記錄與所有者聯繫起來。這 DMARC record workflow 將發布與訊息和報告驗證結合。
保留組合結果的限制
As the signature scope in RFC 6376 §3.7 and receiver handling in RFC 9989 §5.4 事實證明，這些檢查不會為收件者加密郵件、確定其內容的真實性或保證收件匣的放置。傳輸安全和敏感訊息內容的保護是不同的問題。
受損的授權服務仍然可以發送經過驗證的郵件。同樣，有效的技術結果並不能證明組織批准了特定的應用程式帳戶或業務請求。
因此，有用的组合结果是精确的：接收者评估实际的源和签名身份，找到 From 所需的对齐传递路径，并考虑相关策略。將該證據與產生該證據的服務和路線一起保留。三個配置的記錄是一個起始依賴；經驗證、維持的溝通是操作結果。
保留有界結論
在虛構的接受矩陣中，公鑰僅關閉發布證據。提供者域SPF通行證仍需檢查其與寄件者的關係。對於任何已申請的DMARC通行證，請保留適用的保單和特定的一致通行路徑，然後將帳戶審批和內容安全分開。這裡沒有進行任何業務配置或訊息測試。