出版 p=reject 是一個政策里程碑，而不是終結 DMARC 營運.發送服務發生變化，新的應用程式出現，接收者保留自己的處理決定。聚合報告仍然有助於識別身份驗證回歸、新觀察到的來源以及請求的策略和報告的處理之間的差異。
策略變更後保持報告配置和監控。適用性仍然取決於網域的使用： RFC 9989 §7.4 注意不要拒絕其使用者可能向 Internet 郵件清單發佈的網域，並要求拒絕網域使用有效的 DKIM 而不是僅僅依靠 SPF。證據仍然受到參與接收者及其觀察的限制。拒絕策略並不能證明每個冒充嘗試都被封鎖或每個合法訊息都已傳遞。
分別閱讀政策、評估和處置
參考： RFC 9989 §4.7, RFC 9989 §5.4, RFC 9990 §3.1.1.9, RFC 9990 §3.1.1.11.
已發布的策略表達了網域擁有者對未通過DMARC郵件的處理請求。評估會詢問經過驗證的SPF或DKIM識別碼是否與作者域一致。報告的處置描述了接收者報告的 DMARC 相關處理，並提供覆蓋資訊（如果提供）。
這些欄位不應折疊為一種狀態。 一個記錄 在 disposition none 旁邊顯示p=reject不會自動出現格式錯誤：訊息可能已通過，或接收方處理可能與請求的操作不同。檢查一致的結果和可用的原因，而不是僅根據政策進行猜測。 RFC 9989 保留接收者的自由裁量權，並且 RFC 9990 定義聚合字段。
留意合法路由迴歸
參考： RFC 9989 §5.3.5.
維護應用程式和擁有者的維護清單。將目前觀察結果與其預期身分進行比較，並調查發生變化的情況 選擇器, 回程路徑 或在使用者報告遺失郵件之前建立網域。包括可能長時間不可見的低運量和季節性路線。
說明性案例：先前驗證的計費應用程式遷移到新平台並失去其一致性 DKIM簽名。 SPF仍然在不相關的服務域下傳遞。假設適用的有效政策並已完成檢查。如果沒有另一個對齊的傳遞路徑，該綜合範例中的消息將無法通過DMARC 。有用的回應是修復受支援的寄件者身份，而不是假設強制執行使未來的加入變得不必要。
解釋持續的未經授權的故障
即使在強制執行後，未經授權的寄件者也可能繼續使用「寄件者」中的網域。報告可以顯示觀察到的失敗身份驗證和接收器對該流量的處理。持續的失敗量並不能證明執行是無效的；控制可能會拒絕繼續到達的流量。
相反，不要將每次失敗都視為已確認的已阻止攻擊。歸因、意圖、接收者涵蓋範圍和實際處理需要證據。報告計數是觀察計數，報告的處置並不是完整的下游交付審核。
協調例外情況和缺失的覆蓋範圍
參考： RFC 9990 §3.1.6, RFC 9990 §4, RFC 9989 §5.3.8.
查看失敗郵件收到與所請求政策不同的處理方式的記錄。調查提供的覆蓋原因和相關轉發或中介行為。不要假設每個接收者都應用相同的本地策略，或者每個異常都有足夠的解釋 總結報告.
檢查報告管道本身：目的地所有權、需要的外部授權、攝取錯誤以及貢獻接收者的變更。強制執行後儀表板靜默可能反映了收集問題。對關鍵路線進行受控測試，並在調查交付時將接收者證據與應用程式日誌進行比較。
保持執法後運作節奏
分配新寄件者加入、定期庫存審查、 DNS更改和報告分類的責任。對任何臨時政策放寬使用批准和到期流程。驗證提議的更改是否解決了受支援的原因，並且不會不必要地影響不相關的寄件者。
透過測試合法路線、調查未知來源、檢查接收器偏差以及仍然存在的報告差距來結束每次審查。 p=reject後的目標得以維持，可解釋的身份驗證覆蓋範圍。僅靠政策字串無法提供這種保證。
約束結論與下一步行動
對於虛構的平台遷移，請在不相關的服務身分下保留原始SPF通行證，與遺失對齊的DKIM分開。必須在受影響的路由上測試稍後支援的簽名修復。報告的無處置仍然處理證據，而不是身份驗證已恢復或收件匣收到訊息的證據。