SPF、DKIM 和 DMARC 检查器

配置

查看一个域名如何保护其邮件：包含所有 include 和 DNS 查询次数的 SPF 记录、DKIM 密钥及其长度、DMARC 策略、MX 服务器，以及 MTA-STS、TLS-RPT 和 BIMI 记录。每项发现都附有说明，让你知道该修复什么。

此工具在服务器上运行

工作原理

邮件协议并不验证发件人：任何服务器都可以把你的域名写成发件人。三条 DNS 记录能堵住这个漏洞。SPF 列出哪些服务器可以代表该域名发信。DKIM 用私钥为每封邮件签名，其公钥发布在 DNS 中。DMARC 把两者结合起来：要求至少一项通过并与可见的发件人域名一致，告诉收件方如何处理未通过的邮件，并要求提交所有以你名义发送的邮件的报告。

自 2024 年 2 月起，Gmail 和 Yahoo 要求每天向其用户发送超过 5000 封邮件的发件人必须配置 SPF、DKIM 和 DMARC，缺少任何一项都会导致邮件被拒或进入垃圾箱。因此最好三者一起检查：没有 DMARC，再完美的 SPF 也作用有限；而 DKIM 发布有误时把 DMARC 设为 reject，会把你自己的邮件也挡在门外。

检查从我们的服务器通过公共 DNS 查询完成，与任何邮件服务器的做法相同。SPF 会被完整评估，逐一跟随每个 include 和 redirect 来统计 DNS 查询次数，因为超过 10 次的上限会使整条记录失效。此外还会查询 MX 记录以及可选的 MTA-STS、TLS-RPT 和 BIMI 记录。

示例

github.comSPF · 10 / 10八个服务商的 include（Microsoft、Google、Zendesk、Salesforce、Mailchimp、SendGrid…）及其再次 include 的记录，使评估正好达到 10 次 DNS 查询的上限。再加一个服务商，整个 SPF 就会返回永久错误。

example.comMX 0 . · v=spf1 -all · v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s适用于既不发信也不收信的域名的正确配置：空 MX、不授权任何人的 SPF，以及设为 reject 的 DMARC。它能保护常被冒用的停放域名。

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.comquarantine · 25 %逐步部署：未通过的邮件中只有四分之一会进入垃圾箱，报告会发送到 rua 指定的邮箱，便于发现尚未完成认证的合法发件方。

使用场景

诊断该域名的邮件为何进入垃圾箱或被 Gmail、Outlook、Yahoo 拒收。
在添加新的发信服务商（如 CRM 或邮件营销平台）之前，确认 SPF 不会超过 10 次 DNS 查询。
配置完成后，确认服务商的 DKIM 密钥已正确发布。
规划在不阻断合法邮件的前提下，把 DMARC 从 none 逐步切换到 quarantine 和 reject。
审计客户或被收购公司的域名，包括不应发信的停放域名。
分析网络钓鱼时，检查可疑发件人的配置。

常见问题

我的域名明明对邮件签名了，为什么显示找不到 DKIM？

因为 DKIM 无法列出一个域名的所有密钥：每个密钥位于 <selector>._domainkey.<domain>，必须知道选择器才能查询。本工具会尝试最常用的选择器，但许多服务商使用自定义名称或带日期的名称。打开一封从该域名发出的邮件，找到 DKIM-Signature 头并复制 s= 的值；用这个选择器检查就会准确无误。

如果 SPF 超过 10 次 DNS 查询会怎样？

RFC 7208 要求收件方返回永久错误（permerror），对 DMARC 而言这等同于 SPF 失败。消耗查询次数的是 include、a、mx、ptr、exists 机制和 redirect 修饰符，包括每个 include 内部的这些项；ip4 和 ip6 不消耗。要减少次数，可以删除不再使用的服务商、用 ip4 网段替换 include，或改从拥有独立 SPF 的子域名发信。

用 ~all 还是 -all？

启用 DMARC 后差别不大：收件方执行的是 DMARC 策略，而不是 SPF 限定符。~all 更常见，因为有些收件方看到 -all 会在评估 DKIM 之前直接拒收，可能导致本可由 DKIM 挽救的转发邮件丢失。没有 DMARC 时，-all 是要求拒收未授权邮件的唯一方式。

如何在不丢失邮件的情况下把 DMARC 从 none 改为 reject？

先设置 p=none 并在 rua 中填写地址，阅读几周的汇总报告：报告会列出所有用你的域名发信的服务器，以及它们是否通过 SPF 或 DKIM。为缺失的合法发件方完成认证，再以较低的 pct 切换到 quarantine，逐步提高 pct，最后改为 reject。直接跳到 reject 往往会把计费系统、CRM 或没人记得的内部系统挡在外面。

1024 位的 DKIM 密钥够用吗？

可以用，因为 RFC 8301 要求收件方接受 1024 到 4096 位的密钥，但同一标准建议签名方至少使用 2048 位。低于 1024 位的密钥被视为无效。换成 2048 位很简单：用另一个选择器发布新密钥，切换签名，然后把旧密钥的 p 留空以吊销它。

MTA-STS、TLS-RPT 和 BIMI 有什么用？

MTA-STS（RFC 8461）要求发信服务器在投递到你的 MX 时必须使用 TLS，从而防止把连接降级为明文的攻击。TLS-RPT（RFC 8460）会在这些投递失败时向你发送报告。BIMI 会在支持它的客户端中于发件人旁显示品牌标志，且仅在 DMARC 为 quarantine 或 reject 时有效。三者都不是必需的，但都有好处。