A DMARC 名稱錯誤的TXT值可以完美寫入，但仍與您正在調查的訊息無關。在變更其策略之前，請證明接收者可以為可見寄件者地址中使用的網域發現它。
一個常見的陷阱是在應用程式作為子網域發送時測試公司網站網域。另一種方法是在附加區域名稱的DNS欄位中輸入完全限定名稱。解決方法是精確的名稱比較，然後是權威的DNS證據。
從訊息中取得查找名稱
從受影響的工作流程中取得收到的訊息並識別其寄件者地址中的網域。對於來自notices@billing.example.com的合成訊息，初始策略發現會在_dmarc.billing.example.com處查詢TXT 。 一個記錄 在example.com 、 www.example.com或發送供應商的不相關網域不是相同的查找。如果初始查找未找到有效策略，則可以根據適用的DMARC規則繼續發現。 RFC 9989 ，第 4.10.1 節.
不要替代 Return-Path 可見域的域。在下面 RFC 7208 §2.4，信封身分很重要 SPF，但它無法確定此初始DMARC策略查找。在診斷問題時，將兩個欄位保留在單獨的欄位中。
在開啟DNS編輯器之前寫入預期的絕對所有者名稱。這一小步驟可以防止 UI 標籤成為事實來源。
尋找權威區域和輸入模型
確定哪些 名稱伺服器 目前服務於相關區域。註冊商帳戶、託管儀表板或先前使用的DNS服務可能會顯示不再具有權威性的記錄。如果billing.example.com已被委託，請在編輯父區域之前確定誰控制該子區域。
檢查編輯器的說明中的“名稱”或“主機”欄位。有些介面接受相對名稱；有些接受全名並將其規範化。區域文件約定並不是對 Web 表單的承諾。在DNS主檔案中，以點結尾的名稱是絕對名稱，而相對名稱則使用目前來源進行解釋。 RFC 1035 ，第 5.1 節.
作為記錄的 UI 範例， Cloudflare的當前記錄工作流程表示選擇記錄類型並填寫必填字段，這些字段因記錄而異。使用提供者的當前記錄指令並驗證已儲存的結果，而不是將其他提供者的現場行為投射到其上。 Cloudflare DNS記錄管理.
解決重名案件
考慮為區域example.com配置的說明性編輯器，該編輯器將區域附加到每個相對名稱值。輸入_dmarc.example.com作為相對值將建立_dmarc.example.com.example.com 。指向該意外名稱的驗證器可以找到記錄，而預期的_dmarc.example.com查找卻找不到記錄。
明確比較三個項目：
- 預期的絕對所有者： _dmarc.example.com 。
- DNS服務或區域匯出顯示的已儲存擁有者。
- 權威TXT答案適用於預期名稱和疑似意外名稱。
如果錯誤名稱的答案包含預期的政策，請將其保留為證據。在目標擁有者處發布或更正已批准的記錄，注意不要在那裡引入第二個DMARC候選人。在檢查錯誤記錄沒有單獨的預期用途後，透過正常的變更控制將其刪除。不要將本文中的範例名稱視為您的生產域。
驗證修復情況，沒有虛假的截止日期
向權威服務機構詢問確切的所有者和記錄類型。然後比較遞歸解析器的答案，注意時間戳記、回應狀態和 TTL。如果預期的名稱先前不存在，負緩存可以在其剩餘生命週期內繼續傳回較早的結果。新選擇的正TXT TTL 不會擦除舊的負緩存。 RFC 2308 §3, RFC 2308 §4 和 RFC 2308 §5.
在 TTL 到期後，合格的過時答案的使用可能會繼續 RFC 8767 §4，因此 TTL 不是全域收斂期限。儀表板保存通知確認表單操作，而不是全域可見性。同樣，正確的公共DNS答案並不能證明您的服務使用一致的網域對郵件進行簽署。透過原始路由發送新訊息並檢查接收系統的可信任結果。
與郵件身份驗證分開解決命名問題
在更改記錄中保留原始所有者名稱、更正的所有者、批准的值和測試時間戳記。如果DMARC現在適用但訊息失敗，請繼續 身份和對齊診斷。這就是進展：可以找到記錄，剩下的問題屬於發送路徑。
如果接收者仍然發現不同的策略，請比較他們觀察到的來自網域、 DNS答案和實作行為。不要僅僅為了讓兩個不相關的檢查者同意而在名稱之間不斷移動正確的記錄。
記錄可以審查的決定
對於雙名燈具，在更改TXT值之前比較預期名稱和已儲存的絕對名稱。在意外所有者處找到的有效策略並未表明預期的初始查找找到了它。保留意外記錄作為證據，然後採取單獨批准的糾正和清除措施。這是一個說明性編輯器模型，並不聲稱Cloudflare以這種方式附加名稱或進行了任何DNS更改。