MTA-STS 策略检测工具
获取域名的 _mta-sts TXT 记录与 mta-sts.txt 策略文件，诊断邮件传输过程中的强制 TLS 加密（MTA-STS）是否配置正确。
使用提示
- MTA-STS 是由“发信方”服务器负责检查的机制。一旦发布策略，其他人发往你域名的邮件服务器就会开始强制使用 TLS。
- 建议先以 mode: testing 运行数周至一个月，监控是否出现意外的投递拒绝，再切换到 enforce，以确保过渡安全。
- max_age（策略有效期）通常设置在 604800 秒（7天）到 31557600 秒（1年）之间。数值过短会导致频繁重新获取策略文件。
- mx 字段可以使用通配符（如 *.example.com），但 TLS 证书的 SAN（Subject Alternative Name）必须与该通配符匹配。
- 只发布 DNS 记录或只发布策略文件都不起作用，只有两者同时齐备时 MTA-STS 才会生效。
常见问题
“未配置 MTA-STS”本身并不罕见，目前大多数域名仍未采用。但如果希望增强对 STARTTLS 剥离攻击的防护，值得考虑引入该机制。
SPF、DKIM、DMARC 用于验证发信方身份、防止伪造。MTA-STS 与发信方身份验证无关，它强制邮件传输链路本身使用 TLS 加密，防御的是另一类威胁。
并非放在你自己的域名下，而是必须放在以“mta-sts.”为前缀的子域名（例如 mta-sts.example.com）的 /.well-known/mta-sts.txt 路径下，并通过有效的 TLS 证书提供服务。
不建议这样做。应先以 testing 模式运行数周至一个月，借助 TLS-RPT 监控投递情况，确认不会出现意外拒收后再切换到 enforce，这样更安全。
本工具仅检查 TXT 记录与策略文件的语法及必填字段是否齐全，并不验证 TLS 证书的有效性，也不会对列出的 MX 主机执行实际的 TLS 握手。如需更严格的验证，请配合 checktls.com 等专业工具使用。
闲话 ― STARTTLS 的弱点与 MTA-STS 诞生的背景
长期以来，SMTP 传输加密依赖于 1999 年标准化的 STARTTLS 机制——先以明文建立连接，再切换到加密通道。2014 年，安全研究人员确认了真实存在的“STARTTLS 剥离攻击”：由于 STARTTLS 协商本身发生在加密启用之前，路径中的攻击者可以篡改服务器响应，隐藏其对 STARTTLS 的支持，从而诱使对方退回到明文通信。
问题的根源在于 STARTTLS 刻意设计为“对方不支持 TLS 时优雅降级为明文”这一兼容性特性，而攻击者恰恰可以利用这一点，伪装成对方不支持 TLS。大约在 2015 年前后，谷歌自身的测量数据显示，在某些国家和某些运营商网络中，STARTTLS 剥离攻击已经大规模发生。
MTA-STS（RFC 8461，2018年发布）正是业界对此问题的回应，由谷歌、微软、雅虎等共同制定。域名通过 DNS TXT 记录声明支持 MTA-STS，再发布一份通过 HTTPS 获取的策略文件，列出允许的 MX 主机与 TLS 要求。策略一旦获取便会按 max_age 缓存，此后若发生降级尝试即可被检测并拒绝，而不是被悄悄接受。
MTA-STS 通常与 TLS-RPT（TLS 报告，RFC 8460）搭配使用，后者可让域名所有者在发信服务器无法建立 TLS 时收到报告。MTA-STS 负责“强制执行”，TLS-RPT 负责“可观测性”，两者并用是目前业界推荐的最佳实践。