钓鱼邮件可能会在你不知情的情况下以你域名的名义发出。能阻止这件事的，正是 SPF / DKIM / DMARC。本文通俗讲解三者的作用与安全的配置步骤。
三者的作用
| 设置 | 作用（一句话） |
|---|---|
| SPF | 用 DNS 声明“允许发送本域名邮件的服务器就是这些” |
| DKIM | 给邮件加上电子签名，证明“传输途中未被篡改、来自正规发件源” |
| DMARC | 声明 SPF/DKIM 失败时如何处理的策略，并接收报告（把三者联系在一起的设置） |
三者都是 DNS 中的文本（TXT）记录。以 example.com 为例，大致如下（值为示例）。
| 设置 | 写在哪里 | 示例值 |
|---|---|---|
| SPF | example.com | v=spf1 include:_spf.mail-service.example ~all |
| DKIM | selector._domainkey.example.com | v=DKIM1; k=rsa; p=(由发信服务签发的公钥) |
| DMARC | _dmarc.example.com | v=DMARC1; p=none; rua=mailto:dmarc@example.com |
SPF 的 include: 请使用邮件发送服务指定的值。DKIM 的公钥同样由发信服务签发，不需要自己生成。
是如何被验证的（原理）
收件方（Gmail 等）会对收到的邮件检查 SPF 与 DKIM，再把结果对照 DMARC 的策略，决定“放行／隔离／拒绝”。
也就是说，仅有 SPF 和 DKIM 时往往是“做了判定却什么都不做”，只有配上 DMARC 的策略，“拦截冒充”的效力才会真正显现。
容易被忽视的一点：域名对齐
DMARC 判定的关键在于域名是否一致。只有当收件人在邮件软件中看到的发件人（From 头）的域名，与经 SPF 或 DKIM 验证的域名一致时，DMARC 才会通过。
SPF 检查的不是显示出来的发件人，而是投递时在幕后使用的信封发件人（envelope sender）的域名。因此，攻击者可以用自己的域名通过 SPF，同时只在 From 栏里写上你的域名。如果 SPF 通过但与 From 域名不一致，DKIM 也没有提供一致的域名，DMARC 就会判定该邮件失败。正是这种一致性检查，让 DMARC 能够阻止冒用 From 地址的冒充。
安全的配置步骤
SPF 只设一条且正确
把用于发信的正规服务器（自有、邮件投递服务等）无遗漏地全部许可。SPF 记录在一个域名上汇总为一条（多条容易失效）。
启用 DKIM 签名
在所使用的邮件发送平台上启用 DKIM，并把公钥登记到 DNS，使正规邮件带上签名。
DMARC 从 p=none 开始
不要一上来就拒绝。先用 p=none（仅监控）＋接收报告，确认正规邮件是否会被误拦。
逐步加严
通过报告补齐正规投递的遗漏后，再从 p=quarantine → p=reject。最终实现“冒充一律拒绝”。
第 1 步中的「只设一条」来自规范。RFC 7208 规定，一个域名如果有多条 SPF 记录，结果就是 permerror（永久错误）。同一规范还把 include 等引起的 DNS 查询在整个评估过程中限制为 10 次，超出同样是 permerror。添加邮件服务时，请追加到现有的那一条记录中，而不是再新增一条。
常见错误
| 错误 | 会发生什么 | 解决方法 |
|---|---|---|
| 有两条 SPF 记录 | SPF 返回 permerror | 合并为一条 |
嵌套的 include 太多 | DNS 查询超过 10 次 → permerror | 删除不再使用的服务的 include |
| 某个发信服务未启用 DKIM | 经该服务发出的邮件 DMARC 失败 | 在该服务中启用 DKIM 并发布到 DNS |
| DMARC 一直停在 p=none | 冒充邮件继续被投递 | 查看报告并提升到 reject |
| 不发邮件的域名什么都没配置 | 无法阻止冒用这个闲置域名的冒充 | 发布 v=spf1 -all 和 DMARC p=reject |
如何检查自己的域名
- 在 SPF / DKIM / DMARC 检查工具中输入你的域名，查看三条记录是否存在、有什么问题
- 如果想在命令行中直接查看，运行
dig +short TXT example.com（SPF）和dig +short TXT _dmarc.example.com（DMARC） - 从你的域名向 Gmail 地址发送一封邮件，在 Gmail 的「显示原始邮件」中确认
SPF、DKIM、DMARC都是PASS - DMARC 报告（rua）开始送达后，每周检查一次是否有不认识的发件方
对于已验证所有权的网站，网站安全诊断会把这些与 Web 端的设置一起检查。
真实案例：来自「自己地址」的冒充邮件
「收到了一封从自己的地址发给自己的威胁邮件」，是日本 IPA（信息处理推进机构）等机构提醒过的典型情况。这类邮件大多并不是账号被盗，只是发件人栏被改写了。由于发件人栏可以随意填写，对于尚未把 DMARC 提升到 reject 的域名，这类邮件可能会进入收件箱。如何判断以及如何应对，见以下文章：
- 自己的邮箱地址发出了垃圾邮件（五分钟内确认是否被盗号）
- 冒用自家域名的冒充邮件（读邮件头，并用 SPF、DKIM、DMARC 阻止）
规范更新（2026 年 5 月）
DMARC 于 2026 年 5 月修订为 RFC 9989，取代了之前的 RFC 7489。p=none、p=quarantine、p=reject 三种策略没有变化。变化之处在于：删除了 pct 标签（应用比例），改用表示测试模式的 t 标签；并新增了 np 标签，用于指定对不存在的子域名的策略。现有记录不会马上失效，但新写记录时不要再使用 pct。
本站视角：你守护的也是“你的用户”
SPF/DKIM/DMARC 不只是为了让自己的邮件能送达，更是一套保护“你的用户”免遭冒用你域名的钓鱼的机制。钓鱼说到底就是窃取认证凭据或密钥的手段。
现实中，许多域名只停留在 SPF/DKIM，并未把 DMARC 提升到强制(reject)。不要停在 p=none，要查看报告、逐步把策略一路加严到 reject，才能真正见效。
出处（一手资料）
- IETF RFC 7208, "Sender Policy Framework (SPF)" — datatracker.ietf.org（每个域名一条记录；DNS 查询最多 10 次）
- IETF RFC 6376, "DomainKeys Identified Mail (DKIM) Signatures" — datatracker.ietf.org
- IETF RFC 9989, "Domain-Based Message Authentication, Reporting, and Conformance (DMARC)" (May 2026; obsoletes RFC 7489) — datatracker.ietf.org
- Google, "Email sender guidelines" — support.google.com（2024 年 2 月 1 日起的要求；每天发送 5,000 封以上发件方的要求）
接下来阅读
- 怎么做：识别并阻止冒充邮件 / 自己的邮箱地址发出了垃圾邮件
- 术语：钓鱼是什么 / .env 是什么
- 工具：SPF / DKIM / DMARC 检查工具