報告可以顯示已發布的拒絕策略，而無需報告拒絕。在解釋處置之前閱讀報告簡介：當前 RFC 9990 定義訊息傳遞的 pass DMARC 在強制策略下，而較舊的報告不能使用任何內容來傳遞訊息。將策略情境、身分驗證結果和處理決策解釋為不同的證據。他們的關係，而不是單一領域，解釋了需要調查的內容。
首先讀取觀察到的配置
policy_published 記錄接收者觀察到的報告策略領域的策略配置。這是歷史報告證據，而不是新的DNS查找。如果您今天查詢DNS ，請將結果和時間戳分開。策略可能在報告的時間間隔期間或之後發生了變化。
RFC 9990允許在一段時間內配置發生變化時進行多次報告；否則，記者應注意最終觀察到的配置。因此，一個策略快照不能總是解釋每一個訊息時間條件。在指責記者不一致之前，保留時間間隔並更改歷史記錄。
評估作者域和對齊路徑
一個記錄的 header_from 提供作者域。當子域依賴另一個域的策略時，它可能與策略域不同。確定適用的策略關係，而不是假設每行都單獨使用頂級 p 值。
policy_evaluated 下的 dkim 和 spf 值描述與 DMARC 相關的識別碼評估。它們與 auth_results 下的原始結果不同。通過的對齊路徑可以滿足DMARC ；不相關的傳遞身分不能。透過DMARC郵件不會因為網域發布而成為策略拒絕候選者 p=reject.
讀取具有覆蓋原因的處置
說明性目前概況案例一：policy_published 顯示p=reject,已對齊 DKIM 通過，並且處置通過，如RFC 9990附錄 A 中所述並在附錄 B 中說明。情況二：兩條對齊的路徑都失敗，但由於本地策略原因，處置仍然沒有。該報告描述了接收器覆蓋，而不是修復的身份驗證結果。分別保存故障和原因。
RFC 9990需要一個理由 結盟 失敗且套用的策略與配置的策略不符。應標記缺失或意外的資訊以供調查，而不是用虛構的解釋來填充。原因字串是記者的解釋，可能仍需要證實。
這些案例是綜合的。無處置或通過的身份驗證結果都不能證明收件匣放置情況。其他過濾和傳送決策可以存在於報告描述的DMARC處理之外。
有條不紊地調查真正的不匹配
將報告的周期、遵守的政策、作者域、對齊模式和原始識別碼與您的DNS更改日期和受控訊息證據進行比較。確認寄件者是授權的業務路線。如果報告內部仍然不一致，請保留 XML 並記錄不確定性。
不要僅僅為了使儀表板的標籤一致而削弱域策略。修復存在驗證發送缺陷的問題；單獨記錄接收器覆蓋和報告限制。結果應該是另一個管理員可以從相同欄位複製的敘述。
比較兩個顯式現場夾具
兩個部分合成地圖均使用當前RFC 9990報告配置文件和策略域以及brand.example 、 p=reject,寬鬆對齊和紀元間隔 1704067200–1704153600（2024 年 1 月 1 日 00:00 至 20024 月 202020 年 UTC首先， count=25,原始 SPF vendor.example的通行證和brand.example /selector billing1 的DKIM通行證。計算出的比對結果是SPF失敗， DKIM通過； DMARC通過。所提供的配置已通過目前RFC 9990報告設定檔。
在第二個中， count=4並且兩個原始機制都通過了vendor.example ，其中 DKIM選擇器 v1。兩個身分均未對齊，因此計算的DMARC結果失敗。提供的配置仍然是 none，並附有原因類型 local_policy 和明確合成註釋“可信任轉發器處理異常”。這個原因解釋了虛構的處理而不改變失敗的對齊。
現場比較解釋了兩種認證結果；第二個例子明確地提供了一個原因。這些部分字段地圖不是完整的 XML 或即時觀察。接收者的處理決定是一個輸入，而不是僅從認證推斷出的結果。
選擇下一步行動
- 對齊傳遞加上目前設定檔處置傳遞（或舊設定檔無）：對該傳遞訊息不要求DMARC拒絕；如果需要，請單獨調查交付情況。
- 兩條對齊的路徑都失敗且無處置：檢查覆蓋原因並確認發送者，而不是將身份驗證重新標記為通過。
- 報告與目前DNS不一致：將報告間隔與指定日期的策略變更歷史記錄進行比較。
- 缺少必要的原因：保留報告並標記無法解釋的不匹配。不要發明本地政策例外。
區分當前和遺留配置
RFC 9990附錄 A 將處置透過定義為不透過執行策略傳遞DMARC操作。它不保留任何內容，因為沒有採取任何行動。較舊的RFC 7489格式報告缺乏傳遞配置，並且無法報告傳遞訊息的任何內容。一起檢查命名空間、報告設定檔和對齊結果：沒有一個不是普遍無效的，但它不應該默默地代表目前設定檔傳遞範例。這兩個數值都不能證明收件匣的放置情況。