詢問擬議的升級實際上改變了什麼
聲稱平台提供 DMARCbis 升級應確定目前標準、正在更改的實施行為以及更改有效的證據。不應將其作為將DNS記錄切換到發明的請求而接受 DMARC 版本。保留電流 RFC 9989 仍指定區分大小寫的版本值DMARC1 。新標準文件和新實施版本與已發布政策中的新版本令牌不同。
本文提出了與標準相關的準備審查。它沒有聲稱EmailAuth實現 RFC 9989 完全，每個接收器都採用了它或進行了升級。沒有更改DNS記錄、解析器、接收器或生產配置。在任何人批准推出之前，審查應將規範變更、供應商實施聲明和觀察到的互通性分開。
拒絕版本切換快捷方式
RFC 9989的策略記錄定義規定，版本標記的唯一可能值是DMARC1 ，否則不同的版本值會導致記錄在指定處理下被忽略。因此，發布v=DMARC2的提案並不是此 RFC 中基於標準的遷移指令。要求提議者確定支援任何建議的記錄變更的確切部分，而不是依賴產品標籤。
同樣的注意事項也適用於重命名儀表板設定。稱為DMARCbis的設定可以啟用解析器功能、策略發現演算法或報告解釋，但其意義在記錄之前是特定於產品的。記錄實際支援的行為、發行版本和限制。不要推斷切換設定會更新外部接收器、正確重寫每筆記錄或驗證所有合法的傳送工作流程。
盤點相關標準變化
使用RFC 9989的變更討論和規範部分來建立有重點的清單。一個重要領域是基於 DNS 的策略和組織域發現，包括 DNS樹漫步。這是一種實現行為，而不僅僅是插入現有記錄的新字串。聲稱支持的供應商應解釋哪些發現和 結盟 它處理的案例並為實際產品版本提供範圍證據。
另一個明確的變化是從目前規範中刪除 pct 標籤。附錄 A.6 解釋了歷史並介紹了具有值 y 和 n 的測試標籤 t，在應用中被描述為與先前的 pct 值 0 和 100 類似。這並不能證明對每個歷史百分比值進行全面機械替換或承諾每個接收器都實現新行為是合理的。在提出策略差異之前，請檢查目前確切的語意和相關的部署群體。
將協議要求與提供者資格規則分開
提供者可以發布參考現有部署約定的產品資格要求。這些要求需要自己當前的原始碼審查，並且不應因為協議文件發生更改而默默地重寫。相反，歷史提供者指令不會重新定義RFC 9989的規範內容。記錄明顯的差異、來源日期和需要解決的實作問題，而不是假裝兩層是相同的。
本手稿並不聲稱通用接收器支援測試標籤、樹行走行為或任何其他修訂功能。準備評估必須確定組織控制哪些組件以及外部組件。發送者只能在支援的範圍內更新自己的實作或策略；它不能強制所有接收系統升級。因此，相容性結論需要經過論證的、有限的證據，而不是全球採用的假設。
單獨的報告標準和解析器準備情況
RFC 9990 將DMARC聚合報告定義為單獨的規範。平台的策略評估器和報告攝取解析器可能有不同的升級需求。詢問支援哪些報告格式、欄位和驗證行為，以及舊的保留報告如何保持可解釋性。不要假設更改策略發現實施會自動更新每個報告工作流程或歷史分析。
固定產品版本並保留用於評估的標準參考。如果解析器遇到不支援的欄位或報告變體，則應記錄和測試其行為，而不是默默地解釋為零活動。保留原始報告出處，並將缺失的觀察結果與驗證結果區分開來。本文沒有使用報告解析器，也沒有將測試裝置表示為實際的接收器報告。
建構標準到實施矩陣
每個相關要求建立一行，包括 RFC 部分、規範行為、目前產品行為、建議的變更、受影響的元件、證據參考和未解決的限制。單獨的發送者策略發布、接收者評估、組織域發現、報告產生和報告攝取。平台可能只執行其中一些角色，因此不支援的角色應標記為超出範圍，而不是算作透過暗示實現。
新增現有有效策略、無效版本值、發現邊界、對齊關係和報告相容性（如果適用）的代表性案例。確切的裝置應由合格的評審員根據規範文本和產品支援的角色進行設計。該草案沒有提供實施一致性套件，也沒有聲稱一小部分示例可以證明完全合規。每個觀察到的結果都需要保留輸入、產品版本和預期行為。
將任何記錄變更與寄件者準備情況聯繫起來
如果評估建議更改DNS策略，請準備準確的差異、所有權記錄、業務批准、驗證計劃和回滾標準。透過寄件者準備矩陣保持合法的發送工作流程可見。標準升級並不能證明每個供應商都具有一致的身份驗證或每個關鍵工作流程將繼續不受影響。請勿使用新的實施標籤作為跳過操作準備的理由。
記錄變化可以顯示什麼和不能展示什麼。權威的DNS證據可以顯示特定時間的發布；可信賴的接收訊息證據可以顯示範圍內的身份驗證結果； 總結報告 可以在其保留的覆蓋範圍內顯示模式。沒有一個能夠單獨建立通用的互通性。回滾規劃必須考慮快取狀態和外部實作差異，而不僅僅是恢復舊設定檔的能力。
虛構診斷：請求的 DMARC2 記錄
虛構的供應商提出升級並告訴買方將策略的版本值改為 DMARC2。買家詢問標準參考，發現RFC 9989仍指定DMARC1 。提議的版本切換因不受支援而被拒絕，而更廣泛的實施審查仍在繼續：供應商可能對需要單獨證據的發現或報告行為進行合法更改。
團隊將請求一個範圍內的準備矩陣並展示實際產品發布的結果，而不是根據其行銷名稱接受或拒絕整個升級。這是虛構的審查活動，不是真正的供應商指示或觀察到的生產缺陷。沒有發布任何記錄，也沒有測試任何接收器。此範例展示了精確的標準問題如何將錯誤的捷徑與潛在有用的實作工作區分開來。
在呼叫升級完成之前需要一個演示範圍
一個有用的結論確定了實施的與標準相關的變更、涵蓋的角色、保留的證據以及仍然未知的外部相容性。不應該說該組織現在使用第二版或所有接收器行為統一。此次升級是實施和準備評估，而不是通用開關。
該目錄要求進行與標準相關的準備評估並展示範圍內的實施結果。這些原始結果仍然開放。人類專家審查、來源適用性、生產路線、可訪問性和所有者發布也保持開放。本草案提供了審查方法和虛構範例，而不是一致性證據、已部署的遷移或完整的EmailAuth支持的聲明。