回滾會改變未來的觀察結果；它無法到達每個寄件者並刪除快取的策略。當強制政策開始延遲合法郵件時，保留確切的損壞版本並找到最快的方法使接收路徑滿足寄件者可能已經持有的策略。
在取消控制之前穩定交付
參考： RFC 8461 §4, RFC 8461 §5.1.
判斷故障是否為遺漏MX 、憑證問題、遺失 STARTTLS 支持或政策獲取麻煩。恢復先前合規的MX或修復其憑證可能比嘗試緊急全域原則撤銷更直接地幫助具有新舊快取策略的寄件者。
檢查受影響的寄件者日誌（如果有）並測試每個預期的接收候選者。如果剩餘一台符合要求的MX ，寄件者或許可以使用它。不要因為備份的DNS首選項優先順序較低就認為備份是安全的；它仍然需要匹配策略並通過傳輸驗證。
選擇修復或故意撤回
參考： RFC 8461 §3.2, RFC 8461 §8.1, RFC 8461 §8.3.
如需修復，請在變更TXT ID 之前發布已更正的 HTTPS 正文。保留先前的策略副本和 max_age 值可用於計算轉換風險。更正後的當前正文並不能證明發送者已獲取它。
對於故意刪除， RFC 8461第 8.3 節建議使用較小的 max_age（例如一天）提供服務模式 none 並更新發現記錄，然後保留相關的策略基礎設施，直到所有先前提供的策略都已過期，然後再將其刪除。計算每個版本的上次服務時間加上自己的 max_age，然後使用每個版本的最新到期時間。具有較長生命週期的舊版本可以比前一個版本更耐用。 none 策略仍然需要 version 和 max_age；該模式下不需要 mx 行。使用新的有效 ID 來宣布更改。
重現陳舊的強制案例
參考： RFC 8461 §3.3, RFC 8461 §5.
在受控寄件者中，快取僅允許mx1.example.net且 max_age 86400 的強制策略。將公共DNS和 HTTPS 變更為無策略，但最初阻止該寄件者取得更新。嘗試傳送到mx2.example.net 。儘管操作員有新的 none 主體，但舊的有效強制策略仍然排除 mx2。
然後允許刷新並捕獲不應用任何操作的發送方，或在安全隔離環境中將受控測試時鐘提前至原始快取生命週期。請勿為此測試變更生產郵件基礎架構上的時鐘。這是一個實驗室程序，不是執行的 MTA 測試;新的離線裝置僅演示狀態和最後服務生命週期算術，而不是真正的發送者快取。
關閉兩個隊列的證據
參考： RFC 8461 §8.3, RFC 8460 §4.1.
驗證沒有快取策略的新寄件者以及已知保留先前強制修訂的寄件者的行為。保留佇列結果、取得結果和策略元資料。 TLS-RPT 可以幫助識別剩餘的故障，但覆蓋範圍不完整且報告延遲。
在計劃的提款視窗期間保持 HTTPS 主機和發現可用，監控實際的交付路徑並記錄最終的刪除決定。單獨刪除_mta-sts既不是立即回滾，也不是可靠的事件復原策略。
保留的歷史證據和剩餘範圍
以下描述了保留的 2026 年 11 月 7 日觀察結果，而不是為本次審查重新運行的網路實驗。新執行的離線檢查單獨記錄。
提款計算現在包括之前提供的每個版本，而不僅僅是最新的 max_age。在執行的邏輯帳本中，A1 最後一次服務於 1000300，生命週期為 86400，B2 最後一次服務於 1000600，生命週期為 3600，C3 最後一次服務於 1000900，生命週期為 3600。它們的到期界限分別為 1086700、1004200 和 1004500。因此，計算出的刪除邊界為 1086700。即使在實驗室通告並取得 B2 之後，舊的 A1 發送方快照仍然拒絕新的主機名稱。恢復舊的相容路由對於該快照仍然有意義。這是標記的狀態和路由計算，而不是觀察到的遠端快取撤回或排隊訊息恢復。生產撤回必須使用實際的上次服務時間和所有先前版本。