TLS-RPT（SMTP TLS Reporting）记录检测工具
获取域名的_smtp._tls TXT记录，诊断TLS连接失败时的报告发送地址（rua）是否按RFC 8460规范正确配置。适用于MTA-STS/DANE部署后的运维监控。
使用提示
- TLS-RPT并非由接收方声明后自用，而是由发送邮件服务器读取并使用，用于在与你的域名建立TLS连接失败时，知道该把统计报告发往何处。
- rua字段可以同时列出mailto:格式的邮箱地址和https:格式的Web端点，也可以用逗号分隔指定多个目标。
- 报告以JSON格式（application/tlsrpt+json，也可能经过gzip压缩）发送，建议准备专用的解析工具或邮箱，而不是指望人工阅读。
- 刚部署MTA-STS或DANE之后，建议持续关注一段时间的TLS-RPT报告，以便及时发现可能遗漏的配置错误。
- Google、Microsoft、Yahoo等主要邮件服务商均支持发送TLS-RPT报告，因此与这些大型服务商邮件往来较多的域名，部署后收益也更明显。
常见问题
MTA-STS是强制TLS连接的防御机制，而TLS-RPT则是通过报告确认强制之后TLS连接是否实际发生失败的观测机制。两者可以独立配置，也可以只部署其中一个。
“未配置”本身在许多域名中都很常见，并不意味着立即存在危险。但如果已经部署了MTA-STS或DANE，建议同时配置TLS-RPT，以便及时发现配置错误。
会发送到TXT记录rua字段中指定的mailto:邮箱地址或https:端点。也可以用逗号分隔指定多个接收地址。
报告是JSON格式的结构化数据，通常的做法是通过监控工具或脚本自动汇总，而非人工查看。也有不少厂商提供专门的报告解析服务。
本工具仅检查TXT记录的语法以及必填字段（v、rua）是否存在，并不验证报告是否真的会送达。部署后请等待数天，确认是否实际收到了报告邮件。
闲话 ― 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强制化的落地。