開始一個 DMARC 使用一條可重複的訊息和精確的症狀進行調查。 「郵件損壞」可能意味著驗證結果對齊失敗、策略格式錯誤、 SMTP事務被拒絕或儘管通過了DMARC ，但郵件仍被發送到垃圾郵件。這些情況沒有相同的補救措施。
更改DNS前保留證據
記錄受影響的寄件者網域、傳送應用程式、收件者、時間和確切的錯誤。發生傳送時取得收到的原始來源，或未發生傳送時取得SMTP回應和寄件者日誌。對待 Authentication-Results 僅當其來源屬於您正在調查的接收邊界時才值得信賴。保留經過編輯的工作副本，並限制原始版本（如果其中包含個人資料）。
建立一個身分錶，其中包含可見的來自網域、SPF 評估的身份和結果，每個 DKIM d 和 s 值和結果，以及接收方的DMARC結果。添加 結盟 與該觀察相關的模式和政策資訊。目前的DNS很有用，但它無法證明解析器在最近更改之前看到了什麼。
從症狀中選擇下一項檢查
如果 SPF 透過且DMARC失敗，請在編輯SPF之前將SPF身分與 From 進行比較。不相關的包絡域的頻道未對齊。然後檢查每一個 DKIM簽名 用於經過對齊的路徑。
如果DKIM通過且DMARC失敗，請將其 d 域與 From 進行比較並確認適用的對齊模式。不要混淆 選擇器 與簽章域。接收者可能會評估多個簽名，因此請避免在第一個失敗的簽名處停止。
如果DKIM加密失敗，請檢查確切的選擇器記錄、公鑰和訊息轉換。遺失的鑰匙、過時的選擇器和修改後的主體需要不同的變更。如果沒有簽名，請調查出站簽名者或路由繞過，而不是發布猜測的選擇器。
如果SPF報告錯誤，請檢查實際評估的網域的策略、尋找依賴項和語法。多種的 SPF記錄 單一業主並不是一種安全的組合服務方式。不要僅僅為了通過測試而添加廣泛的地址範圍。
將身份驗證與接收者配置分開
DMARC通行證不保證收件匣的放置。如果接收者報告透過但將郵件發送到垃圾郵件，請保留該結果並調查聲譽、內容或接收者的其他控制權。相反，已送達的郵件並不能證明通過，因為收件人可以應用本地處理決策。
對於轉送或郵件清單流量，識別中介及其修改。 SPF可以在轉發時更改，而DKIM僅在簽名材料保持有效的情況下才能生存。不要僅僅因為一條間接路徑需要調查而削弱整個域的策略。
使用假設和停止條件
說明性案例：來自billing@example.org ， SPF傳遞給bounce.example.net ， DKIM傳遞給example.net 。假設這些是唯一可用的經過身份驗證的識別碼。兩個驗證結果均通過，但兩個網域均不完全符合example.org ，且不相關的網域也不提供寬鬆對齊。下一步是調查寄件者支援的一致身份，而不是將收件者新增至SPF 。這是綜合身份比較，而不是觀察到的事件。
寫下可疑的原因、提議的更改、預期的證據和回滾。更改一個相關元素，通過相同的路徑發送並比較結果。讓不相關的寄件者保持正常工作。僅當原始症狀得到解決並且代表性合法流量保持健康時才關閉事件。如果提供者或標準變更導致了故障，請保留前後證據並安排文件更新。
保留不確定的情況
如果收到的原件不可用且螢幕截圖僅顯示一個DKIM結果，請不要斷定所有DKIM路徑均已失敗或DMARC一定會失敗。請求可信接收者結果和完整的身份證據。缺少SPF結果是未知的，而不是記錄的失敗。 RFC 9989第 4.4 節及 5.3.5 節 要求評估適用的經過身份驗證的識別碼； 第 5.4 節 保持最終處理的獨特性。本範例未執行任何診斷命令或即時訊息測試。