DMARCbis 改變部分的方式 DMARC 被指定並實施。它不會要求您將記錄重新命名為 DMARC2。核心規格， RFC 9989，發表於 2026 年 5 月，同時 RFC 9990 和 RFC 9991 分別涵蓋總結報告和故障報告。
實際任務是確定哪些變更會影響您的網域、傳送服務以及處理身分驗證資料的軟體。首先要了解目前的規範，然後將它們與已使用的配置和流程進行比較。結果應該是一份清晰的準備登記冊，其中包含證據、所有者和針對每個發現的決定。
將三種規格映射到您的系統
將目前文件用於各自的工作：
| 文件 | 要審查什麼 |
|---|---|
| RFC 9989 | 核心DMARC評估、策略發現、 結盟 並記錄語義 |
| RFC 9990 | 聚合報告格式、產生和處理 |
| RFC 9991 | 故障報告及其處理注意事項 |
從現有記錄和配置歷史記錄開始。不要因為舊指南引用了操作記錄就刪除操作記錄 RFC 7489。確定已更改的指令以及實現這些指令的軟體。
主要審查領域包括以下內容：
- 域發現： RFC 9989第 4.10 節 定義DNS樹遍歷。查看採用較舊的公共後綴列表發現模型的系統。
- 政策標籤： 檢查目前的IANA註冊表。這
百分比,射頻和裡標籤是歷史性的。評估t,NP和PSD根據它們的實際範圍，而不是將它們添加為升級清單。 - 測試： 確定相關評估者如何實現二進位文件
t訊號.聲明的測試狀態和接收者的最終處置是不同的觀察結果。 - 報告： 確認收集器和解析器處理您期望收到的報告格式和字段，而不會遺失相關的遺留觀察結果。
版本標記仍然存在 v=DMARC1。請勿替代 DMARC2 或用測試標誌機械地取代舊的百分比。
將更改的標籤翻譯成測試
這 t 標誌預設為 n，請求將聲明的評估應用於DMARC故障。環境 t=y 表明業主正在測試而不是要求直接應用申報的評估。 RFC 9989第 4.7 節 定義了失敗郵件的一級減少：拒絕變為隔離，隔離變為無。實作也可能有相關的特殊處理。
此標誌不會將失敗的身份驗證結果變更為通過、變更報告產生或影響無策略。它是二進制的，而不是對任意百分比的郵件進行採樣的請求。在依賴實際流量之前建立實作支持，並將接收器本地過濾與策略層級測試結果分開。
另外兩個標籤會影響評估範圍：
- NP： 指定對目前不存在的子域的評估 組織域。如果不存在，則適用的後備為 sp（如果存在），否則為 p。一個失蹤的 MX記錄 單獨並不能證明不存在。
- .psd： 標記發現期間使用的域邊界資訊。預設 u 將邊界確定留給發現規則； y 標識公共後綴，而 n 標識其自身及其子域的非公共後綴組織邊界。在未確定其正確描述域的情況下，請勿設定任一明確邊界值。
普通組織不應僅為了聲稱準備就緒而將其域名標記為公共後綴。檢查實際的發現假設和委託的命名空間。這 子網域政策指南 涵蓋範圍較窄的繼承問題。
確定必須繼續工作的郵件
網域可能不僅僅代表員工電子郵件。它可以出現在發票、登入連結、客戶警報和外部機構發送的訊息上。標準更新是在倉促的配置變更破壞這些依賴關係之前檢查這些依賴關係的機會。
要求提供三項可交付成果：使用您身分的服務清單、對影響您的特定變更的解釋以及關鍵訊息的測試計劃。答案應該將已發布的規範與特定接收器或軟體服務已經部署的功能區分開來。
分配所有權和預算。報告處理變更需要有人負責報告管道。無法正確驗證的寄件者需要其企業所有者的參與。將這兩個項目稱為DNS升級隱藏了工作。
建立準備登記冊
以下是說明性規劃登記冊，而不是對真實域的評估：
| 尋找 | 需要工作 | 完成的證據 |
|---|---|---|
| 推出說明採用百分比抽樣 | 使用下面的受控裝置測試二進位標誌 | 記錄申報評估、測試標誌後評估和獨立接收者決定 |
| 報告解析器採用遺留模式 | 檢查接受的格式、欄位和錯誤處理 | 對有效的、遺留的和畸形的燈具進行版本控制 |
| 關鍵應用程式沒有已知的所有者 | 建立業務服務和支援的身份 | 指定擁有者和已驗證的收到訊息樣本 |
| DNS編輯器由外包團隊控制 | 同意批准和恢復責任 | 準確的變更預覽、批准和恢復材料 |
以下綜合裝置指定了實施RFC 9989受控評估器的預期結果。它們是測試輸入，而不是生產記錄範本或已執行的測試。假設發現有效的適用策略且測試訊息未通過DMARC 。
| 夾具 | 輸入 | 預期政策層面觀察 |
|---|---|---|
| 測試標誌 | p=reject; t=y | 驗證仍然失敗； t=y後的評估是隔離，而不是聲明拒絕 |
| 沒有標記 | p=none; t=y | 此標誌使無評估和報告生成行為保持不變 |
| 不存在的孩子 | 流行的組織域策略p=none; sp=quarantine; np=reject,默認t=n;孩子被確定為不存在並且沒有直接政策 | 適用的子評估被拒絕，而不是現有子 sp 值 |
分別擷取評估者版本、輸入、觀察到的驗證、選定的評估和任何最終處理。受控夾具建立測試的行為；它並不能證明每個網路接收者都執行相同的規則。政策層級的隔離觀察並不是垃圾郵件資料夾放置的普遍承諾。
也要審查政策的適用性。 RFC 9989第 7.4 節 建議不要拒絕通用電子郵件網域，因為合法的間接路由（包括郵件清單）可能會中斷。在提出更強有力的政策之前，準備審查應確定這些路線並評估適用的互通性指南。
將組態變更與軟體或流程變更分開。有些發現不需要立即進行DNS編輯。其他則需要提供程式更新、解析器修復或受控實作測試。
檢查互通性和準備聲明的限制
準備情況聲明應指定其範圍。它是否涵蓋網域組合、策略評估器、報告處理器，或僅涵蓋 一個記錄 查看？這些是不同的評估。
使用暫存器來追蹤實作版本和未解決的差異。從現有和不存在的子網域、對齊模式、間接郵件和DNS故障中選擇適用的案例。
將接收者的自由裁量權視為營運模式的一部分。規範的發布並不會使每個接收器的行為都相同。已發布的拒絕首選項也不能證明每個收件人都拒絕了每個失敗的訊息。
對受損帳戶、欺騙性顯示名稱、相似網域名稱和敏感業務核准保持獨立控制。 DMARC準備不會將網域身份驗證轉變為對郵件內容安全性的判斷。
進行並驗證所需的更改
在生產變更之前，保留先前的狀態，識別受影響的流程，獲得適當的批准並定義恢復條件。然後透過完整的發送路徑驗證已發布的配置和代表訊息。
如果結果與預期行為不一致，請暫停向其他網域的擴展並解決或明確接受相容性發現。
對於基礎身份，請使用 對準診斷指南。對於初始配置，請遵循 DMARC建立和驗證工作流程。對於報告層，使用 總結報告演練.
實用的外賣
當每個適用的發現都有所有者、支持的決策和可重複的證據時，結束評估。保持未解決的實施差異可見，驗證關鍵訊息和報告處理，並保留已批准的恢復條件。就緒標籤應指向該記錄，而不是替換它。