MTA-STS 与 TLSRPT：强制并监控 SMTP TLS

裸 SMTP 不加密任何内容。STARTTLS 升级到 TLS 是机会式的：客户端提出升级请求，一旦失败——或者攻击者在链路上剥掉 STARTTLS 能力——邮件就悄无声息地回落到明文传输。网络路径上的中间人可以精确地实施这种降级，进而读取或篡改在途邮件。几十年来这被当作可接受的风险，而 MTA-STS 终结了这个局面。

两个 RFC 是一对搭档。MTA-STS（RFC 8461）让你的域名发布一条策略，告诉所有发件服务器："我的 MX 主机支持 TLS，加密无效或证书无效就别投递。"TLSRPT（RFC 8460）则每天给你发报告：多少邮件成功走了 TLS，又有哪些失败。稳妥的部署顺序是：先上 TLSRPT、观察、再强制。

MTA-STS 的原理

发件服务器要给你的域名投递邮件时，会先查 DNS 里有没有 MTA-STS 记录。如果有，它通过 HTTPS 抓取策略文件并缓存，此后除非连接使用了有效的 TLS，否则拒绝向你的 MX 主机投递。攻击者阻断或剥离 STARTTLS 不再引发明文回落——发件方只会延迟重试，因为策略写明：没有 TLS 就没有投递。策略抓取本身由普通 Web HTTPS 保护，链路上的攻击者拿不到你策略主机的证书，就无法伪造。

第一步：先部署 TLSRPT

TLSRPT 只是一条 TXT 记录，零成本。在任何 MTA-STS 动作之前先发布它，好让你看到基线：

主机:   _smtp._tls.yourdomain.com
类型:   TXT
值:     v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com

rua 地址每天会收到聚合报告——JSON 格式的 TLS 会话统计。每份报告分别统计成功投递和失败投递，并按接收 MX 主机与失败类型细分：对端不支持 STARTTLS、证书过期、证书主机名不匹配、校验失败等。如果更愿意走 HTTPS 接收，rua 标签也接受 https: URL。

观察两周左右。如果某台接收主机持续出现失败，多半是证书问题或中间防火墙在剥离 STARTTLS——先修好它，否则一旦切换 enforce，这些流量会立刻被拒。

第二步：发布 MTA-STS DNS 记录

主机:   _mta-sts.yourdomain.com
类型:   TXT
值:     v=STSv1; id=20261104T120000

id 是一个简短的版本标识，它唯一的职责就是"变化"：当发件服务器发现 DNS 里的 id 与缓存策略中的不同，就会重新抓取策略。因此每次修改策略文件，都必须更换 id。

第三步：托管策略文件

策略文件放在专用子域名的固定 HTTPS 路径上：

https://mta-sts.yourdomain.com/.well-known/mta-sts.txt

文件内容必须包含：

version: STSv1
mode: testing
mx: mail1.yourdomain.com
mx: mail2.yourdomain.com
max_age: 86400

• version 固定为 STSv1。
• mode 取值 enforce、testing 或 none 之一。
• mx 逐行列出每台 MX 主机——清单必须与你的 MX 记录一致，否则发件方会拒绝对不在清单内的主机投递。
• max_age 是发件方可以缓存策略的秒数——测试期用 86,400（一天），强制后最长可到 31,557,600（一年）。

最关键、也最常被忽视的要求：策略主机上的 HTTPS 必须持有有效的、公共受信的证书。发件方不会通过损坏的或自签名的 TLS 连接抓取策略，所以 Web PKI 必须先就位。

testing 与 enforce 的区别

testing 模式下，发件方行为照旧——什么都不拦，但每一条"如果 enforce 就会被拒"的连接都会出现在你的 TLSRPT 报告里。这是安全的观察模式。

enforce 模式下，发件服务器无法与清单内 MX 主机建立有效 TLS 时，直接拒绝投递。邮件在发件方排队重试；问题持续存在则最终退信。只有当 TLSRPT 报告显示失败率持续接近于零，才切到 enforce，并逐步调大 max_age——max_age 越长，发件方在你做变更期间继续执行旧策略的时间就越久。

运维要点：MX 变更与证书续期

两个维护场景，处理不当会直接断信：

• MX 迁移。顺序永远是：先把新 MX 主机加进策略文件（并更新 id），等传播时间超过 max_age，再去改 DNS 的 MX 记录。下线旧主机则相反：先从 DNS 摘除、暂时保留在策略文件里，等 max_age 过后再从策略中移除。一台不在缓存策略清单里的主机对外发信，会被执行策略的发件方直接拒收。
• 证书过期。清单内 MX 主机的证书一旦过期，执行策略的发件方就会拒绝对它投递——你的入站邮件会堆积在对端队列里，直到证书修好。策略主机和每台 MX 主机的续期都要自动化。如果策略主机的证书过期，发件方无法刷新策略，只能继续使用缓存副本撑到 max_age 到期——损坏更慢，但倒计时在走。

检查现有记录用 MX 查询工具和 MTA-STS 查询工具——后者会同时取回 DNS 记录与线上的策略文件，并标记 MX 记录与策略清单的不一致。

验证

两条记录发布后，用 MTA-STS 查询工具对域名跑一遍：确认 DNS 记录可解析、策略文件能通过有效 HTTPS 抓取、mx 行与真实 MX 记录吻合。然后盯 TLSRPT 报告：testing 模式下的第一批报告证明链路通了；当日报成功率接近 100% 且没有反复出现的失败类型时，就可以上调 max_age，最终把 mode 切到 enforce。

常见错误

• 一步到位切 enforce。没有 TLSRPT 历史，你无法知道哪些合作伙伴或中间防火墙会破坏 STARTTLS——强制执行等于一夜之间把它们的投递失败变成你的事故。
• mx 清单过期。DNS 里加了新邮件服务器却忘了写进策略文件，执行策略的发件方会对它拒收。mx 清单必须与 MX 记录同步变，且策略先行。
• 策略主机证书断供。网站证书自动续了，却忘了把 mta-sts 子域名纳入续期计划。
• 从不更新 id。只改策略文件不换 id，发件方会继续用缓存里的旧策略，你的修改被静默忽略。
• 测试期 max_age 太长。上线阶段，过长的 max_age 会让纠错变得迟钝——先控制在一天，有把握了再延长。

常见问题

MTA-STS 能端到端加密我的邮件吗？

不能。它保证的是服务器之间那一跳的 SMTP 使用有效 TLS——在这一跳上挫败降级与窃听。接收邮件服务器仍然以明文读取内容；内容的端到端保护属于 S/MIME 或 PGP 的领域。

MTA-STS 和 DANE 有什么区别？

两者都强制 SMTP TLS。DANE（RFC 7672）用 DNSSEC 发布哪张 TLSA 证书可信；MTA-STS 用普通 DNS 加 HTTPS 与 Web PKI。DANE 密码学上更强，但要求双方都部署 DNSSEC；MTA-STS 部署容易得多，任何 DNS 服务商都能用——记录发布方法见DNS 服务商配置指南。

MTA-STS 会不会弄坏入站邮件？

会，而这正是它的职责：TLS 一旦失败，发件方拒投。于是坏证书或被剥离 STARTTLS 的链路，会表现为邮件延迟或退信，而不是静默地明文投递。这也是必须先部署 TLSRPT、确认失败率可忽略之后再 enforce 的原因。

它和普通的机会式 TLS 差在哪？

机会式 TLS 是尽力而为：TLS 出于任何原因失败，就回落明文投递，毫无怨言。MTA-STS 把默认值翻转过来——TLS 失败等于不投递——降级攻击对强制策略从此失效。

我只收邮件不发邮件，需要 MTA-STS 吗？

MTA-STS 保护的是发往你域名的入站邮件，只要你有邮件要收，它就适用——抓取并执行策略的是发件方。如果你同时运营出站 MTA，对投递目标域名执行 MTA-STS 是自动的：Postfix（配合 tls-policy-map 机制）、Exim 及主流邮件网关均已原生支持。