一則訊息有幾個 DKIM 簽名需要對每個簽名進行評估。計算簽名或選擇第一個通過的結果可能會錯誤地識別對可見作者進行身份驗證的域。在下面 RFC 9989 §4.4.1，任何與作者域一致的經過 DKIM 驗證的識別碼都可以提供DKIM路徑 DMARC 經過。
保留每個結果的身份
透過核准的流程匯出原始訊息。記錄可見的 From 域，並且對於每個簽名，其 d= 簽名域名， s= 選擇器, a= 演算法及相關 規範化 設定.將可信任接收系統的結果與該簽章相關聯。兩個簽章可以使用相同的網域但使用不同的選擇器或演算法，因此僅憑域可能無法區分它們。
不要輕信任意的 Authentication-Results 字段只是因為它出現在訊息中。 RFC 8601 §1.2 解釋了這些字段的信任邊界。使用您正在調查其評估的接收系統的結果，並在匯出證據時保留該來源。寄件者可以插入誤導性的標題文字；複製的狀態標籤不是獨立的驗證。
將驗證和調整作為單獨的決策
驗證確定簽章是否對其簽章域有效。 結盟 將該經過驗證的網域與適用DMARC規則下的作者網域進行比較。不相關的提供者的簽名可以完全有效，無需驗證作者的DMARC可見域。
為了嚴格的DKIM對齊，網域必須完全匹配，以下是網域大小寫比較 RFC 1035 §2.3.3。寬鬆對齊使用由適用的DMARC流程確定的組織域關係。 RFC 9989 §4.10.2 為此確定定義了DNS樹遍歷。不要根據兩個網域中的共同單字來決定對齊，也不要默默地假設每個接收者都採用了最新的發現實作。
處理合成訊息
假設有效的適用DMARC策略，作者域為 example.com 並且沒有對齊 SPF 經過。簽名 A 使用 d=example.net，驗證成功，未對齊。簽名 B 使用 d=example.com 但下游內容更改後驗證失敗。兩者都不提供對齊的傳遞DKIM身份，因此此組合不會產生DMARC通行證。
現在新增簽名 C d=example.com 即驗證成功。它精確對齊，因此它提供了DMARC傳遞的DKIM路徑。不相關的通過和失敗簽名不會自動取消 C。這是一個說明性評估，而不是有關捕獲的客戶訊息或保證郵箱放置的聲明。
將範例寫入調查記錄中的單獨欄位：簽名標識符、驗證結果、對齊結果和對DMARC的貢獻。切勿將簽章 A 的通行證與簽章 B 的對齊域結合來製造單一簽章無法實現的結果。
解釋為什麼有多個簽名
並行演算法、提供者的操作簽名和中間人的後期簽名都可以創建多個結果。在路由和簽署者配置確定原因之前，這些都是假設。 RFC 8463 §6 描述了 RSA 的不同選擇器和 埃德25519 轉換簽名；他們的結果應該單獨追蹤。
如果網關重新簽署修改後的郵件，請檢查其新網域。透過網關簽名不會自動修復原始作者的身份驗證。如果組織控制最終簽名階段，請驗證其是否以批准的身份簽署預期的後處理內容。在未檢查其操作目的之前，請勿刪除明顯多餘的簽名。
以訊息級結論結束
評估所有相關的DKIM簽章後，分別評估SPF的經過驗證的識別碼和對齊方式。如果未發現適用的DMARC策略，請勿將該情況重新標記為正常DMARC故障。將身分驗證結果與接收者的最終處置區分開來，這可以反映附加策略或篩選。
保留原始訊息、可信結果來源、每個簽名分析以及最終結論的原因。如果報告工具以不同的方式聚合簽名，請在將不同的摘要視為協議矛盾之前比較其原始證據。有用的結果是一條可解釋的身份路徑，而不僅僅是大量的綠色指標。
記錄範例，不混合身份
對於上面的合成訊息，每個簽名保留一行：
- 答： example.net ；驗證通過；對齊編號； DKIM對DMARC貢獻
- B： example.com ；驗證失敗；網域將匹配但未經過身份驗證； DKIM貢獻編號
- C： example.com ；驗證通過；對齊是； DKIM貢獻是的。
在 C 出現之前，所宣告的未對齊SPF不存在任何通過路徑。如果存在 C， DMARC將透過假定的適用策略。不聲明實際的接收者結果或收件匣放置結果。
相關閱讀
DKIM對齊：將 d= 與可見的 From 域進行比較 · RSA 和 Ed25519 DKIM簽章：部署問題與互通性.