MTA-STS — 邮件传输代理严格传输安全

Standards Track Transport Security Published March 2026

ELI5: 想象通过上锁的邮箱寄信，但有人可能会换成假锁来读取你的邮件。MTA-STS 就像发布一个标志，说"我总是使用真的锁——如果锁看起来不对，就不要投递"。它防止攻击者欺骗邮件服务器发送未加密的电子邮件。

为什么存在这个标准

SMTP 设计于电子邮件以明文传输的时代。STARTTLS (RFC 3207) 增加了可选加密，但它有一个致命缺陷：它是机会性的。发送服务器询问"你支持 TLS 吗？"，活跃网络攻击者可以简单地删除该响应，强制降级为明文。发送服务器无法区分"这个服务器不支持 TLS"和"攻击者删除了 TLS 提议"。

MTA-STS 通过让域名所有者发布策略来解决这个问题——通过 HTTPS 而非 DNS——声明："我的邮件服务器始终支持带有有效证书的 TLS。如果你无法建立安全连接，拒绝投递。"因为策略通过 HTTPS 获取（有自己的证书信任链），活跃攻击者无法伪造或抑制它。

工作原理

MTA-STS 要求接收域名提供两样东西：

一条 DNS TXT 记录位于 _mta-sts.example.com，标示策略存在并包含用于缓存清除的版本标识符。
一个通过 HTTPS 提供的策略文件位于 https://mta-sts.example.com/.well-known/mta-sts.txt，声明实际策略。

第一步：DNS 记录

发布一条 TXT 记录来通告你的 MTA-STS 策略：

_mta-sts.example.com. IN TXT "v=STSv1; id=20240101T000000Z"

id 字段是一个不透明的字符串。发送服务器缓存策略，当 id 改变时重新获取。使用时间戳或递增计数器。

第二步：策略文件

在 https://mta-sts.example.com/.well-known/mta-sts.txt 托管策略。HTTPS 证书必须对 mta-sts.example.com 有效。

version: STSv1
mode: enforce
mx: mail.example.com
mx: backup.example.com
mx: *.example.net
max_age: 604800

策略字段

字段	描述
`version`	必须是 `STSv1`。
`mode`	`enforce`（失败时拒绝），`testing`（投递但报告），或 `none`（禁用）。
`mx`	允许的 MX 主机名。仅最左标签允许通配符（例如 `*.example.com`）。
`max_age`	发送者应缓存此策略的时间长度（秒数）。建议：604800（1 周）或更长。

发送服务器的操作

查找收件人域名的 MX 记录。
检查缓存的 MTA-STS 策略，或者如果 DNS _mta-sts TXT 记录是新的或已更改则获取一个。
连接到 MX 主机并启动 STARTTLS。
根据策略中的 mx 模式验证 MX 服务器的 TLS 证书。
如果模式是 enforce 且 TLS 失败或证书不匹配：不投递。将邮件排队并稍后重试。

关键技术细节

为什么选择 HTTPS 而不是 DNSSEC？

DNSSEC 部署仍然有限。HTTPS 利用了广泛部署的 Web PKI（证书颁发机构基础设施）。任何能获得网页证书的域名都可以使用 MTA-STS——不需要 DNSSEC。这是 MTA-STS 和DANE (RFC 7672)（需要 DNSSEC）的关键区别。

首次使用信任（TOFU）

MTA-STS 遵循 TOFU 模型。第一次发送者遇到你的策略时，必须信任 DNS 和 HTTPS 响应。之后，缓存的策略防止降级直到 max_age 过期。攻击者需要在初始获取期间同时破坏 HTTPS 和 DNS——这是一个显著更难的攻击。

测试模式

以 mode: testing 开始。在此模式下，发送服务器即使 TLS 验证失败也会投递邮件，但生成TLS-RPT (RFC 8460) 报告，以便在切换到 enforce 之前识别问题。

部署示例

example.com 的完整 MTA-STS 设置：

DNS 记录

; MTA-STS 策略信号 _mta-sts.example.com. 300 IN TXT "v=STSv1; id=2024061501" ; TLS 报告端点 (RFC 8460) _smtp._tls.example.com. 300 IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com" ; MX 记录（必须与策略 mx: 行匹配） example.com. 300 IN MX 10 mail.example.com. example.com. 300 IN MX 20 backup.example.com.

策略文件

# 在 https://mta-sts.example.com/.well-known/mta-sts.txt 提供
version: STSv1
mode: testing
mx: mail.example.com
mx: backup.example.com
max_age: 86400

一旦 TLS-RPT 报告确认没有问题，将 mode 改为 enforce 并增加 max_age 为 604800 或更长。

常见错误

证书不匹配。策略中的 MX 主机名必须与该服务器上的 TLS 证书匹配。如果 MX 是 mail.example.com 但证书是 *.mailprovider.com，强制执行将导致投递失败。
忘记更新 DNS id。发送者按 id 缓存策略。如果更改策略文件但不更改 id，发送者在 max_age 过期前不会重新获取。
mta-sts.example.com 上的 HTTPS 证书无效。策略托管站点必须有有效的公开信任的证书。自签名或过期的证书将导致发送者忽略策略。
直接跳到 enforce。始终以 testing 开始并监控TLS-RPT 报告至少两周。配置错误的 MX 服务器在强制模式下会无声地丢失邮件。
强制模式中的短 max_age。短 TTL 意味着发送者频繁重新获取，扩大 TOFU 窗口。在生产环境中至少使用 604800 秒（1 周）。
通配符 MX 滥用。 mx: * 无效。通配符仅适用于最左 DNS 标签：mx: *.example.com 匹配 a.example.com 但不匹配 a.b.example.com。

可投递性影响

MTA-STS 不会直接改善收件箱投递——它保护收件人的邮件免受拦截。但它有间接的可投递性好处：

建立域名信任。Google、Microsoft 和 Yahoo 都支持 MTA-STS。发布策略表明你认真对待安全并运行维护良好的域名。
合规所需。处理敏感数据的行业（金融、医疗）越来越要求邮件 TLS 强制执行。MTA-STS 是标准机制。
防止静默降级。没有 MTA-STS，网络路径上的攻击者可以删除 STARTTLS 并拦截邮件而任何一方都不知情。这是有文档记录的现实世界攻击。
与 TLS-RPT 配对。 RFC 8460 报告让你能看到所有发送者的 TLS 失败——对于在影响投递之前诊断证书或配置问题无价。