SMTP TLS Reporting（TLS-RPT，RFC 8460）为邮件发送方的 TLS 连接故障提供标准化诊断上报机制，配合 DANE 或 MTA-STS 解决 SMTP 加密落后于 Web 的问题，通过 DNS TXT 记录即可启用每日聚合报告。
背景与问题：
SMTP 安全长期滞后于 Web，核心原因是担心丢失邮件导致发送方不强制验证证书、接收方接受弱加密甚至明文。DNS 未普及 DNSSEC 时，攻击者可伪造 MX 记录劫持投递。2008 年以来 PKI 经历十年动荡，至 2018 年 TLS 1.2 广泛部署、TLS 1.3 刚发布、证书透明度上线，基础设施才基本恢复可信。DANE 与 MTA-STS 提供了选择性加密升级路径，但缺乏连通性失败的可见性。
TLS-RPT 机制与报告内容：
TLS-RPT 通过 DNS TXT 记录发布策略，记录名以 _smtp._tls. 为前缀（如 _smtp._tls.example.com），值格式为 "v=TLSRPTv1;rua=mailto:tlsrpt@example.com"。合规 MTA 会按每日周期发送聚合报告，包含发送方观测到的 DANE 与 MTA-STS 策略、流量统计及可选的失败详情。部署门槛低，仅需一条 DNS 记录，无需修改邮件服务器配置。
现状与取舍：
当前发送方对 TLS-RPT 支持有限，启用后短期内收到的报告极少，原文未给出具体数据。但部署成本极低，属于单向推动标准演进的举措。报告通过邮件投递，依赖邮件系统本身的可达性；若域名已部署 DANE 或 MTA-STS，TLS-RPT 能形成反馈回路，否则主要作为基线观测手段。
运维人员可立即为域名添加 _smtp._tls TXT 记录，零成本接入标准化诊断流；网络工程师在排查跨域邮件投递失败时，将获得发送方视角的策略匹配与失败统计，缩短定位时间。
原文: APNIC Blog（2018-11-16）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog