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 + 3600 = 1004500。到期值是使用显式逻辑时间计算得出的；缓存保留比较是一个执行的断言。两者都不是 MTA 刷新调度程序的模拟。实际发送者选择刷新、重试或保留状态仍然是一个实现测试。