TXT 记录详解：SPF、DKIM 与 DMARC

TXT 记录存放附加在域名上的任意文本。这听起来微不足道，但整个邮件信任体系正是通过它发布的，此外，您会做的大多数域名所有权验证也都依靠它。

核心问题在于，诞生于 1982 年的 SMTP 允许任何服务器声称以任何域名的身份发信，协议本身没有任何机制来阻止。SPF、DKIM 和 DMARC 是后来为解决这个问题而加上的三层机制，而且三者都存放在 TXT 记录中。

SPF：哪些服务器可以以您的名义发信

SPF（Sender Policy Framework，发件人策略框架）发布一份获准为您的域名发送邮件的服务器列表。接收服务器会把连接进来的 IP 与该列表进行比对。

example.com.    3600    IN    TXT    "v=spf1 include:_spf.google.com ip4:93.184.216.34 ~all"

DKIM：加密签名

DKIM（DomainKeys Identified Mail）使用私钥对每封外发邮件签名。您在 DNS 中发布与之匹配的公钥，接收方据此验证签名。

selector1._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..."

selector1 部分由您的邮件服务商选定，并包含在每封已签名的邮件中，让接收方知道要获取哪把密钥。使用选择器意味着您可以轮换密钥，或同时使用多家服务商而不冲突。

DKIM 相对于 SPF 的优势在于，签名涵盖邮件本身，所以转发后依然有效。它的弱点在于，对于完全没有签名就到达的邮件，它什么都说明不了，而这正是 DMARC 弥补的空白。

DMARC：前两者失败时该怎么办

DMARC（Domain-based Message Authentication, Reporting and Conformance）把另外两者联系起来：它要求 SPF 或 DKIM 不仅要通过，还要与可见的 From 地址对齐，并告诉接收方在失败时该怎么处理。

_dmarc.example.com.    IN    TXT    "v=DMARC1; p=quarantine; rua=mailto:reports@example.com; pct=100"

安全地部署这三者

顺序很重要。直接上 p=reject，是让您自己的发票邮件无法送达的经典做法。

1. 1

   盘点所有以您的名义发信的系统

   当然有您的邮件服务商，但还有开票工具、CRM、营销平台、工单系统，以及您应用的事务性邮件。这里遗漏的任何一项，之后都会出问题。

2. 2

   发布带软失败的 SPF

   把第一步中的每个发件方都包含进来，并以 ~all 结尾。软失败会把未列出的发件方标记为可疑，而不会在您核实列表期间毁掉邮件。

3. 3

   启用 DKIM 签名

   在每个服务商处开启，并发布它们提供的选择器记录。发送一封测试邮件，确认签名验证通过。

4. 4

   DMARC 从 p=none 开始

   仅监控。收集两到四周的汇总报告，它们会暴露您忘记的发件方。

5. 5

   逐步收紧

   一旦报告显示只有合法来源通过，就转到 p=quarantine，可以先配合 pct=25，等到干净之后再转到 p=reject。

TXT 记录不只用于邮件

同一种记录类型还承载着几十种服务的域名所有权验证，Google Search Console、Microsoft 365、Facebook 等都会要求您把一个令牌发布为 TXT 记录，然后再去检查它。

example.com.    IN    TXT    "google-site-verification=rXsLp2..."
example.com.    IN    TXT    "MS=ms12345678"

这些记录可以和平共存。一个域名可以拥有许多条 TXT 记录；唯一的规则是，以 v=spf1 开头的必须有且只有一条。

用查询工具查看任意域名，可以同时看到它的所有 TXT 记录，这是发现重复 SPF 记录或从未移除的验证令牌的快捷方法。