邮箱安全入门：SPF / DKIM / DMARC 是什么（2026）
一句话结论：SPF 查发信服务器是否在名单上，DKIM 验邮件签名是否完好，DMARC 把前两者的结果与发件人域名对齐并决定处置；三者都靠 DNS 记录发布，收紧要按 none、quarantine、reject 的顺序来。
三者分工：各查一件事
发件人域名在 DNS 发布三类记录，收信方按记录检查。SPF 回答“这台服务器有没有资格替这个域名发信”，DKIM 回答“邮件是否发信方签过且未被改过”，DMARC 回答“结果与发件人域名是否一致，不一致时怎么处置”。DMARC 本身不认证，建立在 SPF 与 DKIM 的结果之上。
| 机制 | 查什么 | 记录位置 |
|---|---|---|
| SPF | 发信服务器的 IP 是否在授权名单上 | 域名根部的 TXT 记录，只能有一条 |
| DKIM | 签名能否验过、内容是否被改过 | 选择器加 _domainkey 子域的 TXT 记录 |
| DMARC | SPF/DKIM 是否通过且对齐；失败时如何处置 | _dmarc 子域的 TXT 记录 |
SPF：发信服务器名单，查的是信封发件人
SPF 是一条 TXT 记录，列出哪些服务器可以替这个域名发信，收信方比对发信服务器 IP 与名单。查的是信封发件人（SMTP 的 MAIL FROM，即退信地址），不是收件人看到的发件人地址，两者可以不同，这正是 DMARC 要补的缺口。语法示例（须按自家发信服务填写，不可照抄）：v=spf1 include:_spf.google.com ~all，意思是授权 Google 发信、其余按软失败处理，只适用于仅用 Google Workspace 发信的情形。记录以 v=spf1 开头，~all 表示软失败，-all 表示硬失败。一个域名只能有一条 SPF 记录，多条会让邮件服务无法正常工作；有其他服务时，把授权合并进同一条。
SPF 有一条硬上限：按 RFC 7208 第 4.6.4 节，单次检查中触发 DNS 查询的项最多 10 次，超过就返回永久错误（PermError），收信方按失败处理。计入上限的是 include、a、mx、ptr、exists 与 redirect，每项计 1 次，嵌套查询也计入；不计入的是 ip4、ip6 与 all。每加一个发信服务，先数查询次数再发布。Google 帮助页称最多 10 个 include 标签，协议原文算的是查询次数（含嵌套），以协议原文为准。
DKIM：签名验真伪，选择器定位公钥
DKIM 用一对密钥工作：私钥保存在发信服务器上，给每封发出的邮件加签名；公钥发布在 DNS 的 TXT 记录里，收信方取公钥验证。签名覆盖邮件头与正文摘要，验证通过说明确由持私钥一方发出且未被改过；改动签名覆盖的内容，验证就失败。选择器（selector）用来定位公钥：多把密钥各对应一个选择器，公钥记录挂在“选择器._domainkey”子域下。Google Workspace 的默认选择器是 google，记录形如 google._domainkey；Cloudflare 转发服务的选择器以 cf2024-1 开头（复用域名邮箱实操文章口径）。收信方从 DKIM-Signature 头读出选择器与签名域名（d= 标签），再取公钥验证；换密钥用新选择器发新公钥，旧记录保留一段时间再删。DKIM 只证明签名有效，域名关系留给 DMARC 对齐检查。
DMARC：对齐与处置，收紧要按顺序
DMARC 记录挂在 _dmarc 子域，以 v=DMARC1 开头，p 标签写策略。Google 帮助页（核查 2026-11-13）定义三档策略：none 只观察，不改变投递，把结果记入每日报告；quarantine 把未通过的邮件标记为垃圾邮件，送入垃圾文件夹；reject 拒收邮件，收信服务器通常会向发信服务器发退信通知。策略是建议，最终处置由收信方决定。
| 策略 | 未通过时的处置 | 在收紧顺序里的位置 |
|---|---|---|
| p=none | 照常投递，只记录并报告 | 起点：先观察 |
| p=quarantine | 送入垃圾文件夹 | 中间：确认通过后再收紧 |
| p=reject | 拒收 | 终点：隔离跑干净后再收紧 |
DMARC 通过的条件：SPF 通过且对齐，或 DKIM 通过且对齐，通一条即可。对齐指认证域名与发件人域名相符：SPF 对齐比较信封发件人域名，DKIM 对齐比较签名域名（d= 标签）。aspf 与 adkim 两个标签分别控制对齐模式，默认都是宽松模式：子域名与组织域名相符即可通过；严格模式要求完全相同。收紧顺序复用域名邮箱实操文章口径：先用 p=none 观察报告几周，确认 SPF 与 DKIM 都已对齐，再收紧到隔离、拒绝；Google 帮助页建议一致，并要求 SPF 与 DKIM 至少运行 48 小时后再启用 DMARC。pct 标签控制策略适用的未通过邮件比例，从小比例起步、逐步提高到 100，取值 1 至 100 的整数，不写则适用于全部邮件。rua 标签写报告接收邮箱，报告量大，Google 建议用专门的邮箱或群组接收。v 与 p 两个标签须排在最前面。
转发为什么会破认证，ARC 一笔带过
转发会破坏认证：转发服务器再次发出邮件，收信方看到的发信服务器变了，SPF 可能失败；转发方改动内容，DKIM 也可能失效；两项都失败，DMARC 也失败。ARC（Authenticated Received Chain，RFC 8617，实验性规范）的做法是，各中间方把当时看到的认证结果签名封存，收信方据此判断邮件进入转发链之前是否通过认证；ARC 不修复签名，也不替代 DMARC，是否采信由各家自定。转发处理细节见域名邮箱实操文章。
Gmail 代发与对齐：先看时效注记
用 Gmail 代发域名地址时，发件人域名与实际发信服务不一致，对齐按代发服务配置走，否则 DMARC 可能失败。时效注记：Google 已公告，2027 年 1 月起 Gmail 不再支持第三方邮箱地址的代发，Workspace 别名与本人拥有的其他 Gmail 地址不受影响；2026 年第三至第四季度为过渡期，可能限制新配置。域名地址按官方文字理解属于第三方地址，同样在终止范围内，不要把长期发信押在这条路上。发信方案见域名邮箱实操文章与Gmail 海外使用文章。
如何自查：只用 DNS 记录与邮件头
站内规则只推荐实测过的工具，本文不推荐任何检测工具。第一步，查 DNS：域名根部是否只有一条 SPF 记录，_dmarc 子域的 DMARC 记录是否存在、p 值是什么，DKIM 选择器子域的记录是否存在、名称是否与发信服务给出的一致；缺失或写错先补记录，再等 DNS 传播，DKIM 校验最长等待 48 小时，期间不要反复改记录。第二步，看验证结果：给自己发测试信，在收信邮箱里打开邮件原文，看 Authentication-Results 头的 spf、dkim、dmarc 三项；全通过仍进垃圾文件夹时，问题在域名信誉或内容上。第三步，读汇总报告：rua 邮箱的报告列出各发信来源与认证结果，核对合法来源是否对齐，收紧前先修好未对齐的来源。
局限与未核实清单
本文未实测，核查日期 2026-11-13，各服务商可能随时调整。未能核实：各收信方的实际处置细节；各发信服务商的具体记录值，须按自家文档填写；ARC 在各收信方的采信程度；DMARC 新版规范的实施进度，各来源说法不一，本篇按 RFC 7489 口径写；Gmail 代发在自定义域名地址上的完整表现。配置前以官方文档为准，先用非关键地址测试。
2026-11-13：首发
相关：邮箱与电话号码 · 域名邮箱实操 · Gmail 海外使用 · 海外邮箱对比 · 方法论