如何配置 SPF、DKIM 和 DMARC - 分步教程 + 验证

这是一份动手实操的配置指南：如何为你自己发信的域名发布 SPF、DKIM 和 DMARC，让发信 IP 远离 RBL 黑名单，并验证一切确实生效。如果你想先了解每种机制是什么的通俗理论，可以读任意一篇关于“电子邮件认证如何工作”的入门介绍——这里我们只专注于你要创建的记录、发布它们的先后顺序，以及那些会让真实邮件出问题的错误。

开始之前，先准备好两样东西：

访问你域名的 DNS 区域（在这里添加 TXT 记录）的权限——通常是你的注册商或 DNS 托管商。
一份书面清单，列出每一个以你域名发信的服务：你的邮箱服务商（Google Workspace、Microsoft 365…）、你自己的邮件服务器，以及任何第三方——邮件订阅工具、CRM、账单/开票系统、客服工单。漏掉一个，它发出的邮件就会认证失败。

第 1 步 — 发布一条 SPF 记录

SPF 是位于域名根部的一条 TXT 记录，列出允许为该域名发信的服务器。让所有人都栽跟头的规则是：一个域名只能有一条 SPF 记录。如果你使用多个发信方，就把它们合并到同一行、用多个 include: 机制——而不是发布两条 SPF 记录。

一个通过 Google Workspace 加一个营销工具发信的域名，其典型记录如下：

example.com. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all"

部分	含义
`include:_spf.google.com`	通过引用来授权某个服务商的整个发信 IP 段。请从每个发信方的文档中获取确切的令牌。
`ip4:` / `ip6:`	用公网 IP 授权你自己的邮件服务器，例如 `ip4:203.0.113.10`。
`~all` 与 `-all`	`~all` = 软失败（测试期间从这里开始）；`-all` = 硬失败（清单完整后再切换到它）。

10 次查询上限。SPF 在被评估时最多允许 10 次 DNS 查询；每个 include: 和 a/mx 机制都可能消耗一次或多次。超过上限，SPF 就会返回 permerror——被视为失败。如果你叠加了很多服务商，请删掉不用的 include，或使用 SPF 扁平化（flattening）服务，而不是继续堆加更多。

先软后硬。先用 ~all 发布一到两周，确认没有合法发信方失败，再把最后一个机制改为 -all。

第 2 步 — 在每个发信方启用 DKIM

DKIM 为每一封邮件加上一个加密签名。你很少需要手工构建密钥——每个发信平台会生成它，并给你一条 TXT（或 CNAME）记录，让你发布在某个选择器（selector）下。要逐个发信方去做：Google、Microsoft、你的 ESP 以及你自己的服务器，各自都有自己的选择器和密钥。

在发信方的管理面板中，启用 DKIM /“电子邮件认证”。它会给你显示一个选择器（例如 google、s1）和一个公钥。
把它发布到 DNS 中的 <selector>._domainkey.example.com。使用 CNAME 的服务商可以替你轮换密钥——有此选项时优先选它。
回到面板，点击开始认证，让发信方开始添加 DKIM-Signature: 邮件头。在可以选择时，优先使用 2048 位密钥。

由于签名随邮件一起传递，DKIM 能在转发后依然有效（不像 SPF）——这正是下一步要依赖它的原因。

第 3 步 — 逐步推出 DMARC

DMARC 把 SPF 和 DKIM 与可见的 From: 地址绑定起来，并告诉收信方在失败时该怎么做。千万不要一开始就用 p=reject——你会退回自己某个忘了配置的发信方发出的合法邮件。请分三个阶段推出，在每个阶段之间观察报告。

阶段	`_dmarc.example.com` 处的记录	目的
1. 监测	`v=DMARC1; p=none; rua=mailto:dmarc@example.com`	对收件人不做任何改变；只收集谁在以你的名义发信的汇总报告。
2. 隔离	`v=DMARC1; p=quarantine; pct=25; rua=…`	把一部分失败邮件送进垃圾箱。随着信心增强逐步提高 `pct`。
3. 强制	`v=DMARC1; p=reject; rua=…; sp=reject`	直接拒收伪造邮件。`sp=` 设定子域名的策略。

rua= 地址每天会收到来自收信方的 XML 汇总报告。请阅读它们（起初一个免费的 DMARC 报告查看器就够了）：每份报告都列出使用你域名的发信 IP，以及它们是否在对齐（alignment）的前提下通过了 SPF 和 DKIM。对齐是关键所在——一封邮件不能只是通过 SPF 或 DKIM，通过的那个域名必须与 From: 域名相匹配。如果某个合法服务对它自己的域名通过了 DKIM，但对你的域名没通过，就在进入强制阶段之前，通过在你的域名下发布该服务的 DKIM（第 2 步）来修复它。

第 4 步 — 让你的发信 IP 远离 RBL

SPF/DKIM/DMARC 证明的是身份；RBL 黑名单（DNSBL）评判的是发信 IP 的信誉。一封认证完美的邮件，如果它的 IP 被列入名单，照样会落进垃圾箱。你无需为 RBL 发布任何东西——你要做的是让自己远离它们：

只发送对方想要的邮件。垃圾邮件投诉和撞上垃圾邮件陷阱（spam-trap）是上名单最快的方式。
逐步预热新 IP，而不是在第一天就大量猛发。
确保每一个能发信的账户和脚本都安全——单个被入侵的表单或密码，就会让整个 IP 被列入名单。
为你的发信 IP 设置有效的反向 DNS（PTR），并使其与其 HELO 名称相匹配。

如果你真的被列入名单，大多数有信誉的名单（Spamhaus 等）会显示原因，并在原因修复后提供自助解封。先修复，再申请移除——在问题仍存在时解封只会让你被重新列入。

第 5 步 — 验证它确实生效

发布了记录并不等于证明。请逐层确认：

检查记录是否存在。直接查询 DNS：dig TXT example.com、dig TXT google._domainkey.example.com、dig TXT _dmarc.example.com（在 Windows 上用 nslookup -type=TXT）。
确认你授权的邮件服务器。使用我们的 MX 查询来查看某个域名实际发布的 MX 主机——便于发现过时或错误的邮件主机。
在一封真实邮件上查看结果。给自己发一封测试邮件，打开它的原始源码，把它粘贴到 MIME 解码器中。查看 Authentication-Results: 邮件头——它会显示收信方所看到的 spf=pass、dkim=pass 和 dmarc=pass（或确切的失败原因）。那才是最真实的依据。
观察 DMARC 报告数周，然后再从 p=none 转向强制阶段。

常见的配置错误

症状	常见原因与修复
SPF `permerror`	存在两条 SPF 记录，或超过 10 次 DNS 查询。合并成一条记录；删掉不用的 `include:`。
合法邮件 SPF 失败	有一个你忘记授权的发信方，或邮件被转发了。添加该发信方；转发的情况依靠 DKIM+DMARC 对齐。
DKIM `fail`（正文哈希）	某个环节在传输途中改写了邮件（邮件列表页脚、某个网关设备）。用宽松（relaxed）规范化方式签名；排除易变的邮件头。
SPF/DKIM 通过但 DMARC 失败	没有对齐——通过的那个域名不是你的 `From:` 域名。请在你自己的域名下发布该发信方的 DKIM。
子域名被伪造	没有子域名策略。在 DMARC 记录中加上 `sp=reject`。

一旦三条记录全部上线、对齐并通过验证——而且你的 IP 一直远离黑名单——你就关上了别人伪造你域名的大门，也为你的真实邮件争取到了进入收件箱的最佳机会。要逐一核查任意域名上的单个地址，首页上的邮箱检查器会为你运行实时的信箱检查。