TLS-RPT（SMTP TLS Reporting）记录检测工具
获取域名的_smtp._tls TXT记录，诊断TLS连接失败时的报告发送地址（rua）是否按RFC 8460规范正确配置。适用于MTA-STS/DANE部署后的运维监控。
诊断 TLS 连接失败的报告（TLS-RPT）
纵然引入了 MTA-STS 或 DANE，仍有一事看不见：**投递究竟有没有在失败，惟有发信一方知晓。** TLS-RPT 便是填上这道缺口的约定。把报告地址写进 `_smtp._tls` 的 TXT 记录，**发信方的服务器便会逐日把报告送来。** 本工具取来那条记录，报出其写法是否合乎 RFC 8460。
**TLS-RPT 本身并非防御，而是一套观测的手段。** 它挡不住攻击，只告诉您 TLS 的建立失败了多少回。**可若没有这份观测，便无从判断何时该把 MTA-STS 推进到 `enforce`。** 万一强制一开投递即停，不等有人来抱怨，您是断然不会知道的。**故而实务中的次第是：先配好 TLS-RPT，让 MTA-STS 停在 `testing` 并读其报告，确信无物失败之后，方才转入 `enforce`。**
使用方法
- 输入域名 只给域名即可，形如 `example.com`。
- 查看 TXT 记录 **看有无 `v=TLSRPTv1` 与 `rua=`。**
- 确认报告地址的写法 以 `mailto:` 或 `https:` 写就。**也请确认那个地址当真收得到。**
- 定下由谁来读报告 **配好了却无人过目，便等于白配。** 请定下谁看、何时看。
用好本工具的小技巧
- TLS-RPT并非由接收方声明后自用，而是由发送邮件服务器读取并使用，用于在与你的域名建立TLS连接失败时，知道该把统计报告发往何处。
- rua字段可以同时列出mailto:格式的邮箱地址和https:格式的Web端点，也可以用逗号分隔指定多个目标。
- 报告以JSON格式（application/tlsrpt+json，也可能经过gzip压缩）发送，建议准备专用的解析工具或邮箱，而不是指望人工阅读。
- 刚部署MTA-STS或DANE之后，建议持续关注一段时间的TLS-RPT报告，以便及时发现可能遗漏的配置错误。
- Google、Microsoft、Yahoo等主要邮件服务商均支持发送TLS-RPT报告，因此与这些大型服务商邮件往来较多的域名，部署后收益也更明显。
这些场景会用到
把 MTA-STS 推向强制之前
**趁还在 `testing`，可量一量究竟有无失败**，这便是作决断的依据。
及早察觉投递的毛病
不必等人来告知，便可知失败正在发生。
引入 DANE 之后作监控
**证书与 TLSA 记录的出入，会以失败的形态现于报告之中。**
确认自家记录的写法
`rua` 写错的模样，便是一封报告也收不到。
TLS-RPT 的术语
- _smtp._tls TXT
- **承载报告地址的 DNS 记录。** 写作 `v=TLSRPTv1; rua=mailto:...` 的形式。
- rua
- 报告该送往何处。**请给出一个电子邮件地址，或一个备好接收的 HTTPS 端点。**
- RFC 8460
- 规定 TLS-RPT 的格式与报告内容的标准。
- 每日报告
- 发信方服务器所送的、涵盖一日的报告。其中载有成功与失败的次数，以及失败的缘由。
- MTA-STS
- 强制 TLS 的安排。**TLS-RPT 与它相配，用以看清那份强制究竟施行得如何。**
- DANE
- 以 DNSSEC 为前提验证证书的安排。**此处的毛病同样会现于 TLS-RPT 的报告之中。**
常见问题
闲话 ― TLS-RPT填补的“静默故障”漏洞
TLS-RPT（TLS Reporting，RFC 8460）于2018年发布，几乎与MTA-STS（RFC 8461）同期推出。两者由同一个工作组讨论制定，有诸多共通之处——都以DNS的TXT记录为基础，也都由Google、Microsoft、Yahoo等主要厂商共同推动——但二者承担的角色截然不同。MTA-STS是“强制使用TLS”的防御层，而TLS-RPT则是揭示“强制之后实际发生了什么”的可观测层。
在TLS-RPT出现之前，SMTP通信中TLS握手失败的情况大多只会被发送方邮件服务器记录到日志中，接收域名的管理员完全不会收到任何通知。即便证书过期或MTA-STS策略配置有误，也往往要等到邮件真正无法送达才会被发现——这种“静默故障”曾是运维上的一大难题。
部署TLS-RPT之后，系统会按日向rua中指定的地址发送汇总报告。报告采用application/tlsrpt+json格式（常经gzip压缩），以结构化数据形式包含成功/失败的次数，以及失败时的具体原因（如证书不匹配、STARTTLS协商失败等）——这类数据更适合交由监控系统摄取分析，而非人工阅读。
在实际运维中，部署MTA-STS或DANE时通常会一并配置TLS-RPT。如果只部署了强制层而没有观测手段，一旦配置有误导致正常邮件被拦截，也无从察觉。通过持续监控TLS-RPT报告，可以更安全地推进TLS强制化的落地。