MTA-STS 策略快取不是普通的瀏覽器快取。此策略的 max_age 控制其自上次成功獲取以來的生命週期。發現TXT有自己的DNS TTL。這些時鐘可能存在很大差異，並解釋了為什麼兩個發送者同時應用不同的策略版本。
記錄寄件者仍可持有的策略
參考： RFC 8461 §3.2, RFC 8461 §3.3.
保留每個已發佈的策略主體、發現 ID、發佈時間和 max_age。當前端點螢幕截圖無法告訴您寄件者昨天獲取了什麼。在發生事件期間，請求應用的策略並從可用的寄件者日誌中獲取時間，而不是假設最新的正文是通用的。
RFC 8461表示，寄件者應將策略快取最多 max_age，並應在過期前主動刷新，建議每日刷新。這些建議並不能保證同步更新。實作可能會在不同時間檢查更新，並且當即時發現或獲取失敗時，發送者可以繼續應用有效的快取策略。
將兩個到期計算分開
參考： RFC 8461 §3.2, RFC 8461 §5.1.
在標記的算術裝置中，在紀元時間 1000000 處取得且 max_age 86400 DNS策略的到期邊界為 1086400。 DNS TTL 為 300 不會更改該計算。如果電信商發布 max_age 3600 的新主體，則已快取的舊主體不會追溯取得新的生命週期。
新的有界離線裝置計算該邊界。保留的歷史傳輸實驗室記錄還記錄了舊緩存的深層副本、壽命較短的策略獲取以及舊快照及其過期時間在明確替換之前保持不變的斷言。快取部分是顯式狀態/算術模型，而不是真實的 MTA、 DNS快取或刷新調度程序；單獨保留的環回DNS /HTTPS 交換不會擴大該快取聲明。若要擴展測試，請使用可檢查的策略快取配置受控發送方，並保留其實際的取得、刷新和傳送日誌。
按安全順序更新
參考： RFC 8461 §8.1, RFC 8461 §8.2.
發布新的 HTTPS 正文，驗證它，然後更改DNS id。 RFC 8461建議在端點更新和TXT TTL 傳遞時保持舊策略與交付相容。對於計劃的路由更改，還允許寄件者保留舊策略，直到其生命週期結束或成功刷新。
使協定策略快取與 CDN 的來源快取不同。寄件者不得使用 HTTP 快取進行策略檢索。然而， RFC 8461 §8.2 允許來源端反向代理快取；驗證其新鮮度和發布行為，而不是將每個代理快取視為禁止的。從公共端點驗證實際正文並確保託管發布工作流程公開預期的修訂。
無需猜測即可診斷延遲變化
參考： RFC 8461 §3.3.
比較DNS答案、HTTPS 回應位元組、快取的策略元資料和寄件者的失敗日誌。舊主體的新 ID 表示出版品訂購或託管新鮮度有問題。遞歸答案中的舊 ID 可能反映DNS快取狀態。提取中斷期間舊的但有效的快取策略可以是預期的協定行為。
不要將每個延遲都聲明為傳播。識別哪個快取或相依性保留舊狀態，修復該元件並在整個轉換過程中保留合規的接收路徑。本文沒有執行即時寄件者快取實驗。
保留的歷史證據和剩餘範圍
以下描述了保留的 2026 年 11 月 7 日觀察結果，而不是為本次審查重新運行的網路實驗。新執行的離線檢查單獨記錄。
捕獲的邏輯快取裝置保留在 1000000 處取得的 A1，過期時間為 1086400。實驗室發布 B2，透過實際的 UDP DNS應答宣布 B2，並透過 HTTPS 使用 max_age 3600 取得 B2。然後，它斷言深度複製的 A1 快照仍然等於其原始內容並保留過期時間 1086400。一個單獨的最後服務的分類帳計算A1 的最大可能到期時間為 1000300 + 86400 = 1086700，晚於 B2 的 1000600 + 3600 = 1004200 和 C3 的 1000900 + 3000。到期值是使用顯式邏輯時間計算得出的；快取保留比較是一個執行的斷言。兩者都不是 MTA 刷新調度程序的模擬。實際發送者選擇刷新、重試或保留狀態仍然是實作測試。