RFC 7817：电子邮件的更新型TLS服务器身份检查

Current Standard Transport Security Published March 2026

ELI5: 当您通过HTTPS连接到网站时，您的浏览器会检查证书是否与域名匹配。电子邮件服务器在通过TLS相互连接时需要做同样的事情——但通过MX记录的电子邮件路由使其更加复杂。此RFC准确定义了发送服务器应该检查证书的名称。

为什么这个存在

当SMTP客户端通过STARTTLS（根据RFC 3207）或隐式TLS（根据RFC 8314）启动到远程邮件服务器的TLS连接时，它会收到一份证书。但该证书中应该出现哪个主机名？

在电子邮件中，您不会直接连接到收件人的域。您查找example.com的MX记录，它可能指向mail.hosting-provider.net。证书应该说example.com还是mail.hosting-provider.net？答案很重要，因为：

检查错误的名称意味着合法的证书被拒绝
根本不检查意味着TLS提供加密但没有身份验证——中间人可以提供任何证书
电子邮件托管提供商从同一服务器为数千个域提供服务，无法为每个客户域获取证书

工作原理

RFC 7817定义了一个清晰的层级结构，说明客户端应根据服务器的发现方式对照服务器证书检查哪些参考标识符：

身份验证检查顺序

MX主机名 — 如果通过MX查询发现服务器，请对照MX主机名（例如mail.hosting-provider.net）而不是收件人域检查证书。
收件人域 — 如果没有MX记录，客户端回退到域本身的A/AAAA记录，请对照收件人域检查。
显式配置 — 如果服务器是手动配置的（例如提交服务器），请对照配置的主机名检查。

TLS连接流程

; 第1步：解析收件人域的MX
dig example.com MX
example.com.  IN  MX  10 mail.provider.net.

; 第2步：连接到MX主机，启动SMTP
220 mail.provider.net ESMTP ready
EHLO sender.example.org
250-mail.provider.net
250-STARTTLS
STARTTLS
220 Go ahead

; 第3步：TLS握手 — 对照"mail.provider.net"检查证书
; 证书SAN：DNS:mail.provider.net, DNS:*.provider.net
; 找到匹配 → 身份已验证

关键技术细节

证书匹配规则

字段	检查	说明
主体备用名称(SAN)	首选	首先检查SAN扩展中的DNS-ID条目
通用名称(CN)	备用	仅当不存在SAN DNS-ID条目时（已弃用的做法）
通配符	仅限最左边标签	`*.provider.net`匹配`mail.provider.net`但不匹配`a.b.provider.net`

按发现方法的参考标识符

发现方法	对照以下内容检查证书	示例
MX查询	MX主机名	证书必须匹配`mail.provider.net`
A/AAAA回退(无MX)	收件人域	证书必须匹配`example.com`
SRV记录(RFC 6186)	SRV目标主机名	证书必须匹配SRV目标
手动配置	配置的主机名	证书必须匹配管理员设置的内容
MTA-STS策略(RFC 8461)	策略中的MX主机名	策略限制哪些MX名称可接受

与DANE的交互

部署DANE时(RFC 7672)，DNS中MX主机名的TLSA记录会固定证书或公钥。DANE提供比传统的基于CA的验证更强的身份保证，因为它不依赖于信任证书颁发机构 — 域所有者直接在DNSSEC签名的DNS中发布预期的证书数据。

常见错误

对照收件人域检查证书。如果example.com的MX指向mail.google.com，证书会说mail.google.com而不是example.com。检查错误的名称会导致TLS失败或迫使您跳过验证。
以静默方式回退到未经验证的TLS。许多MTA使用"机会TLS" — 如果可能的话加密但不验证证书。这可以保护免受被动窃听，但不能防御主动攻击。使用MTA-STS或DANE来要求经过验证的连接。
在MX主机上错误配置证书。如果您的MX记录指向mx.yourdomain.com但您的证书只涵盖yourdomain.com，验证证书的发件人将失败。确保您的证书SAN包括您的MX主机名。
忽略证书链验证。验证主机名是必要的但不充分。完整的证书链必须对受信任的根CA有效。过期或自签名证书即使名称匹配也会失败。
不在证书过期前续签。MX服务器上过期的证书会导致TLS握手失败。执行MTA-STS的发件人将拒绝向具有过期证书的服务器投递邮件。

可投递性影响

MTA-STS执行取决于此。当接收域发布MTA-STS策略时，发送服务器必须根据RFC 7817验证MX证书。如果您的MX证书配置错误，执行MTA-STS的发件人（包括Gmail）将不会向您投递邮件。
Google和Microsoft验证证书。主要提供商越来越多地对出站邮件执行证书验证。接收基础设施上配置错误的证书可能导致这些发件人的投递失败。
DANE/TLSA提供最强的保证。DANE将证书与DNSSEC绑定，完全消除了CA信任依赖性。结合RFC 7817身份检查，它提供经过验证、加密的电子邮件传输。
TLS报告揭示问题。SMTP TLS报告(RFC 8460)在发件人连接到您的服务器时遇到TLS失败时向您发送报告，包括证书验证失败。发布TLSRPT记录并监控这些报告。