SPF、DKIM 与 DMARC：邮件认证的三条记录、判定流程与五个误区

邮件进垃圾箱，常见原因不是正文写了什么，而是发件域名没过认证。SPF 用 DNS 记录声明哪些服务器可以代发，DKIM 用签名证明内容在传输中没有被改动。DMARC 再把这两项结果与 From 头里的域名对齐，并按域名主人的意愿决定放行还是拦截。

2026 年 5 月 20 日，IETF 发布了 RFC 9989、RFC 9990、RFC 9991 三份文档，DMARC 由此从信息性文档升为正式标准。下面按「各管什么、记录怎么写、一封信怎么判、自己怎么配、新规范改了什么、容易错在哪」的顺序讲一遍。

三套机制各管一段

三者不是替代关系，而是从不同角度回答同一个问题：这封信是否真的由这个域名发出。

SPF 检查的是 SMTP 会话里的 MAIL FROM，也就是信封发件人，并非收件箱里显示的 From 头。这个差别决定了它挡不住哪一类伪造。

DKIM 的签名写在 DKIM-Signature 头里，d= 是签名域，s= 是选择器。收信方把两者拼成查询名，取回公钥验签，字段含义见 RFC 6376。

RFC 8301 要求签名算法使用 rsa-sha256，RSA 密钥不少于 1024 位，并建议 2048 位。低于 1024 位的签名会被直接判为无效。

DMARC 自身不做密码学校验。它比对域名的对齐关系，再按发布者写下的策略决定放行、隔离或拒收。

三条记录长什么样

三条记录都是 TXT，区别在名称、字段与出错方式。

SPF 的查询预算很紧。RFC 7208 规定 include、a、mx、ptr、exists 与 redirect 合计不超过 10 次查询，返回空答案的查询另限 2 次。超出预算即返回 permerror，整条记录失效。

同一域名下出现两条 SPF 记录，结果同样是 permerror。合并时要把旧记录删掉，而不是再发一条新的。

2048 位 RSA 公钥转成 base64 后常常超过单段长度上限，实践中会拆成多段写进同一条 TXT，解析时按顺序拼接。手工粘贴时漏掉一段，验签会一直失败。

DMARC 的版本标签必须排在记录开头，取值只接受 DMARC1，且区分大小写。写错、漏写或位置不对，整条记录会被忽略。

p 有三档取值：none 只观察，quarantine 建议投入垃圾箱，reject 建议拒收。字段缺省时按 none 处理。

一封信的判定流程

1. 发信方在 SMTP 会话里给出 MAIL FROM，收信方用它的域去查 SPF 记录。
2. SPF 求值，命中授权列表为 pass，明确不在列表为 fail，允许但可疑为 softfail。
3. 收信方解析 DKIM-Signature 头，按 d= 与 s= 取回公钥，校验头哈希与正文哈希。
4. 做对齐判断。SPF 通过且 MAIL FROM 域与 From 域对齐，或者 DKIM 通过且 d= 与 From 域对齐，都记为 DMARC pass。
5. 两项都没通过或都没对齐，进入失败处理，按 p、sp、np 的取值放行、隔离或拒收。
6. 按 rua 与 ruf 回传报告。聚合报告是周期性的 XML 汇总，失败报告是逐封的即时反馈。

对齐模式由 adkim 与 aspf 控制，默认都是 r，即宽松模式。宽松模式只比较组织域，news.example.com 与 mail.example.com 视为同一域；严格模式 s 则要求完全相同。

在 DMARC 的语境里，SPF 只有 pass 算通过，softfail、neutral、none 都按未通过处理。DKIM 则同时看签名是否验证成功、签名域与 From 域是否对齐。

聚合报告是每日一份的 XML，通常经 gzip 压缩后投递，邮件主题里带着上报域与统计区间。rua 指向别的域时，对端要先发布 policy-domain._report._dmarc.destination-host 的 TXT 授权。缺了这条授权，接收方会忽略该地址。

第六步常被跳过。没有 rua 就没有反馈渠道，只能等用户投诉，或者等退信堆在日志里。

自己动手的五步

配置顺序建议从观察开始，先看清谁在代发，再收紧策略。

盘点时按渠道过一遍，漏掉一个，切到拒收之后那一路的信就进不来。

• 网站表单与评论通知，常由主机上的 sendmail 或 PHP mail 直接发出。
• CRM、营销平台与工单系统，通常走服务商的中继地址。
• 监控、备份、打印机与 NAS 的告警邮件，来源最容易被忘。
• 事务性邮件接口，例如注册验证与密码重置。

1. 查现状。用 dig +short TXT example.com 看 SPF，把域名换成 _dmarc.example.com 与选择器名，分别看 DMARC 与 DKIM。再发一封测试信，从收件方返回的 Authentication-Results 头确认三项结果。
2. 收敛 SPF。把多个服务商的授权收进一条 include 链，保留 ip4 与 ip6 直连地址，结尾用 -all 或 ~all。每加一个 include 都要数一遍查询次数，别等 permerror 出现才发现。
3. 生成并发布 DKIM。用 2048 位 RSA 生成密钥对，私钥交给发信系统，公钥发到 DNS。选择器带上日期，例如 mail2026，便于日后轮换。
4. 从观察切到执行。先发 p=none 加 rua，跑两周报告，确认每一行来源都能解释。再改 quarantine，稳定一段时间后改 reject；需要灰度时用 t=y，让接收方按低一档的策略执行。
5. 建立例行检查。定期确认三处记录还在、公私钥仍配对、报告还有回传。证书、域名或邮件服务商变更时，把这三项一起复核。

DNS 里加 TXT 记录与证书验证的 dns-01 挑战是一套动作，记录放置、传播时间与验证顺序相通。站内ACME 证书自动化那篇写过同类细节。域名解析的基础操作可以看宝塔面板建站指南里的解析一节。

2026 年的新规范改了什么

三份新文档在 2026 年 5 月 20 日发布，DMARC 首次进入 Standards Track，同时废弃 RFC 7489 与 RFC 9091。

• pct 标签被移除。按百分比逐步放量的做法不再有效，灰度改用 t=y，接收方会按比声明低一档的策略执行。
• 新增 np，用于给不存在的子域单独设策略；新增 psd，用于公共后缀域。
• 组织域的判定从公共后缀列表改为 DNS Tree Walk，减少不同接收方对同一域名得出不同结论的情况。
• DMARC 里的 SPF 只看 MAIL FROM，不再回退到 HELO 身份。
• 报告内容拆成 RFC 9990 与 RFC 9991。失败报告可能包含完整头与正文，个人信息风险要提前评估。

现有的 v=DMARC1 记录继续有效，不必急着重发。但下次改 DNS 时，应把 pct、rf、ri 一并清掉，避免留下已经不起作用的字段。

五个常见误区

• 配了 SPF 就不会被冒充。SPF 只看信封发件人，对 From 头没有约束；邮件转发也会让合法信件对不上 IP。
• DKIM 通过就代表身份可信。签名只证明某个域签过这段内容，d= 可以是任何域名。没有对齐，签了也不进 DMARC。
• 记录发得越多越保险。同一名字下出现多条 DMARC 记录，接收方会放弃判定；多条 SPF 则直接 permerror。
• 直接上 p=reject。网站表单、CRM、打印机、第三方群发都可能漏掉。没看过 rua 报告就拒收，等于把自己的业务信打掉。
• 改完 DNS 立刻生效。TTL 与缓存会让旧记录继续存活一段时间，报告又常按天汇总。往别的域收报告，还要对端发布授权记录。

还有一个高频细节：选择器命名。轮换时让新旧公钥并存一段时间，确认新签名的信都能通过，再撤掉旧记录。用旧选择器配新密钥，会让失败原因难以区分。

需要这套配置的场景很明确：自建邮局、用第三方平台群发、品牌域名被拿去发钓鱼信，或者群发量大到要满足邮箱服务商的准入要求。

上手顺序是先用一天盘点所有发信源，再合并 SPF、发布 DKIM，然后从 p=none 观察两周。确认报告里每一行都能解释，再依次切到 quarantine 与 reject。想理解另一类同样把信任锚放在域名上的认证，可以对照站内Passkey 的作用域机制。

相关地址

以下为本文引用的规范与公告页面，标签定义、字段取舍与过渡建议以这些页面为准。

• RFC 9989（DMARC 核心协议）：https://www.rfc-editor.org/rfc/rfc9989.html
• RFC 9990（DMARC 聚合报告）：https://www.rfc-editor.org/rfc/rfc9990.html
• RFC 9991（DMARC 失败报告）：https://www.rfc-editor.org/rfc/rfc9991.html
• RFC 7208（SPF 规范）：https://www.rfc-editor.org/rfc/rfc7208.html
• RFC 6376（DKIM 签名）：https://www.rfc-editor.org/rfc/rfc6376.html
• RFC 8301（DKIM 算法与密钥更新）：https://www.rfc-editor.org/rfc/rfc8301.html
• dmarc.org（新版规范发布公告）：https://dmarc.org/2026/05/ietf-publishes-updated-dmarc-specification/