← RFC Reference

RFC 6186：电子邮件服务自动发现的SRV记录

这为什么存在

配置电子邮件客户端需要知道多个服务器主机名、端口和安全设置：用于读取邮件的 IMAP 或 POP3 服务器，以及用于发送邮件的提交服务器。大多数用户无法提供这些信息。在 SRV 记录出现之前，电子邮件客户端依赖于：

• 猜测常见的主机名，如 mail.example.com 或 imap.example.com
• 专有的自动发现协议（Microsoft Autodiscover、Mozilla ISPDB）
• 手动配置指南

RFC 6186 提供了一种基于 DNS 的标准机制，适用于任何域。域管理员发布 SRV 记录，任何兼容的电子邮件客户端都可以自动发现正确的服务器。

工作原理

电子邮件客户端从用户的电子邮件地址中提取域，然后查询 DNS 以获取特定服务名称下的 SRV 记录。

SRV 记录格式

名称：     _service._proto.domain
类型：     SRV
内容：  priority weight port target

所需的 DNS 记录

对于域 example.com，电子邮件托管在 mail.provider.net 上：

; 接收邮件（IMAP over TLS）
_imaps._tcp.example.com.    IN SRV  0 1 993 mail.provider.net.

; 接收邮件（IMAP with STARTTLS）
_imap._tcp.example.com.     IN SRV  0 1 143 mail.provider.net.

; 接收邮件（POP3 over TLS）
_pop3s._tcp.example.com.    IN SRV  0 1 995 mail.provider.net.

; 发送邮件（Submission over TLS）
_submissions._tcp.example.com. IN SRV  0 1 465 mail.provider.net.

; 发送邮件（Submission with STARTTLS）
_submission._tcp.example.com.  IN SRV  0 1 587 mail.provider.net.

禁用服务

要表明服务不可用，请发布一条 SRV 记录，其目标为 .（单个点）：

; 我们不提供 POP3
_pop3._tcp.example.com.     IN SRV  0 0 0 .
_pop3s._tcp.example.com.    IN SRV  0 0 0 .

关键技术细节

RFC 6186 定义的服务名称

客户端发现优先级

1. 首先查询 _imaps._tcp（根据 RFC 8314，隐式 TLS 优于 STARTTLS）。
2. 如果没有 _imaps 记录，回退到 _imap._tcp（强制使用 STARTTLS）。
3. 对于提交，优先选择 _submissions._tcp（端口 465）而不是 _submission._tcp（端口 587）。
4. 使用 SRV 优先级和权重字段在多个服务器之间进行负载平衡和故障转移。

TLS 证书验证

根据 RFC 7817，客户端必须针对 SRV 目标主机名（例如 mail.provider.net）而不是用户的电子邮件域验证服务器的 TLS 证书。这允许托管提供商用单个证书为多个域提供服务。

常见错误

• 完全不发布 SRV 记录。许多域依赖专有的自动发现或假设用户会手动配置。发布 SRV 记录只需几分钟，可以帮助每个符合标准的电子邮件客户端。
• 仅发布 STARTTLS 变体。RFC 8314 建议使用隐式 TLS。将 _imaps 和 _submissions 记录（隐式 TLS）发布为主要选项，STARTTLS 变体作为后备。
• SRV 目标指向 CNAME。SRV 目标必须是 A 或 AAAA 记录，而不是 CNAME。这是 DNS 协议要求（RFC 2782）。将 SRV 指向 CNAME 可能导致解析失败。
• 忘记禁用未使用的服务。如果不支持 POP3，发布一条"点"SRV 记录来明确告知客户端。否则他们可能会花时间探测永远不会响应的端口。
• 证书与 SRV 目标不匹配。如果 SRV 记录目标是 mail.provider.net，该服务器上的 TLS 证书必须在其 SAN 中包含 mail.provider.net。不匹配会导致验证证书的客户端连接失败。

可送达性影响

• 减少用户配置错误。自动发现意味着更少的用户输入错误的设置，这意味着更少的"无法发送"支持工单和更少的邮件卡在发件箱中。
• 从一开始就强制执行 TLS。通过仅通过 SRV 发布 TLS 启用的服务，可以确保客户端默认安全连接，而不是以未加密的方式开始。
• 实现顺畅的托管迁移。将电子邮件移至新提供商时，更新 SRV 记录，客户端将自动找到新服务器，无需手动重新配置。
• 补充提交最佳实践。_submissions 的 SRV 记录将客户端定向到正确的身份验证提交端口（RFC 6409），使提交流量与 MX 中继流量保持适当分离。

Related RFCs