一則訊息可以傳遞 DMARC 儘管 SPF 或者 DKIM 失敗。目前的任務是識別通過的對齊路徑，然後確定其他故障是路線的預期屬性還是導致服務脆弱的故障。
不要僅僅為了使每個指示器都變成綠色而更改正確的DMARC結果。同樣，不要使用通行證作為忽略損壞的簽名服務的權限。訊息級結果和整個發送系統的彈性是不同的評估。
確定哪條路徑承載結果
DMARC使用可見寄件者位址中的網域作為其參考。當需要時，通過的SPF身份或通過的DKIM簽章身分可以滿足DMARC 結盟 關係成立。在以下描述的信任邊界內使用接收者產生的結果 RFC 8601 §7.1。對於DKIM ，檢查每個相關簽名，而不僅僅是郵件用戶端顯示的第一個簽名。通過/失敗規則在中指定 RFC 9989 ，第 5.3.5 節.
以下案例是綜合範例。假設適用的有效策略和精確的域匹配，無論對齊標記為“是”。
- 案例：A； SPF ：不及格； DKIM ：From 域的通行證； DMARC結論：透過DKIM
- 案例：B； SPF ：From 域的通行證； DKIM ：失敗； DMARC結論：透過SPF
- 案例：C； SPF : 傳遞給不相關的域； DKIM ：失敗； DMARC結論：失敗，因為沒有經過路徑對齊
- 案例：D； SPF ：不及格； DKIM ：一次簽章失敗；另一個傳遞給 From 域； DMARC結論：透過對齊的簽章
在實際調查中，將這些標籤替換為實際收到的訊息中的網域和可信結果。提供者的「經過驗證」的帳戶狀態不足以證明哪一條路由成功。
當SPF失敗但DKIM存活時
轉發可以改變最終接收者看到的連接來源。這可能會破壞原始信封特性的SPF ，而完好無損。 DKIM簽名 繼續驗證。這是在擴展SPF權限之前檢查路由的原因之一。 SPF轉發注意事項在中討論 RFC 7208 ，第 10.3 節.
首先確定受影響的訊息是直接發送還是透過中介發送。比較直接樣本和轉寄樣本，包括它們的信封身分、接收邊界和DKIM結果。如果對齊的DKIM簽章仍然存在，則DMARC通行證是可以解釋的。
不要僅為了消除故障而在網域的SPF中授權大量轉送系統。這樣的改變可能不會解決在轉送的路由上評估的身份，並且可能不必要地擴大發送權限。記錄特定於路由的說明並單獨調查意外的直郵失敗。
當DKIM失敗但SPF承載訊息時
直接訊息可能具有通過的對齊SPF身份，但其DKIM簽章失敗。檢查簽名域並 選擇器、金鑰可用性、簽章診斷以及閘道是否更改了簽章內容 RFC 6376 §3.7。簽章失敗本身並不能證明訊息被修改；金鑰、簽章值和實作問題也是可能的。比較您有權這樣做的可疑修改點之前和之後採集的樣本。
DMARC通行證不會使DKIM故障變得無害。不同的路由可能不會保留SPF路徑。稍後的基礎架構變更可能會暴露依賴性。使缺陷在發送者的操作記錄中可見，而不是將其隱藏在總通過率後面。
還有一個標準差： RFC 9989 規定SPF當DMARC所有者的政策是 p=reject。該部署要求不會改變特定郵件可以透過SPF獲得DMARC傳遞的事實。看 RFC 9989 ，第 8 節。修復並驗證一致的DKIM ，而不是將孤立的通行證視為完整的部署批准。
將DMARC與提供者要求區分開來
接收提供者可能會提出超出DMARC通過條件的要求。例如，Google 的指南要求 大量寄件人 為個人Gmail帳戶設定SPF 、 DKIM和DMARC ，而直郵則必須透過SPF或DKIM來配合。這些是相關但獨立的檢查。回顧目前 Gmail寄件者指南 適用的寄件者類別。
不要根據一條經過身份驗證的訊息來承諾交付。其他要求、聲譽和內容過濾仍然適用。如果報告的問題是拒絕，請保留準確的SMTP回應，而不是假設失敗的身份驗證方法導致了該問題。
決定是否修復或記錄
透過特定操作對發現結果進行分類。預期與轉送相關的SPF故障與存活的對齊DKIM可能需要路由記錄和監控。直接生產路線上無法解釋的DKIM故障需要所有者和維修計劃。未對齊的通行證需要身份配置工作，而不僅僅是更寬鬆的策略。
對於每個受影響的工作流程，保留觀察到的成功路徑、失敗方法的原因或懸而未決的問題、支援的修正以及透過相同路徑重新測試。在任何金鑰、網關或提供者變更後執行代表性訊息。來自不同應用程式的成功測試無法解決此工作流程的問題。
使用 DKIM主體哈希指南 用於訊息修改調查和 對準失敗指南 當傳遞的身份無關時。目標是您可以解釋的結果和您可以維護的發送路線。
明確下一步的決定
對於情況A，僅在路由證據支持時記錄轉送解釋；否則，將原因留待解決。對於情況 B，分配DKIM修復而不偽造訊息級DMARC通行證。對於情況 D，保留通過簽名的精確 d=，獨立於失敗簽名。這些是分析分類，而不是觀察到的事件結果。