网络诊断工具

TLS-RPT 检测

SMTP TLS 报告策略

什么是 TLS-RPT?

TLS-RPT(SMTP TLS 报告,SMTP TLS Reporting)让一个域名能从发送方服务器收到关于 TLS 连接失败的每日报告,从而发现以不安全方式投递的邮件。IPeek 会读取 _smtp._tls TXT 记录并显示报告目的地。它通过让你看清 MTA-STS 和 DANE 策略在真实环境中的表现来补充这两者。

TLS-RPT 报告如何工作

TLS-RPT 以位于 _smtp._tls.your-domain 的单条 DNS TXT 记录发布。该记录持有一个版本标签和一个 rua= 标签,列出报告应发往何处,可以是 mailto 地址或 HTTPS 端点。支持该标准的发送方服务器会把它们与你 MX 主机一天内的 TLS 协商结果汇总,并将一份 JSON 报告投递到这些目的地。每份报告统计成功和失败的会话,并对失败进行分类,如证书验证错误或 STARTTLS 不可用,从而为你提供关于真实投递的反馈回路。

如何解读你的 TLS-RPT 结果

IPeek 确认 _smtp._tls TXT 记录是否存在,并显示它解析出的 rua 目的地。核实版本为 TLSRPTv1,且每个 rua 目标都是你实际监控的有效邮箱或 HTTPS URL。记录本身不强制任何事;它只请求报告,因此它的存在意味着发送方知道把 TLS 失败数据发往何处。报告到达后,查看失败类型:certificate-expired、验证失败和 starttls-not-supported 各自指向你接收基础设施上的一个具体修复点,趁它们尚未造成隐性投递问题时处理。

TLS-RPT 与 MTA-STS 和 DANE 的关系

MTA-STS 和 DANE 对入站邮件强制执行 TLS,但只有当你能看清它对真实流量的影响时,强制执行才是安全的。TLS-RPT 提供了这种可见性:当你以 testing 模式部署 MTA-STS 时,报告会在你切到 enforce 之前揭示哪些发送方遇到了 TLS 失败。DANE 的 TLSA 不匹配同理。把 TLS-RPT 当作你 TLS 态势的监控层,与强制机制并行部署而非取而代之,从而及早发现证书和配置问题。

常见问题

什么是 TLS-RPT DNS 记录?

它是发布在 _smtp._tls.your-domain 的一条 TXT 记录,用于请求 TLS 失败报告。记录包含一个 v=TLSRPTv1 版本标签和一个 rua= 标签,以 mailto 地址或 HTTPS URL 指定报告发往何处。支持 TLS-RPT 的发送方服务器借此知道该把关于发往你域名的 TLS 连接的每日汇总报告投递到哪里。

TLS-RPT 报告里有哪些信息?

TLS-RPT 报告是一份 JSON 文档,概括发送方服务器与你 MX 主机之间一天内的 TLS 协商情况。它统计成功和失败的会话,并按类型细分失败,如证书过期、证书验证错误或 STARTTLS 不可用。这让你能精确定位是哪些接收主机或证书在造成不安全或失败的投递。

TLS-RPT 会对邮件强制执行 TLS 吗?

不会。TLS-RPT 纯粹是一种报告机制,自身不强制任何事。强制来自 MTA-STS 或 DANE,它们要求 TLS 并能阻止不安全投递。TLS-RPT 作为监控层与这些策略并存,让你看清 TLS 成功或失败的频率,从而能放心地部署强制机制。

我该如何设置 TLS-RPT?

在 _smtp._tls.your-domain 发布一条 TXT 记录,包含 v=TLSRPTv1 和一个指向你所监控邮箱或 HTTPS 端点的 rua= 标签,例如 rua=mailto:tlsrpt@your-domain。请选择一个你确实会查看的目的地,因为报告以 JSON 形式每日到达。将它与 MTA-STS 或 DANE 配对,使报告能描述你强制 TLS 策略的表现。

TLS-RPT 如何与 MTA-STS 配合?

TLS-RPT 提供了让 MTA-STS 可安全部署的可见性。当你以 testing 模式发布 MTA-STS 策略时,发送方服务器会通过 TLS-RPT 报告任何 TLS 失败,因此你能在切到 enforce 之前看到哪些发送方会被阻断。两者被设计为协同工作:MTA-STS 设定策略,TLS-RPT 告诉你它在实践中的表现。

相关工具

Deutsch | English | Español | Français | Italiano | Português | Русский | Українська | 日本語 | 简体中文 | 한국어