整體較高 DMARC 通過率可能與損壞的關鍵業務服務共存。較大的流主導演算法，而較小的流可能攜帶密碼重置、發票或緊急警報。在使用標題率批准更改之前，請單獨審查已知的合法服務。
定義通過的內容
參考： RFC 9989 §5.3.5, RFC 9990 §3.1.1.9, RFC 9990 §3.1.1.8, RFC 9989 §5.4.
使用 DMARC 評估的對齊結果而不是原始結果 SPF 或者 DKIM 獨自成功。透過適用的有效策略和已完成的檢查，透過一種對齊機制足以實現訊息層級DMARC通行證；兩者都需要創建不同的指標。處置是獨立的：訊息可以在接收者異常下進行處理，而不會成為身份驗證通行證。
按訊息計數對行進行加權。代表數千個觀察值的單一健康行和代表十個觀察值的失敗行並不是同等大小的群體。將速率標記為適用於收集的觀察結果，而不是發送的每個訊息。
拆分已批准的發送庫存
使用提供者配置、已知路由和授權訊息樣本將觀察到的身份對應到服務。來源 IP 本身可以被共用或代表轉發器。保留未分類的流量，而不是根據猜測分配所有權。
對於每項關鍵服務，記錄觀察到的數量、對齊的通過和失敗計數、接收器覆蓋範圍和最新測試結果。將未知和可疑的未經授權的流量與經過驗證的合法群體分開。分類變更應註明日期，以便排除不方便的數據而導致比率提高。
檢查小溪
說明性案例：行銷服務有 99,900 個通過的觀察結果，密碼重設服務有 100 個失敗的觀察結果。綜合通過率為 99.9%，而觀察到的密碼重設通過率為零。總費率在數學上是正確的，但在操作上並不完整。
這並不能證明每次密碼重設都被拒絕，或來自該服務的所有訊息都到達了報告接收者。它確實證明了立即進行路線級調查的合理性。檢查當前的原始訊息、一致的身份、提供者設定和相關網關，而不是慶祝總體百分比。
圍繞影響設置決策門
使用整體利率作為背景，然後在收緊政策之前需要關鍵服務的證據。沒有觀察的小批量服務需要測試或記錄差距，而不是假設的通過。根據業務影響、合法性信心和當前失敗證據確定修復的優先順序。
透過新的端到端測試和後續報告觀察（如果可用）來解決服務問題。將總指標和服務視圖保留在操作報告中。有用的摘要使重要的異常可見，而不是讓健康的體積隱藏它。
讓異常情況在營運審查中可見
列出每個關鍵服務及其所有者、預期身份、觀察到的故障和當前調查狀態。即使在四捨五入的情況下也顯示計數會使整個圖表看起來完美。包括最新成功的受控測試及其未進行的任何路線。所有者應該明確接受剩餘的差距，而不是允許未分類的服務從審查中消失。在寄件者或範本變更後進行檢查，因為較早通過的樣本無法確定新修改的路由仍然正確簽署和對齊。
繼續調查
使用 總結報告演練 解釋底層欄位和 對準診斷指南 當原始身分驗證通行證不滿足DMARC時。
保持決策的界限
本地計算得出 99,900 / 100,000 = 99.9% 的總體通過率，0 / 100 = 0%（假設的密碼重設佇列）。我們立即決定調查該關鍵路線，而不是推斷拒絕所有 100 條訊息。這些是發明的教學計數，而不是客戶遙測。