在收集內容之前確定診斷需要什麼
故障報告 可以公開有關單一訊息的信息，這與 總結報告 總結觀察組。更新收集管道 RFC 9991 因此，從必要性決定開始：哪個診斷問題需要特定於訊息的證據，誰可以接收它以及實際需要什麼資料？首先啟用收集，然後再決定保留可能會建立不必要的私人信件儲存。
DNS中的請求並不能保證接收者產生報表。 RFC 9991第 2 節和第 7 節 描述接收者意願、政策限制和重大隱私問題。缺失的報告並不能證明不存在身份驗證失敗。保持覆蓋範圍的不確定性可見，而不是將沉默視為乾淨的健康證明。
精確映射更新的格式
RFC 9991更新了源自RFC 6591故障報告格式。其第 4 節要求 Identity-Alignment，並有條件地要求 DKIM-Domain、DKIM-Identity 和 DKIM-Selector DKIM 對齊標識符或 SPF-DNS 的失敗 SPF 對齊標識符失敗。交付結果是可選的。欄位地圖應該保留這些條件，而不是要求每個報告中的每個欄位或發明缺失值。
身份對齊的含義很容易逆轉：它列出了未能驗證對齊身份的機制。值 none 表示所有嘗試的方法都成功驗證了一致的身份。這並不意味著沒有 結盟 資訊存在。 RFC 9991第 4 節 提供權威定義；實施者應在附加簡化的儀表板標籤之前比較實際輸入和結果類型。
保持 DMARC 故障報告與特定於機制的DKIM或SPF報告不同，接收者可以根據自己的策略和適用的報告選項進行選擇。收集器應在解釋欄位之前識別報告類型。意外組合值得記錄驗證決策，而不是靜默轉換為通用DMARC失敗計數。
將目的地驗證視為多項控制中的一項
失敗報告請求使用 ruf 和相關 fo 選項。對於外部目的地， RFC 9991第 5 節 要求驗證程序 RFC 9990第 4 節，在適當的情況下用 ruf 代替 rua。這可以防止強行向不情願的目的地報告；它沒有建立公開底層訊息內容的組織許可。
記錄實際接收單位、用途、傳輸路線和核准的資料範圍。組織表觀域內的地址仍可能轉送給第三方。透過授權的管理證據追蹤該路線，而不是根據拼字假設目的地是內部的。更改的報告地址需要技術驗證和適當的共享決定。
該規範也限制在psd=y的記錄中考慮 ruf，除非存在特定協定。不要將一個網域所有者的請求概括為允許公共後綴運營商收集其他人的失敗內容。報告產生、接收者授權和個人資料處理仍然是不同的問題。
儲存和展示前設計最小化
RFC 9991第 7 節 解釋說報告可能會暴露標題、正文內容、標識符和以前隱藏的目的地。有關意外失敗的合法消息的報告可能特別敏感。選擇最小的診斷欄位集、較短的合理保留期和需要存取的角色。這裡沒有規定通用的保留期限。
密文可以減少曝光，但不應宣傳為保證匿名。在地址本地部分被刪除後，主題、路由細節或引用的片段仍可保持標識。追蹤所應用的轉換、保留的欄位以及診斷的結果。如果必須保留原始位元組用於單獨批准的目的，請將它們與普通分析人員視圖和匯出隔離，而不是將它們複製到每個日誌中。
將附件和報告文字視為不可信材料。防止自動渲染或執行嵌入內容，並套用攝取限制和安全顯示行為。 RFC 9991討論了分發垃圾郵件造成的額外損害， 網路釣魚 或報告中的惡意軟體內容。建議的收集設計不應將診斷郵箱變成不受限制的重新分發通道。
最低攝取量審查的虛構範例
在虛構的紙本案例中，報告包含 Identity-Alignment: spf 和帶有不必要的收件人地址的標頭材料。建議的現場地圖記錄失敗的對齊SPF機制，並僅保留定義的調查所需的診斷數據。受限證據引用取代了普通案例視圖中的完整標頭轉儲。
然後，審閱者詢問保留的欄位是否仍支援所述問題、匯出是否執行相同的限制以及刪除是否到達派生副本。這些是建議的驗收檢查。本次練習沒有收集、編輯、傳輸或刪除任何報告，且發明的欄位值沒有建立真正的接收者支援。
第二個計劃檢查涵蓋可選字段的缺失。收集器應將遺失的 Delivery-Result 表示為不可用，而不是成功傳遞。這保留了不確定性，並避免將隱私最小化的報告轉化為不受支持的操作結論。
保持產生和收集限制可審查
該規範要求限制傳出報告速率，第 5.1 節建議與 DMARC 一致的報告流以降低循環風險。收集器也應該定義自己的有限攝入量和警報行為。在限制範圍變化範圍內收到較少的樣本；它不應該默默地改變用來描述失敗的分母。
最初的大門仍然開放：將RFC 9991映射到收集管道並審查最小字段、編輯和訪問行為。調試要求逐字保留：驗證當前的主要規格並在起草之前保留工作範例。提供了紀錄片地圖和虛構案例，但沒有測試真實的管道、隱私控製或存取行為。人工技術/隱私審查、所有者批准和發布授權仍然是必要的。