MTA-STS 故障涉及入站邮件的传输安全。它们不能通过改变来修复 SPF 或者 DKIM。按顺序诊断链： DNS中的策略发现、通过 HTTPS 的策略检索、允许的MX名称以及接收服务器的TLS行为。
识别受影响的发送观察
收集发件人的传送错误、时间、目标域和可用的TLS报告。将单个发件人的结果与普遍中断分开。发送者可能缓存了不同的策略版本，并且实现的支持也不同。记录当前策略标识符、正文、模式和 max_age 以及您可以恢复的任何先前活动的策略。
RFC 8461定义了_mta-sts处的接收域发现和https://mta-sts.<domain>/.well-known/mta-sts.txt.检查已发布的 TXT记录 以及真实域的确切 URL。确保 HTTPS 端点为其主机名提供可信证书并提供有效的策略。 RFC 8461第 3.3 节要求 HTTP 200 并禁止在获取策略时遵循 HTTP 3xx 重定向。浏览器成功访问主页并不会建立该端点行为。
将策略与实际MX路由进行比较
检查目标域的公共 MX记录 并将它们的主机名与策略的 mx 模式进行比较。测试每个活动接收主机，包括通常流量很少的备份主机。超出允许模式的新添加的备份可能会造成间歇性故障，而不是完全中断。
对于每个MX主机，验证SMTP STARTTLS、证书有效性、信任链和MX主机名的身份匹配。在调查中将 Web 策略证书和SMTP服务器证书分开：修复一个证书不会修复另一个证书。使用来自授权测试位置的合适TLS诊断工具并保留连接详细信息，而无需传输不必要的真实消息或凭据。
正确解释模式和缓存
测试模式不需要因MTA-STS验证失败而拒绝；其他传送控制仍可能拒绝该消息。当发件人有适用的策略时，强制模式会应用其验证要求。即使DNS发现记录稍后被删除，具有适用缓存策略的执行发件人也可以继续要求该策略。因此，删除损坏的网站并不是可靠的即时回滚。
当策略更改时，更新发现标识符，以便支持发件人可以检测到更改。围绕已发布的缓存生命周期计划更改。对于计划撤销，请使用 RFC 的无模式过程并允许缓存策略，而不是将DNS删除视为立即取消。在发送者仍然需要的转换期间保持策略端点可用。
通过链条解决失败问题
说明性案例： example.org通告primary.example.org和backup.example.net作为MX主机，但MTA-STS策略仅允许primary.example.org 。在选择备份之前，邮件通常会成功。要调查的第一个更正是预期接收路由与策略之间的不匹配，而不是发送者 SPF记录。添加备份之前，请验证备份是否已获得授权且支持 TLS。这是一个综合场景，而不是实时域测试。
构建一个诊断行，其中包含观察时间、发送源、策略版本（如果已知）、选定的MX 、 TLS错误、预期更改和验证结果。 TLS报告可以揭示类别和模式，但其覆盖范围并不完整，缺少报告并不能证明每个发送者都成功。
恢复服务而不隐藏原因
更愿意修复实际的证书、端点或路由不匹配。如果需要放松政策，请获得相关变更批准，记录临时暴露并说明缓存。修复后，验证每个MX路径并检查后续发件人观察结果和TLS报告。对 HTTPS 和SMTP证书进行过期监控，并将MTA-STS策略包含在每个邮件提供商迁移清单中。
在提款决定中保留缓存历史记录
RFC 8461第 8.3 节 描述了具有短生命周期和更改的发现记录的发布模式 none，然后保留端点直到所有先前提供的策略过期。包括较旧的策略，其较长的 max_age 可以比前一个版本的寿命更长。删除DNS不会删除这些缓存。 3.3 节区分了没有可用缓存的失败的新鲜获取和具有有效缓存策略的失败的获取。 RFC 8460第 4.2 和 4.3 节 描述报告的会话和故障类型，而不是完整的每条消息传送分类帐。此教学场景未执行TLS连接、查找或迁移。