測試更改請求，而不更改身份驗證結果
目前的 t 標籤 DMARC 是附加到策略記錄的測試模式訊號。它不會將未經身份驗證的訊息轉換為經過身份驗證的訊息，並且不承諾傳送。其有用目的是軟化對 DMARC 失敗郵件的評估要求，同時允許相關的特殊處理。因此，部署計劃需要兩個獨立的輸出：預期的策略解釋和接收者的實際行為。
RFC 9989第 4.7 節 定義t=y和t=n,其中 n 為預設值。測試根據從 p、sp 或 np 中選擇的評估策略進行。首先確定該策略以及DMARC是否失敗。當子網域覆寫實際控制訊息時，請勿將轉換套用於任意 p 標記。
在發送任何內容之前建立六格期望
對於選定的無策略，y 和 n 都將請求的評估保留為無。對於選定的隔離區，y 不要求任何隔離，而 n 保留隔離區。對於選定的拒絕，y 請求隔離，而 n 保留拒絕。 none 結果仍然允許普通接收器過濾；它不是繞過反濫用控制的指令，也不是保證郵件將進入收件匣。
在虛構的測試設計中， _dmarc.trial.north.example一次保存一個替代記錄，每個記錄以v=DMARC1開頭，並包含一個選定的 p 值和一個 t 值。六個備選方案形成一個矩陣，而不是同時六個TXT策略記錄。同一候選名稱的多個策略記錄是一個不同的發現問題，並且會使預期的比較無效。本文沒有發布任何記錄，也沒有發送任何郵件。
為 DMARC 傳遞控制訊息保留單獨的預期結果。測試不會重寫導致失敗的結果或導致失敗 SPF 結果通過。驗證， 結盟，選定的評估和最終處置應佔據證據包中的不同欄位。否則，一張顯示「已交付」的螢幕截圖可能會掩蓋實驗本來要建立的行為。
包括特殊處理而不依賴它
測試定義允許相關的特殊處理，例如由中介機構進行現場重寫以及更軟的評估。它表示，無論是否發生特殊處理，評估減少都適用。因此，測試設計必須觀察兩個維度，而不是以可見重寫為條件來減少策略。
RFC 9989附錄 A.6 解釋歷史：不一致的百分比處理導致刪除 pct，而圍繞pct=0的有用實踐通知了新的二進位標記。該歷史並未使t=y成為流量採樣百分比或聲稱所有歷史 pct 行為都被再現。這 IANA註冊機構 現在將 t 列為活動狀態，將 pct 列為歷史狀態。註冊表項無法確定接收組織運作哪些軟體。
中間人可能會以影響以後對齊的方式改變識別碼。僅在經過批准的隱私安全測試中保留中介前和中介後訊息證據。不要僅從更改的顯示名稱或最終資料夾推斷該機制。報告應標識更改的確切欄位、更改的躍點以及下游看到的身份驗證結果。
最終拒絕仍需要接收者更廣泛的分析
標記為拒絕的矩陣單元描述了請求的評估，而不是自動SMTP結果。 RFC 9989第 7.4 節 要求接收者不要僅根據發送域的拒絕策略來拒絕。他們必須將其與其他分析結合起來，如果沒有額外的知識，則將失敗的郵件視為隔離。忽略這種差異的測試可能會錯誤地認為合格的接收器有缺陷。
同一部分強調了轉寄和郵件清單互通性風險。域發布拒絕不得僅依賴SPF來確保DMARC通行證的安全，並且必須應用有效的 DKIM 簽名。測試模式不會修復損壞的簽名或確定每個間接路由都是安全的。當實際部署依賴直接傳遞和批准的代表性間接路徑時，請包括這些路徑，而不是從單一郵箱推斷。
將接收者聲明的範圍限定為您可以保留的證據
發布的 RFC 是規範性參考，而不是每個提供者的推出公告。較舊的實作可能會忽略它無法識別的標籤，這可能會使聲明的隔離或拒絕評估不被軟化。這是需要評估的風險，而不是對指定接收者的測量結果。記錄目前提供者的聲明、可用的實際軟體版本以及支援每個相容性結論的具體觀察結果。
提議的授權運作應保留DNS策略快照和時間、準確的記錄名稱、訊息識別碼、對齊輸入、接收器回應和任何可用的報告。單獨記錄本地策略覆蓋。在受控條件下重複六單元比較，而不是一次更改多個發送變數。包括意外拒絕的停止條件並保留核准的回溯計畫；本文並未授權這些操作行為。
報告也保持獨立。 t 標籤本身不會更改報告產生。聚合請求使用 rua 和 RFC 9990 報告規則；故障回饋有其自身的條件和接收者的判斷力。缺少回饋不能證明測試標籤被忽略，而且回饋本身可能無法解釋接收者完整的最終處置推理。
誠實地讓執行之門敞開
確切的委託是：使用每個策略測試t=y和t=n並保留接收器結果。該包包含原始的六單元預期矩陣，在起草之前準備好，但沒有接收器結果。因此它不滿足該執行要求。原始證據之門仍然明顯開放，而不是被基於標準文本的兼容性聲明所取代。
在發布之前，技術所有者必須批准夾具，操作所有者必須授權任何實際測試，並且審核者必須將觀察結果與當前規格和接收器範圍進行協調。勘誤驗證、專家驗收、生產路線檢查、目視審查和出版許可仍在等待中。今天的合理結論是當前標籤要求符合要求的實現要做的事情，以及仍然需要依賴它的精確證據。