How to Set Up MTA-STS and TLS-RPT for Email Security

如何设置 MTA-STS 和 TLS-RPT 来保障电子邮件安全

MTA-STS 可让收件域告知发件邮件系统哪些邮件服务器可以接收邮件，以及连接必须使用可信的 TLS。TLS-RPT 则用于报告：支持该功能的发件方可以向你发送 TLS 投递失败和策略问题的相关信息。如果你正在了解如何设置 MTA-STS 和 TLS-RPT 来保障电子邮件安全，请先检查入站邮件配置，而不是从 DNS 记录入手。

这些机制不能替代 SPF、DKIM 或 DMARC。它们保护的是邮件传输过程中的另一个环节：邮件服务器之间的加密连接。如果策略中列出了过时或配置错误的 MX 主机，邮件投递可能会受到影响，因此在启用强制模式前，务必测试完整配置。

1. 确认邮件托管配置已准备就绪

先检查域名当前的 MX 记录。列出记录指向的所有主机名，包括用于备份或区域投递的主机。如果入站邮件由服务提供商管理，请让对方确认哪些 MX 主机名应写入 MTA-STS 策略，以及每台主机是否支持 TLS 并配有有效证书。

核对具体主机名，而不只是服务商的品牌名称。例如，某个域名的 MX 记录可能是 mx1.mail.example.com 和 mx2.mail.example.com，而服务商还运营着其他未列入该域名 MX 记录的主机。策略应涵盖所有能够接收该域名邮件的 MX 主机名。

检查每台已列出主机的证书和 TLS 配置。证书必须受信任，并且对发件邮件系统连接的 MX 主机名有效。证书即使适用于服务商的网站，如果不适用于邮件主机，也不能作为合适的替代品。

同时询问邮件服务商近期是否计划变更主机。如果设置期间 MX 主机名即将变更，请等最终主机列表确定后再继续，或与服务商协调更新策略。发件方缓存了强制策略后，未列入策略的替换主机可能导致投递问题。

2. 发布 TLS-RPT 报告接收地址

发布 DNS 记录前，先确定报告的接收地址。你可以使用能够接收报告的邮箱，也可以使用提供邮箱地址或 HTTPS 接收地址的 TLS 报告服务。请确认该地址有人定期查看，并且邮件系统能够接收发送到该地址的报告。

在 _smtp._tls.example.com 发布一条 TXT 记录，并将 example.com 替换为你的域名。邮箱接收地址的记录值格式如下：v=TLSRPTv1; rua=mailto:tls-reports@example.com。如果报告服务提供了其他接收地址，请使用其给出的完整 URI。

尽可能使用专用邮箱，而不是个人日常使用的收件箱。TLS 报告可能以结构化附件的形式发送，专用邮箱更便于设置访问规则、保留邮件，并将审核工作分配给负责邮件投递的管理员。发布记录前，请检查邮箱的存储和过滤设置。

由于解析器会根据 TTL 缓存记录，DNS 变更可能需要一段时间才会生效。发布记录后，请分别查询权威 DNS 服务和公共解析器，确认两者返回的 TXT 值都正确。记录名称拼写错误，可能导致发件方无法找到报告接收地址。

3. 托管 MTA-STS 策略文件

将策略文件放在 https://mta-sts.example.com/.well-known/mta-sts.txt，并将 example.com 替换为你自己的域名。该地址必须可以通过 HTTPS 访问，且证书必须对主机名 mta-sts.example.com 有效。把文件放在网站常用的首页路径下并不符合此要求。

策略文件是纯文本文件。初次测试时，可以使用以下字段：

• version: STSv1
• mode: testing
• mx: mx1.mail.example.com
• mx: mx2.mail.example.com
• max_age: 86400

将示例 MX 主机名替换为你域名实际使用的入站主机。max_age 的值表示发件方可以缓存策略的秒数；上例为一天。初期使用较短的缓存时间，便于修改测试策略；缓存时间较长，则发件方会保留策略更久。

启用强制模式前，先使用 testing。在此模式下，发件方可以报告策略失败，但不会将策略视为必须拒绝那些无法满足 TLS 要求的邮件。请从网络外部测试该 URL，并确认它能直接返回文件，不需要登录，也不会陷入重定向循环或返回 Web 应用程序错误。

4. 发布 MTA-STS 发现记录

发件方通过 _mta-sts.example.com 下的 TXT 记录查找策略。记录值包含版本和策略标识符，例如：v=STSv1; id=20261104a。请选择一个便于在变更日志中追踪的标识符，不要重复使用旧值。

每次发布修订后的策略文件时，都要更改标识符。这样可以告知发件系统应检查更新后的策略，而不只是依赖缓存副本。标识符用于发现策略，不能替代策略文件或其 HTTPS 托管。

只有在策略文件已能通过指定 URL 访问后，才发布该记录。然后查询 TXT 记录，并从外部网络访问文件。DNS 记录和文件必须反映同一套当前配置：即使标识符是新的，若指向的文件不存在或内容已过时，部署仍然有问题。

5. 检查策略发现、策略文件和 MX 覆盖范围

分别检查每个环节。查询 _smtp._tls 和 _mta-sts TXT 记录，通过 HTTPS 请求策略 URL，并将每一条 mx: 配置与当前 MX 记录进行比对。这三项检查可以发现单独查询 DNS 无法发现的问题。

确认 HTTPS 响应使用的证书受信任且适用于 MTA-STS 主机名，并检查文件是否包含预期字段。然后检查每台 MX 主机是否支持 TLS，且证书是否对该主机名本身有效。如果服务商有多个入站 MX 主机，请逐一测试，不要想当然地认为它们的证书配置完全相同。

记录检查结果，包括 DNS 值、策略标识符、MX 主机名和检查日期。如果之后的报告显示有故障，这些记录可以为下一位管理员提供有用的基准信息。如需了解更多邮件配置内容，可将 YourTrend 博客 RSS 源添加到团队的参考资料列表中。

6. 在启用强制模式前检查报告

让策略保持在测试模式，同时收集 TLS-RPT 反馈并检查日常邮件流。报告可能会指出发件系统遇到了证书问题、TLS 协商问题，或你公布的 MX 主机与策略不一致。报告是需要调查的线索，不代表你应自动据此修改 DNS 记录。

检查报告中的报告周期、受影响的策略域名以及接收主机详情，并将这些信息与自己的 MX 清单和服务商配置进行比对。如果遗漏了合法主机，请更新策略文件并更改策略 ID；如果证书有问题，请先让服务商修正，再启用强制模式。

还要测试来自组织所依赖邮件系统的投递，例如业务合作伙伴的邮件系统，或你自己控制的另一个服务。确认邮件能够送达，并检查入站日志中是否显示 TLS 连接成功。报告邮箱没有收到报告，并不能证明所有发件方都已测试过你的策略。

根据邮件量和运维需求设定明确的审核周期。没有一个适用于所有情况的天数，能够保证报告覆盖每个发件系统，因此不要把某个固定日历周期视为覆盖充分的证明。记录你检查过的内容，以及测试期间已知哪些发件方成功投递了邮件。

7. 启用强制模式并持续监控和维护

确认 MX 清单、证书、HTTPS 策略文件和测试结果都已就绪后，将策略模式从 testing 改为 enforce。发布更新后的策略文件和新的 _mta-sts 标识符。更新后从网络外部验证两者，并继续检查 TLS-RPT 报告和邮件流日志。

启用强制模式后，支持 MTA-STS 的发件系统应使用 TLS，并按照策略验证收件主机。如果无法做到这一点，发件方可能会重试并延迟投递，而不是通过未受保护的连接发送邮件。请与邮件服务商和支持团队协调变更，确保他们了解如何排查投递延迟。

将维护步骤与策略 URL 和 DNS 记录一并记录。当 MX 主机变更时，应先更新策略，再依赖新主机；证书续期时，应确认主机名覆盖范围和信任链。如果强制模式暴露出问题，可以将模式改回测试模式，以减轻策略带来的影响，但也要更新策略 ID，并确认修改后的文件能正确提供。

指定负责人检查报告邮箱或报告服务，并跟踪 DNS 和证书变更。如果你会为同事发布运维说明或邮件服务更新，也可以让他们关注 YourTrend 的博客 RSS 源。明确负责人并记录 MX 变更流程，能让下一次续期或服务商迁移更容易处理。