RFC 8460: SMTP TLS 报告 (TLSRPT)

Current Standard Abuse Reporting & Feedback Published March 2026

ELI5: 你发布了一份 MTA-STS 政策，说明"发送邮件给我时始终使用 TLS"。但你如何知道发件人是否真的能够安全地连接？TLSRPT 是反馈机制——发送服务器在向你的域投递时收集 TLS 成功和失败的数据，并每天向你发送一份 JSON 报告，以便你能发现问题。

存在的原因

两项标准对服务器间电子邮件强制实施TLS：MTA-STS（RFC 8461）和DANE（RFC 7672）。两者都告诉发送服务器"在向此域投递邮件之前必须建立有效的TLS连接"。但当TLS协商失败时，发送服务器要么回退到明文（不安全）要么拒绝投递（邮件丢失）。无论哪种情况，接收域都不知道存在问题。

TLSRPT填补了这一可见性缺口。域所有者发布DNS记录来请求TLS报告，发送MTA将其TLS连接结果聚合为每日JSON报告，通过电子邮件或HTTPS投递。

没有TLSRPT，你可能部署了MTA-STS但存在证书错误，却没意识到大量进入的邮件被拒绝或以不安全方式投递。

工作原理

第1步：发布TLSRPT DNS记录

在_smtp._tls.yourdomain.com添加TXT记录，指定报告应发送到何处：

; 通过电子邮件发送TLS报告 _smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com" ; 通过HTTPS POST发送TLS报告 _smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=https://report.example.com/tlsrpt" ; 发送到多个目标 _smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com,https://report.example.com/tlsrpt"

第2步：发送服务器收集数据

当发送MTA向你的域投递邮件时，它记录TLS协商结果：成功会话（有效证书）、握手失败、证书不匹配、MTA-STS策略失败、DANE验证失败等。

第3步：每日报告投递

每天一次，发送MTA聚合其结果并发送JSON报告。通过电子邮件投递时，它作为multipart/report消息到达，其中report-type=tlsrpt：

Content-Type: multipart/report; report-type=tlsrpt;
    boundary="TLSRPT-001"

--TLSRPT-001
Content-Type: text/plain

SMTP TLS report for example.com
Report period: 2026-03-10T00:00:00Z to 2026-03-11T00:00:00Z

--TLSRPT-001
Content-Type: application/tlsrpt+json

{
  "organization-name": "Sender Corp",
  "date-range": {
    "start-datetime": "2026-03-10T00:00:00Z",
    "end-datetime": "2026-03-11T00:00:00Z"
  },
  "contact-info": "postmaster@sendercorp.com",
  "report-id": "2026-03-10-example.com",
  "policies": [{
    "policy": {
      "policy-type": "sts",
      "policy-string": ["version: STSv1", "mode: enforce",
        "mx: mail.example.com", "max_age: 604800"],
      "policy-domain": "example.com"
    },
    "summary": {
      "total-successful-session-count": 9450,
      "total-failure-session-count": 12
    },
    "failure-details": [{
      "result-type": "certificate-expired",
      "sending-mta-ip": "198.51.100.1",
      "receiving-mx-hostname": "mail.example.com",
      "failed-session-count": 12
    }]
  }]
}

--TLSRPT-001--

关键技术细节

DNS记录格式

标签	必需	说明
`v`	是	版本；必须是`TLSRPTv1`
`rua`	是	报告URI。`mailto:`用于电子邮件投递，`https:`用于HTTPS POST。多个目标用逗号分隔。

失败结果类型

result-type	含义
`starttls-not-supported`	接收服务器未通告STARTTLS
`certificate-host-mismatch`	证书主机名与MX主机名不匹配
`certificate-expired`	服务器的TLS证书已过期
`certificate-not-trusted`	证书未由受信任的CA签名
`validation-failure`	常见TLS验证失败
`sts-policy-invalid`	MTA-STS策略无法获取或解析
`sts-webpki-invalid`	MTA-STS策略主机证书无效
`tlsa-invalid`	DANE TLSA记录格式错误
`dnssec-invalid`	TLSA查询的DNSSEC验证失败
`dane-required`	需要DANE但TLSA记录不存在

策略类型

policy-type	含义
`sts`	MTA-STS策略（RFC 8461）
`tlsa`	DANE TLSA记录（RFC 7672）
`no-policy-found`	未找到该域的MTA-STS或DANE策略

常见错误

发布MTA-STS但未发布TLSRPT。 enforce模式的MTA-STS在TLS失败时将导致发送服务器拒绝邮件。没有TLSRPT，你看不到这些失败。应始终同时部署两者。
忽视报告。 接收TLSRPT报告仅在你实际解析和监控它们时才有用。设置自动处理或使用聚合和提醒失败的服务。
仅使用HTTPS投递。 虽然HTTPS POST对于自动处理更简洁，但某些发送MTA仅支持电子邮件投递。如果可能，同时提供mailto:和https: URI。
DNS记录位置错误。 记录必须在_smtp._tls.yourdomain.com，而非_tls.yourdomain.com或_tlsrpt.yourdomain.com。前缀特别是_smtp._tls。
让证书过期。 通过TLSRPT报告的最常见失败是certificate-expired。自动化证书更新（例如使用Let's Encrypt）并监控到期日期。
不检查MX主机名与证书。 你的TLS证书必须涵盖MTA-STS策略和MX记录中列出的主机名。如果你的MX是mail.example.com但证书是example.com，发送者将报告certificate-host-mismatch。

可投递性影响

看清TLS失败。 没有TLSRPT，TLS协商失败是看不见的。你不知道来自主要发送者的邮件因上周证书过期而被拒绝。
安全MTA-STS强制的前提条件。 推荐的部署路径是：以testing模式发布MTA-STS，启用TLSRPT，监控报告以查找失败，修复问题，然后切换到enforce。跳过监控步骤会导致邮件丢失风险。
检测中间人攻击。 来自特定网络的certificate-not-trusted或starttls-not-supported突增可能表示STARTTLS剥离攻击。TLSRPT使其可见。
合规证据。 对于处理敏感通信的域，TLSRPT报告提供证据表明大多数进站连接成功协商了TLS。