SPF、DKIM 与 DMARC 详解：示例记录与稳妥的 DMARC 上线步骤

SPF、DKIM 和 DMARC 是三条 DNS 记录，用来向邮箱服务商证明“这封邮件确实是你发的”。如今 Gmail、Yahoo 和 Outlook 都要求大量发信的发件人三者齐备，缺了它们的邮件更容易被过滤，甚至直接被拒收。

本文讲清每条记录的作用，给出可以照着改的示例记录，并带你走一遍不会误伤自己邮件的 DMARC 上线流程。所有示例都用 example.com，实际使用时换成你自己的域名和邮件服务商提供的值。

一句话说清三者

SPF 和 DKIM 各自验证的是“某个”域名。DMARC 则把验证结果和读者在“发件人”一栏真正看到的域名绑在一起。这一步叫“对齐”（alignment），也是大多数配置出问题的地方。

SPF：谁可以替你的域名发信

SPF（Sender Policy Framework，RFC 7208）是一份允许为某个域名发信的服务器清单。收件服务器查的是信封发件人（也叫 MAIL FROM 或 Return-Path）域名的 SPF 记录，而不是读者看到的 From 地址，然后判断当前连接的 IP 是否在清单里。

假设你通过 Google Workspace 和一家邮件服务商发信，SPF 记录示例如下：

example.com.  TXT  "v=spf1 include:_spf.google.com include:spf.mail-provider.example ~all"

从左到右看：

• v=spf1 表示这是一条 SPF 记录。
• 每个 include: 引入另一个域名的服务器清单，具体加哪个由邮件服务商告诉你。
• ip4:、ip6: 直接列出地址，例如 ip4:203.0.113.10。
• ~all 表示“其他来源大概率未获授权”（softfail）；-all 表示“其他来源一律未获授权”（fail）。

在你还没摸清所有发信来源时，先用 ~all。RFC 7208 指出，收件方不应仅凭 softfail 就拒收邮件，所以它更宽容。确认清单完整后再改成 -all。

10 次查询上限

RFC 7208 规定，SPF 检查最多只能触发 10 次 DNS 查询。include、a、mx、ptr、exists 机制和 redirect 修饰符都计数，被 include 进来的记录里的查询同样计数；ip4、ip6 和 all 不计数。超过 10 次，结果就是 permerror：所有邮件的 SPF 都失败，而不是部分失败。

规范还建议收件方把“空查询”（查不到结果的查询）限制在两次以内。如果某个 include: 指向你早已停用、记录也已删除的服务商，就可能触发这一条。

想控制在上限以内：删掉已不再使用的服务的 include:，完全不用 ptr，自有服务器尽量用 ip4: 网段。如果你同时用很多家服务商，把其中一部分放到子域名上（每个子域名有自己的 SPF 记录）也能缓解。

DKIM：给每封邮件签名

DKIM（DomainKeys Identified Mail，RFC 6376）会在每封邮件上加一个加密签名。发信服务器用私钥对指定的邮件头和正文签名；收件方读取 DKIM-Signature 头，找到域名（d=）和选择器（s=），再到 DNS 的 选择器._domainkey.域名 下取回公钥验证。

选择器为 mail2026 的 DKIM 记录示例：

mail2026._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

• p= 是公钥。密钥对由服务商生成，它会把这一串值给你；千万不要把私钥贴进 DNS。
• 有了选择器，你可以同时保留多把密钥，比如每家服务商一把，或者轮换时新旧并存。

很多服务商会让你发布一条 CNAME，把选择器指向它们托管的密钥：

s1._domainkey.example.com.  CNAME  s1.dkim.mail-provider.example.

这样它们轮换密钥时，你不用再改 DNS。

关于密钥长度：Google 要求发往个人 Gmail 账户的邮件使用至少 1024 位的 DKIM 密钥，并建议在 DNS 服务商支持时使用 2048 位。Yahoo 建议密钥长度至少 1024 位。2048 位的长密钥有时需要拆成多个带引号的字符串放进同一条 TXT 记录，多数 DNS 面板会自动处理。

DMARC：把验证结果绑定到 From 地址

DMARC（Domain-based Message Authentication, Reporting and Conformance）做两件事：告诉收件方，自称来自你域名但验证失败的邮件该怎么处理；同时请收件方把所有使用你域名的邮件情况汇报给你。

DMARC 最早发布为 RFC 7489。2026 年 5 月，IETF 用 RFC 9989（核心协议）取代了它，另有 RFC 9990（汇总报告）和 RFC 9991（失败报告）。以 v=DMARC1 开头的现有记录照常有效。

起步用的 DMARC 记录：

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

用例子讲清“对齐”

一封邮件只要满足其中一条就能通过 DMARC：

• SPF 通过，且它检查的信封域名与 From 域名对齐；或者
• DKIM 通过，且签名域名（d=）与 From 域名对齐。

宽松对齐（默认）下，“对齐”指两个域名属于同一个组织域名；严格对齐则要求完全相同。

第三行是最典型的坑：邮件服务商用自己的信封域名发信、用自己的域名做 DKIM 签名。SPF 和 DKIM 都“通过”了，但通过的是它的域名，所以你的 DMARC 失败。解决办法是在服务商那里开启自定义域名认证，让它用 d=example.com 签名，最好再配一个 bounce.example.com 这样的退信子域名。

Google 和 Microsoft 都建议 SPF 和 DKIM 两者都对齐，而不只是其中一个。DKIM 对齐尤其重要：邮件被转发时 SPF 会失效，DKIM 通常还能保留。

如何上线 DMARC 而不误伤自己的邮件

最终目标是 p=reject：收件方直接拒收冒充你的邮件。但一步到位，很可能把你自己的发票、客服回复，或某个被遗忘的工具发出的通讯一并拒掉。Microsoft 的建议是逐步推进：从 none 到 quarantine 再到 reject，每一步都观察报告。dmarc.org 也给出同样的建议：先发布一条只收报告的监控记录。

第 1 步：列出所有以你的域名发信的服务

别只想到营销平台：Google Workspace 或 Microsoft 365、店铺或计费系统、客服系统、CRM、开票工具、开发信工具。每一个都需要通过 SPF 或 DKIM，并且对齐。

第 2 步：发布 p=none，开始收报告

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

p=none 不会改变任何投递结果，但已经满足 Gmail、Yahoo 和 Outlook 对批量发件人的要求，三家都接受 p=none 作为最低标准。发送报告的收件方通常大约每天发来一份。

第 3 步：读汇总报告

汇总报告（rua）是 XML 文件，按发信 IP 列出：用你的域名发了多少封、SPF 和 DKIM 是否通过、是否对齐。你要找的是：

• 未对齐的正常来源：在对应服务商那里配置自定义 DKIM 或自定义退信域名。
• 你不认识的来源：多半是被遗忘的工具，也可能是有人在冒充你，而这正是开启强制策略后要拦下的。

原始 XML 很难读。Microsoft 建议用 DMARC 报告服务或自写脚本，把报告整理成一眼能看懂的形式。rua 用一个专用邮箱接收，不要用某个人的个人邮箱；上线期间每周看一次报告。

如果报告地址和被监控的域名不在同一个域名下，接收报告的那个域名必须发布一条授权记录，否则收件方不会发送报告：

example.com._report._dmarc.reports-vendor.example.  TXT  "v=DMARC1;"

大多数 DMARC 报告服务会在自己那边配好这条记录。

第 4 步：改为 quarantine

当正常来源连续几周都稳定通过并对齐后，修改策略：

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

验证失败的邮件现在会进入垃圾箱。继续关注报告。

第 5 步：改为 reject

_dmarc.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]"

Microsoft 建议先在发信量小的域名或子域名上走完整个流程，主域名留到最后。

不发信的域名

闲置域名很容易被冒用。发布记录，声明它们不会发出任何邮件：

parked-example.com.         TXT  "v=spf1 -all"
_dmarc.parked-example.com.  TXT  "v=DMARC1; p=reject;"

常见错误

1. 同一个域名有两条 SPF 记录。RFC 7208 规定这会导致 permerror。合并成一条，里面放多个 include:。
2. SPF 超过 10 次 DNS 查询。同样是 permerror。嵌套的 include 也要算进去。
3. 两条 DMARC 记录。RFC 9989 规定收件方会全部丢弃，等于你完全没有策略。
4. DKIM 用服务商的域名签名。DKIM 通过，DMARC 失败。开启自定义域名签名。
5. 直接上 `p=reject`。转发邮件和被遗忘的工具会被拒收。先监控。
6. 只在 From 域名上配 SPF。SPF 检查的是信封域名。如果服务商用它自己的退信域名，你的 SPF 记录根本不会被查到。
7. 拼写错误和多余引号。少一个分号，或者记录被发布成 _dmarc._dmarc.example.com（有些 DNS 面板会自动追加域名），都会让配置悄悄失效。
8. 用免费邮箱地址发信。你没法为 gmail.com 发布 DNS 记录。Google 要求发件人不要冒用 Gmail 的 From 头，并表示 Gmail 将开始对这类邮件执行 DMARC quarantine 策略，所以一定要用自己的域名发信。

如何检查你的记录

• 命令行：dig TXT example.com、dig TXT _dmarc.example.com、dig TXT mail2026._domainkey.example.com（Windows 上用 nslookup -type=TXT）可以看到实际发布的内容。
• 邮件头：在 Gmail 里打开一封你发给自己的邮件，点“更多”（三个点），选择显示原始邮件（Show original）。顶部摘要会显示 SPF、DKIM、DMARC 的结果。Authentication-Results 头里能看到被检查的域名（smtp.mailfrom=、header.d=、header.from=），对齐问题就是这样发现的。
• Google Postmaster Tools 为已验证的域名提供“身份验证”和“合规状态”看板。

如何检查邮件头，我们在邮件为什么进垃圾箱里讲得更细。

EterMail 能做什么

EterMail 是我们自己的产品。添加发信域名时，它会列出需要发布的记录，并在活动可以发送前检查域名已通过验证、且有 DMARC 记录。开发信方面，它会检查每个开发信域名的 SPF、DKIM、DMARC 和 MX。开发信应该和通讯邮件用不同的域名，各自配好记录，原因见开发信送达率指南。

身份验证只是入场券，不是全部。各家邮箱服务商在此之上还有哪些要求，请看 Gmail、Yahoo 与 Outlook 发件人要求；关于信誉和互动，请看邮件送达率指南。

常见问题

SPF、DKIM 和 DMARC 有什么区别？

SPF 列出允许为你的信封域名发信的服务器。DKIM 为每封邮件签名，让收件方能验证签名域名，并确认邮件未被改动。DMARC 检查读者在“发件人”一栏看到的域名是否与通过 SPF 或 DKIM 的域名一致，不一致时告诉收件方怎么处理，并把报告发给你。

三个都需要吗？

如果你大量发信，需要。Gmail 和 Yahoo 要求批量发件人同时使用 SPF、DKIM 和 DMARC；Microsoft 对每天向 Outlook.com 地址发送超过 5,000 封邮件的域名也有同样要求。即使发信量不大，三者齐备也能让你的邮件更可信，域名更难被冒用。

刚开始用什么 DMARC 记录比较好？

在 _dmarc.example.com 上发布一条 TXT 记录：v=DMARC1; p=none; rua=mailto:[email protected]。它不影响投递，但能开始收集报告。等报告显示所有正常邮件都通过并对齐后，再改为 quarantine，然后 reject。

p=none 要保持多久？

没有固定期限。要一直保持到汇总报告显示，在一个完整的发信周期里（包括月度账单、季节性活动），所有正常来源都通过并对齐。对很多发件人来说是几周；Microsoft 建议上线期间每周查看一次报告。

可以有两条 SPF 记录吗？

不可以。RFC 7208 规定，一个域名有多条 SPF 记录会返回 permerror，你所有邮件的 SPF 都会失败。把所有发信来源合并到一条记录里，用多个 include:，并把 DNS 查询总数控制在 10 次以内。

为什么 SPF 和 DKIM 都通过了，DMARC 却失败？

因为它们通过的是另一个域名。如果邮件服务商用自己的退信域名，又用自己的域名做 DKIM 签名，两者都不会与你的 From 域名对齐。在服务商那里开启自定义域名认证，让它用你的域名签名即可。