添加记录之前找到缺失的步骤
警告 MTA-STS 政策缺失描述的是发现结果，而不是诊断。接收域可能缺少其发现记录、发布多个竞争记录、提供错误的 HTTPS 资源，或者已经具有发送者无法检索的策略。创建另一个 TXT记录 在分离这些情况之前可能会使可恢复的问题变得更糟。从确切的域和警告背后的证据开始。
这是一份文件调查计划。未执行DNS查找、从客户主机下载策略、 SMTP连接或提供商更改。下面的工作案例是虚构的。操作结论需要来自相关基础设施的带有时间戳的观察结果，以及报告发送者的策略状态（如果有）。
建立政策域
对于普通发送到example.com邮箱的情况，发现开始于 _mta-sts.example.com。该政策取自 https://mta-sts.example.com/.well-known/mta-sts.txt。子域中的邮箱需要发现该子域；合规的发件人不得退回到父级的政策。管理配置的智能主机引入了不同的策略域选择，因此记录调查是否涉及直接传递或中继。 RFC 8461第 3.1–3.4 节
向警告所有者询问其时间戳、查询名称、记录类型和完整结果。屏幕截图显示“丢失”无法区分不存在的名称、不包含可用记录的成功答案或超时。稍后授权时保留权威观察和递归观察。 DNS负缓存可以保留早期的缺失，因此当前的控制面板显示无法解释每个解析器的答案。 RFC 2308
评估完整的发现答案
发现记录开始于 v=STSv1; 并包括一个 ID 识别策略实例。标识符发出变化信号；它不包含政策或强加时间顺序。不带所需版本前缀的记录被丢弃后，必须保留一条可用的记录。因此，多个匹配的TXT记录可能是发现失败的原因，而不是添加第三个记录的原因。 RFC 8461第 3.1 节
保留记录边界。一条TXT记录中的多个带引号的字符串串联在一起，且不插入空格；多个TXT记录仍然是单独的记录。关注任何发现 CNAME 链接并保留目标答案。 RFC 8461允许该委托。 DNS提供商的编辑界面可能会类似地显示这些情况，因此在建议写入之前将实际响应与预期配置进行比较。 RFC 8461第 3.1 节
单独跟踪 HTTPS 检索
有效的发现记录会指向固定的 HTTPS 策略位置。该服务必须提供对策略主机有效的受信任的、未过期的证书。有效的获取需要 HTTP 200；不得遵循重定向。因此，默默地遵循重定向的浏览器可以使损坏的端点看起来很健康。捕获第一个响应状态和原始 URL，而不仅仅是最终显示的页面。 RFC 8461第 3.3 节
检查返回的正文作为策略文本。根据语法检查版本、模式、最长期限和所需的MX条目。发件人应验证文本/纯媒体类型。返回状态为 200 的登录页面或品牌错误文档尚未成为可用的策略。语法允许重复的MX字段；重复的单例字段的处理方式不同，因此保留原始字节而不是默默地标准化它们。 RFC 8461第 3.2 节
将发现与交付验证分开
获得策略后，将其MX模式与实际候选主机名进行比较。允许的通配符涵盖一个完整的最左边标签，而不是任意级别。然后评估 STARTTLS 以及所选MX主机的接收服务器的证书。这些检查与验证 HTTPS 策略服务上的证书不同。成功的策略下载并不验证邮件服务器。 RFC 8461第 4.1–4.2 节
还记录发件人缓存状态。未能发现或获取实时策略不会删除有效的、未过期的缓存策略。相反，没有可用缓存策略且 HTTPS 获取不成功的发件人将继续进行，就好像该域尚未实现MTA-STS一样。该声明仅涉及MTA-STS ；另一项适用的运输政策仍可能限制交付。 RFC 8461第 3.3 节
解决一个虚构的重复记录案例
假设虚构的example.com运营商在更改托管提供商后看到“策略缺失”警告。提议的证据包包含两个单独的发现TXT记录，其中一个包含 id=old1 和一个与 id=new2，均以有效版本前缀开头。假定 HTTPS 端点提供正确的测试策略。这些是发明的观察结果，而不是这里收集的结果。
根据发现规则，两个幸存记录会阻止选择可用策略。合理的修复是识别预期的当前记录并检查删除过时的重复项，而不是重新创建 HTTPS 服务。该提案仍需要所有权和变更批准。随后的跟踪将验证一个发现记录、预期的 HTTPS 正文和MX覆盖范围。旧的发送方缓存可能会产生不同的行为，直到其策略状态发生变化。
以有限的推出决定结束
如果调查支持新的部署，请准备一份受控测试实施计划。识别所有预期的MX主机（包括备份）、建立 HTTPS 可用性并安排 TLS-RPT 收藏。在测试模式下，可以报告MTA-STS验证失败，而无需发送方阻止传送。安静的报告邮箱并不足以证明准备情况。 RFC 8461第 5-6 节
当策略正文更改时，请先发布 HTTPS 正文，然后再更改DNS TTL 和现有缓存的发现标识符和帐户。将原始跟踪、建议差异和回滚所有者保留在一起。当前的RFC 8461勘误表已单独检查；报告的提案尚未被视为已批准的替代方案。缺失的 DNS-to-HTTPS-to-MX 跟踪和受控推出证据仍然是明确的发布门。 RFC 8461第 8.1 节 当前勘误表