随着企业越来越依赖电子邮件作为主要通信手段，加强这些渠道防范潜在威胁的重要性怎么强调都不为过。传输层安全（TLS）可确保跨网络传输数据的机密性和完整性。

SMTP TLS 报告（TLS-RPT）是与 MTA-STS 协同工作的重要协议，可确保邮件安全送达。TLS-RPT 提供有关电子邮件发送问题的详细反馈，帮助域名所有者维护通信的完整性和保密性。在这份全面的指南中，我们将探讨什么是 SMTP TLS 报告、它是如何工作的，以及为什么它对你的电子邮件安全策略至关重要"。

有几种协议可帮助加密 SMTP 消息通道，防止网络攻击者截获电子邮件通信。其中包括 STARTTLS、DANE 和 MTA-STS。但是，在使用这些协议时，如果加密尝试失败，您的电子邮件可能无法送达。 TLS-RPT（根据 RFC 8460中所述）提供了一种反馈机制来报告这些发送失败。

我们强烈建议将 TLS-RPT 与 MTA-STS协议结合使用。让我们来了解一下这些协议如何共同加强电子邮件安全.

主要收获

通过实施 TLS-RPT 和 MTA-STS 等协议，可大大提高电子邮件的安全性。
TLS-RPT 就与 TLS 加密相关的电子邮件发送问题提供重要反馈，帮助域名所有者有效监控其电子邮件渠道。
STARTTLS、DANE 和 MTA-STS 协议共同确保电子邮件通信安全，降低网络攻击风险。
设置 TLS-RPT 记录需要在特定子域的 DNS 设置中发布 TXT 记录。
识别和处理 TLS 加密故障对于维护电子邮件的可送达性和安全性至关重要。

什么是TLS-RPT？

TLS-RPT（传输层安全报告）是一种标准，用于在电子邮件未使用 TLS 加密时报告电子邮件发送问题。它在电子邮件身份验证中的重要性与启用 TLS 加密电子邮件的原因是相辅相成的。

TLS 加密技术可确保发送给您的每封电子邮件都能安全送达。如果连接不安全，很多时候电子邮件可能无法送达。通过 TLS-RPT，域名所有者可以监控电子邮件的发送和连接失败情况。报告可包含以下信息

MTA-STS 策略处理问题
交付失败的原因和类型
电子邮件收发邮件传输代理的 IP 地址
成功和不成功 TLS 连接会话的总计数

这样就能了解您的电子邮件渠道，并能更快地应对送达方面的挑战。

使用 PowerDMARC 简化 SMTP TLS 报告！

开始15天试用预定演示

TLS 报告如何工作？

在 SMTP 电子邮件通信中，TLS 加密是 "机会主义 "的。这意味着，如果无法协商加密通道，电子邮件仍将以未加密（纯文本）格式发送。事实上，近 40 年前，SMTP 电子邮件协议并不支持 TLS 加密。后来才以 STARTTLS 命令的形式进行了改造。

STARTTLS 命令只有在 SMTP 通信双方都支持 TLS 加密时才会发出。否则，电子邮件仍将以纯文本形式发送。

为了摆脱 SMTP 中的机会主义加密，引入了 MTA-STS (RFC 8461).MTA-STS 协议可确保邮件在发送前进行加密。电子邮件服务器或邮件传输代理（MTA）会与接收服务器协商，看它是否支持 STARTTLS 命令。如果支持，电子邮件就会通过 TLS 加密并送达。否则，发送失败。

逐步说明 TLS-RPT 的工作原理

1.了解 TLS 握手过程

传输层安全握手（TLS）是在两个通信的邮件传输代理（MTA）之间建立安全连接的过程。该过程包括以下步骤：

发送电子邮件的 MTA 会向接收电子邮件的 MTA 发送 "客户你好 "信息。该信息包含 TLS 版本和密码套件等有用参数。
电子邮件接收 MTA 收到此信息后，会回复一条 "服务器你好 "信息。其中包含所选的 TLS 版本和密码套件。
启动 TLS 握手后，接收 MTA 会发送由可信 CA（证书颁发机构）颁发的 SSL/TLS 证书。该证书包含公钥。
通信双方的 MTA 会安全地交换加密密钥，并建立 TLS 加密连接。这就确保了双方之间的电子邮件通信安全。

2.TLS 握手失败的情况

由于各种原因，TLS 握手可能会失败：

证书错误： 过期证书或由不可信的证书颁发机构颁发的证书会导致 TLS 握手失败。
版本不匹配： 如果发送和接收 MTA 支持的 TLS 版本不匹配，会导致握手失败。
STARTTLS 故障： 如果 STARTTLS 命令未正确执行，会再次导致 TLS 加密失败。
MTA-STS 强制： 如果电子邮件接收方已将 MTA-STS 策略模式设置为 "执行"，则 TLS 握手失败会导致邮件被拒。

3.报告生成和交付

一旦出现 TLS 加密失败，发送服务器就会生成一份 TLS-RPT 报告，并将其发送给域名所有者，以便进一步评估和排除故障。

报告内容

发送服务器详细信息:发件人的 IP 地址和域名。

接收服务器详细信息:收件人域名和电子邮件服务器信息。

错误描述:故障类型和详情（如证书错误、协议不匹配）。

失败的时间:问题发生的时间戳。

策略模式：域处于 "测试 "还是 "执行 "模式。

报告交付

这些 TLS 报告以 JSON 格式发送到域名所有者的 TLS-RPTDNS TXT 记录中指定的电子邮件地址。

机会加密在 SMTP 中的作用

SMTP 传统上使用机会加密。这意味着它会尝试使用 TLS，但如果接收 MTA 不支持 TLS，就会退回到未加密传输。

不过，机会主义加密有一个很大的局限性。这种加密方式不设定任务，如果 TLS 加密失败，电子邮件可以明文或明文（未加密格式）发送。这种未加密信息很容易被截获。

MTA-STS 和 TLS-RPT 如何协同工作

邮件传输代理严格传输安全（MTA-STS）和 TLS-RPT 是电子邮件验证生态系统中的互补协议。MTA-STS 可确保发送 MTA 必须使用 TLS 传输，并在加密失败时拒收电子邮件、

TLS-RPT 使域名所有者能够监控失败的 TLS 握手并排除故障。如果同时实施，它们可以防止信息在传输过程中被拦截，并最大限度地减少电子邮件的可送达性问题。

DANE 与 TLS-RPT 的关系

基于 DNS 的命名实体认证（DANE）协议允许域名所有者指定通过 DNSSEC 验证的 TLS 证书，以防止中间人攻击。TLS-RPT 监控 TLS 故障，而 DANE 则确保只使用可信证书。这样，DANE 就能主动防止攻击者实施 TLS 降级和证书欺骗攻击，从而维护电子邮件通信的完整性。

为什么你需要SMTP TLS报告？

域所有者需要随时了解从启用 MTA-STS 的域发送的电子邮件因 TLS 加密失败而导致的电子邮件发送问题。TLS 报告可提供此类信息。

电子邮件安全:强调未加密电子邮件通信的风险（如拦截、中间人攻击）。
合规性:请说明 TLS-RPT 如何帮助企业满足数据保护的监管要求。
交付能力:解释 TLS-RPT 如何通过识别和解决加密问题来提高电子邮件的可送达性。

设置 TLS-RPT 的步骤

为 TLS-RPT 创建 TXT 记录并在 DNS 上发布后，就可以启用域名的 TLS 报告功能。该记录必须发布在子域 smtp.tls.yourdomain.com

步骤 1：生成 TLS-RPT 记录（使用 TLS-RPT 记录生成器）

您可以免费注册并使用我们的 TLS-RPT 记录生成器创建记录。

第 2 步：输入您的报告电子邮件地址

输入您希望接收 SMTP TLS 报告的电子邮件地址。

第 3 步：在 DNS 上发布 TLS 记录

您可以联系域名注册商，为 TLS-RPT 创建新的 TXT 记录。如果您自己管理 DNS，请编辑 DNS 设置以包含该记录。

TLS-RPT 记录语法和示例

语法：v=TLSRPTv1; rua=mailto:[email protected]；

让我们来分析一下所提供的 TLS 报告记录的两个组成部分：

v=TLSRPTv1：此标记用于指定所使用的 TLS-RPT 协议版本。在这种情况下 "TLSRPTv1表示协议的第一个版本。
rua=mailto:[email protected]：rua 代表 "汇总数据报告 URI"。该标签指定了收件人邮件服务器发送 TLS 汇总报告的位置。

您可以为接收报告配置多个目的地。对于多个目的地，请用逗号（,）分隔每个条目。您可以使用 "mailto: "为该步骤指定电子邮件地址，或者在 rua= 字段中使用 "https: "指示 MTA 通过 POST 向端点 URL 提交报告。如果使用 "https:"，请确保该字段定义的 URL 是启用 HTTPS 且具有有效证书的网络服务器。mailto: "和 "https: "也可以在一条记录中使用，中间用逗号隔开。

示例：v=TLSRPTv1; rua=mailto:[email protected],https://tlsreport.example.com；

注意： 实际上，您可以用"yourdomain.com" 替换为您希望接收这些报告的实际域名。

了解 TLS-RPT JSON 报告

TLS-RPT JSON 报告的结构

TLS 报告以 JSON 格式发送。下面是一个 JSON TLS 报告的示例：

{

"组织名称"："组织公司"、

“date-range”: {

"start-datetime"：“2020-10-22T00:00:00Z”,

"end-datetime"（结束日期）：“2020-10-22T23:59:59Z”

"联系信息"："[email protected]"、

"report-id"：“2020-10-22T00:00:00Z_domain.com”,

"政策"：[

{

“policy”: {

"政策类型"："sts"、

"政策字符串"：[

"版本：STSv1"、

"模式：测试"、

"mx：mx.domain.com"、

"mx：mx2.domain.com"、

"mx：mx3.domain.com"、

"max_age：604800"

"政策域"："domain.com"

“summary”: {

"总成功会话数"：15,

"total-failure-session-count"：0

}

关键字段及其含义

下面是 JSON TLS 报告中主要字段的细目：

字段	描述
组织	拥有 TLS-RPT 记录的域组织。
电子邮件	发送汇总报告的电子邮件地址。
开始日期	报告期的开始日期。
结束日期	报告期的结束日期。
政策	政策对象数组，用于描述报告期内应用的政策。
政策	包含所应用策略的相关信息。
政策类型	指定政策类型
policy_string	指定与策略相关联的策略字符串
模式	指定 MTA-STS 策略模式（执行/测试）
摘要	包含尝试进行的会话的摘要信息。
成功会话总数	成功建立的 TLS 会话总数。
失败会话总数	TLS 会话失败的总次数。
故障详情	提供特定故障详细信息的对象数组。
理由	表示失败原因的字符串（如 "certificate_expired"）。
计数	因特定原因失败的会话计数。

TLS-RPT JSON 报告格式和数据解释

报告元数据

{

"组织名称"："发送 MTA 组织"、

“date-range”: {

"start-datetime"：“2025-02-25T00:00:00Z”,

"end-datetime"（结束日期）：“2025-02-25T23:59:59Z”

"report-id"：“unique-report-id-12345”

}

JSON 报告的这一部分概述了基本信息，如电子邮件发件人的组织名称、开始日期和时间、结束日期和时间，以及生成 TLS 报告的唯一 ID。

政策详情

“policy”: {

"政策类型"："sts"、

"policy-string"："mode: enforce; mx: mail.example.com; max_age：604800;"

}

本节概述了所执行的 MTA-STS 策略模式，在本例中为强制模式，但也可设置为测试模式。

故障详情

"故障详情"：[

{

"结果类型"："证书过期"、

"sending-mta"："smtp.example.org"、

"receiving-mta"："mail.example.com"、

"失败原因"："由于证书过期，TLS 握手失败"

}

]

这一部分是 TLS 报告中最关键的部分，详细说明了加密和潜在传输失败的原因。在本例中，示例指出证书过期是导致 TLS 握手失败的原因。这在 TLS 握手失败期间的错误检测中发挥了重要作用，并促进了安全 TLS 通信的快速故障排除。

TLS 加密失败的原因和故障排除

TLS 加密失败可能有多种原因。除了双方都不支持加密外，SMTP 降级攻击等更险恶的原因也可能导致 TLS 连接失败。但域名所有者希望知道发送失败的情况。TLS 报告（TLS-RPT）是一种会通知你的协议。在发送失败时，您会收到以 JSON 文件格式发送到 TLS-RPT 记录中定义的电子邮件地址的 TLS 报告。以下是加密失败的几个常见原因和故障排除技巧：

1.证书问题

证书过期

远程服务器提供的证书已过有效期。这使得它在加密时不可信。在这种情况下，你需要更新证书。

证书尚未生效

远程服务器提供的证书无效。这可能是由于服务器时间不正确或过早使用证书造成的。在这种情况下，最好联系证书提供商。

证书被撤销

出于安全考虑，证书颁发机构已撤销远程服务器颁发的证书。在这种情况下，最好联系证书提供商。

无有效签名

发件人的邮件服务器或客户端不信任远程服务器提供的证书链，表明存在潜在安全风险。在这种情况下，最好联系证书提供商。

不支持的证书

远程服务器提供的证书使用了发件人邮件服务器不支持的加密算法或密钥长度，导致无法建立安全连接。在这种情况下，最好与证书提供商联系。

2.主机名和身份不匹配

主机名不匹配

服务器证书中指定的主机名与发件人邮件服务器试图连接的服务器主机名不匹配。这表明可能存在中间人攻击或配置问题。

您可以检查 MTA-STS 策略文件中的 MX 记录，确保它们与域的 MX 记录相匹配。

3.握手和协议问题

握手失败

在发件人邮件服务器和收件人邮件服务器之间的初始TLS 握手过程中出现问题，导致无法建立安全通道。仔细检查 SMTP STARTTLS 连接是否已建立。导致加密失败的原因有多种，如不支持 STARTTLS 或 TLS 降级攻击。

4.MTA-STS 政策问题

mta_sts_policy_not_found

当发件人的邮件服务器无法找到收件人域的 MTA-STS 策略时，就会出现这种故障。查看您的 MTA-STS 策略文件。您应检查 MTA-STS 记录，确保已正确发布。

mta_sts_policy_invalid

当在 DNS 中找到的收件人域的 MTA-STS 策略无效、包含错误或不符合 MTA-STS 规范时，就会出现这种故障。查看 MTA-STS 策略文件。指定适当的 MTA-STS 策略模式。可以是 "无"、"强制 "或 "测试"。这将指示发送服务器如何处理 MTA-STS 策略验证失败的电子邮件。

mta_sts_policy_fetch_error

当发件人的邮件服务器试图从收件人域名的 DNS 记录中检索 MTA-STS 策略时遇到错误，就会出现这种故障。您应该验证 DNS 中的 MTA-STS 记录，以确保记录语法正确。

mta_sts_connection_failure

当发件人的邮件服务器尝试使用 MTA-STS 建立安全连接，但由于不信任的证书、不支持的密码套件或其他 TLS 问题等原因而失败时，就会出现这种故障。您应该检查证书的有效性，并确保证书符合最新的 TLS 标准。

mta_sts_invalid_hostname

当 MTA-STS 策略中指定的收件人邮件服务器主机名与服务器的实际主机名不匹配时，就会出现这种故障。您应检查 MTA-STS 策略文件中的 MX 记录，确保它们与域的 MX 记录相匹配。

实施 TLS-RPT 的最佳实践

定期监控 TLS 报告

应定期监控 TLS 报告，以确保不会错过未发送的邮件。您可以通过手动监控邮箱中的 JSON 报告，或使用报告分析工具（如 PowerTLS-RPT.

确保正确配置 MTA-STS 策略

为确保正确执行 TLS-RPT，您的 MTA-STS 策略应配置正确且无语法错误。您可以使用我们的 MTA-STS 检查器检查您的记录。

及时处理加密故障

一旦检测到 TLS 报告中列出的加密故障，就必须迅速采取措施，防止今后出现电子邮件可送达性问题。

使用安全的 TLS 协议版本

要避免不必要的加密失败，必须只使用最新的、受支持的 TLS 协议版本。

利用 PowerDMARC 简化 SMTP TLS 报告

PowerDMARC 的 SMTP TLS 报告体验旨在提高您的安全性，同时通过托管服务使您的生活更加轻松。

翻译的TLS报告

您复杂的 TLS-RPT JSON 报告将被转换为简化信息，您可以在几秒钟内浏览或详细阅读。

自动检测问题

PowerDMARC 平台能精确定位并突出显示您所面临的问题，这样您就可以在不浪费时间的情况下解决问题。

PowerDMARC 平台没有一件事是我喜欢的，他们的布局简单易懂，功能齐全，可以实现托管 DMARC 控制、 SPF 扁平化，能够轻松扩展 SPF，以检查记录的具体内容，甚至完全支持 MTA-STS 和 TLS-RPT！

迪伦-B（企业主）

有关传输层安全的常见问题

TLS 代表什么？

TLS是传输层安全的缩写。

谁颁发 TLS 证书？

证书颁发机构（CA）可以颁发 TLS 证书。签发证书的过程包括验证证书持有者的身份。一旦身份验证成功，就会签发证书。

为什么需要 TLS 证书？

TLS 证书在确保互联网通信安全方面发挥着举足轻重的作用。它们有助于加密敏感信息通信网络服务器之间交换的敏感信息进行加密。其最常见的用途包括确保电子邮件通信和 HTTPS 的安全。

当前的 TLS 标准是什么？

TLS 1.3 是传输层安全的最新版本。TLS-RPT 可以使用任何版本的 TLS 实现。这可以包括协议的旧版本或未来版本。版本通常由通信服务器的能力等标准决定。

Yunes Tarada

域名和电子邮件安全专家PowerDMARC

Yunes 是 PowerDMARC 的运营团队负责人，拥有电子邮件验证和安全方面的专业知识。Yunes 是微软认证的 Azure 管理员助理，并获得了 CompTIA A+ 等认证。

Yunes Tarada 的最新帖子(查看全部)

电子邮件加盐攻击：隐藏文本如何绕过安全性- 2025 年 2 月 26 日
SPF 扁平化：它是什么，为什么需要它？- 2025 年 2 月 26 日
DMARC 与 DKIM：主要区别及如何协同工作- 2025 年 2 月 16 日

什么是SMTP TLS报告（TLS-RPT）？