從接收者實際報告的內容開始
來源IP位於 總結報告 在記者的觀察中發現了一個連結系統。它不會命名撰寫訊息的應用程式、提交訊息的客戶帳戶或授權使用您的網域的人員。將 IP 標籤視為已核准的傳送服務會跳過這些單獨的決定。實際任務是將有界觀察與業務記錄連結起來，而不假裝缺少的連結是已知的。
RFC 9990於 2026 年 5 月發布，定義了報告的連接位址、訊息計數和評估的策略欄位。此處參考其目前結構。實際報告者可能會使用不同支援的報告版本；保留版本和解釋，而不是默默地將每個輸入轉換為最新的模式。本指南未匯入或測試任何客戶報告。
在豐富觀察之前保留觀察結果
保留報告機構、報告識別碼、時間間隔、策略域和相關記錄。將連線 IP 與身分和結果保留在同一記錄中。僅按地址分組的摘要可以組合不同的寄件者網域、簽名身分或結果，並隱藏重要的差異。在描述由以下內容表示的磁碟區時，使用報告的計數，而不是 XML 行數 一個記錄.
富集標籤應該是一個單獨的註釋，有自己的來源和觀察時間。如果資料庫將該位址稱為熟悉的供應商，那就是有關基礎設施的線索。不要覆蓋原始地址或用提供者的徽標替換未知的應用程式。原始報告和後來的解釋必須保持可區分性，以便其他審查者可以在不遺失潛在證據的情況下質疑歸因。格式良好的報告仍然是一種斷言，其來源需要審查，而不是所聲稱流量的獨立證據。
將身份驗證與服務權限分開
報告的原始鑑定結果及其 DMARC 評價是不同層次的。 RFC 9989 需要經過身份驗證的識別碼以與相關DMARC路徑的作者域保持一致。僅僅因為提供者是可識別的，對不相關的提供者領域的成功檢查是不夠的。相反，報告的一致通過並不表示組織的採購或安全所有者批准了該特定應用程式。
SPF 特別容易被過度閱讀。 RFC 7208 評估已定義SMTP身分的主機授權，而不是共享該郵件基礎架構的每個使用者的業務合法性。預期的服務可能已正確配置，過時的帳戶可能仍會發送，或者批准的帳戶可能已被濫用。即使身份驗證結果看起來相似，這些可能性也需要不同的證據。
完成虛構的報告而不發明發現
考慮起草之前保留的紙本範例：一個虛構的接收者報告了 24 則訊息 192.0.2.40 和 header_from= notices.example, DKIM 結盟 報告為通過， SPF對齊報告為失敗。位址和網域是說明性的，這些是選定的欄位值，而不是完整的或經過驗證的 XML 固定裝置。沒有查詢、訊息傳遞或簽名驗證產生它們。
小說中支持的結論很狹窄：這位記者描述了該分組觀察的一致DKIM路徑。不受支援的結論是 Atlas notifications 是一項已批准的服務，因為尚未提供帳戶對應、應用程式證據或業務所有者。下一步是尋找授權代表訊息和相關的服務註冊條目。該範例沒有證明將地址添加到SPF是合理的。
將地址連接到負責任的服務
提議的歸屬記錄應標識應用程式、提供者、客戶帳戶或租戶、預期目的、允許的發送網域和責任所有者。將這些條目與觀察到的信封身分和DKIM簽章域進行比較，或者 選擇器 如果有的話。提供者的網域驗證徽章是範圍有限的技術證據，而不是組織批准記錄。
提供者文件可以解釋為什麼 IP 不唯一。 Amazon SES記錄共用池和專用池，證明提供者基礎設施可以為多個客戶提供服務。這不會將虛構地址歸因於 SES。它解釋了為什麼 IP 與提供者的關聯仍然會使應用程式和帳戶懸而未決。在將候選屬性提升到核准的服務條目之前，取得特定於客戶的證據。
保持報告範圍和時間限制可見
聚合觀察並不是組織發送的每個訊息的清單。其範圍取決於報告者、期間和報告範圍。稍後間隔的服務缺失可能意味著不活動、延遲報告或缺乏可見性，而不是成功退役。來源 IP 的變更可以反映基礎設施的移動，而無需證明新的應用程序，而相同的 IP 可以稍後支援不同的帳戶。
保留每個支援工件的日期。目前的DNS答案或註冊表標籤無法自動重新建立舊報告的條件。如果時間不同，請說明哪些是歷史記錄以及哪些是後來檢查的。擬議的決策記錄應保留未解決的矛盾，包括企業主認可該申請但無法確認帳戶或觀察到的發送身分。
使分類成為明確的審查決定
使用揭示已知內容的狀態：已觀察但未歸因、候選服務、已驗證的服務映射、已批准的使用或升級的關注。這些是建議的工作流程標籤，而不是EmailAuth功能。批准應指定允許的目的和身份，而不僅僅是提供者名稱。發現不熟悉的流量既不會授權生產DNS更改，也不會允許與外部方分享完整報告。
確切的攝取條件仍然可見且開放：驗證當前的主要規格並在起草之前保留工作範例。保留了主要標準和虛構的論文範例，但它們不滿足委託的原始證據：經過編輯的從報告到決策的演練，其中包含來源欄位、分類不確定性和下一步行動。此包中不存在任何客戶決定或批准。技術審查必須評估最終證據，授權所有者必須接受服務分類，然後才能將其視為營運事實。