SPF 与 DMARC 检查：如何查询、读懂并修复你的记录

SPF、DKIM 和 DMARC 分别检查什么

SPF 和 DKIM 都可能针对读者根本看不到的域名通过验证。DMARC 通过对齐（alignment）弥补了这个缺口：只要 SPF 或 DKIM 在与 From 域名对齐的域名上通过，邮件即通过，一项对齐通过就足够。默认的宽松对齐只要求组织域名相同，因此 bounce.example.com 与 example.com 对齐。严格对齐则要求完全一致。

假设有一个新闻邮件服务，可以说明这一点的重要性。它以 news@example.com 的名义发信，却使用自己位于 example.net 的退信域名作为信封发件人。SPF 对 example.net 通过，但并不对齐，所以只有该服务以 d=example.com 进行 DKIM 签名，DMARC 才会通过。

如何用 dig 或 nslookup 查询记录

只需要 dig（Linux、macOS）或 nslookup（Windows）：

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short MX example.com
nslookup -type=TXT _dmarc.example.com

SPF 记录是以 v=spf1 开头的 TXT 记录；其他服务的验证令牌常常与它并排存在。DMARC 记录是 _dmarc 下以 v=DMARC1 开头的 TXT 记录。SPF 应在信封发件人域名上检查，它可能与 From 域名不同；已送达邮件的 Return-Path 头可以显示它。

DKIM 密钥无法从外部列出，因为每个密钥都位于某个选择器之下。请在你发送的邮件的 DKIM-Signature 头中读取 s= 和 d= 的值，再查询对应名称，例如 dig +short TXT s1._domainkey.example.com。

修改之后，解析器在 TTL 到期前可能仍返回旧结果。要查看当前实际发布的内容，请用 dig +short NS example.com 找到权威服务器，并直接向其查询：dig +short TXT example.com @ns1.example.net。然后向你自己控制的邮箱发送一封真实邮件，查看其 Authentication-Results 头。它显示接收方对 SPF、DKIM 和 DMARC 的判定，而这才是真正算数的结果。

如何读懂 SPF 记录

v=spf1 ip4:192.0.2.10 include:_spf.mail.example.net -all

机制从左到右依次评估，第一个匹配的机制决定结果。每个机制可以带一个限定符：+ 通过（默认）、- 失败、~ 软失败、? 中性。

~all 还是 -all

~all 表示未列出的服务器很可能未获授权，接收方不应仅凭此拒收。-all 表示它们未获授权；之后如何处理取决于接收方自己的策略。两者都合理，德国 BSI 也接受任一种。RFC 9989 补充了一点提醒：使用 -all 时，在 SMTP 会话早期就检查 SPF 的接收方，可能拒收本来能凭对齐 DKIM 通过的邮件（典型的是转发邮件），而这种拒收不会出现在 DMARC 报告中。?all 或完全没有 all，对未列出的服务器不作任何表态。+all 会让互联网上任何 IP 地址都通过，切勿发布。

10 次查询上限

接收方最多评估 10 个会触发 DNS 查询的项，被包含记录内部的项也计算在内（第 4.6.4 节）。超过后结果为 permerror，SPF 就无法再帮助邮件通过 DMARC。另有一个单独的上限针对没有返回答案的查询：超过两次这样的查询也应以 permerror 告终。记录里看起来只有四项，也可能因为被包含的记录里还有自己的 include 而超限，所以要递归计数。要降到上限以下，可以删除不再使用的服务，对你控制的地址改写为 ip4/ip6，并把大批量服务迁到各自的退信子域名，使用独立的 SPF 记录。把服务商的 IP 范围复制进你的记录（即“展平”）会在服务商变更地址后过期。

每个名称只能有一条记录

同一名称上有两条以 v=spf1 开头的 TXT 记录会产生 permerror，请合并。超过 255 个字符的记录要写成单条 TXT 记录中的多个带引号字符串，接收方会不加空格地将它们拼接。SPF 也不会继承：example.com 上的记录并不覆盖 mail.example.com，所以每个用作信封发件人的名称都需要自己的记录。

如何读懂 DMARC 记录

DMARC 现已成为 RFC 9989（2026 年 5 月），是取代 RFC 7489 的标准轨道规范。记录仍位于 _dmarc，并以 v=DMARC1 开头：

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

example.com 上的记录也覆盖没有自己记录的子域名；接收方通过 RFC 9989 所称的 DNS 树遍历（DNS Tree Walk）找到它。发送聚合报告的接收方会以 XML 文件的形式提交，通常每天一次，列出以你的域名发信的 IP 地址及其结果。如果 rua 指向另一个组织域名（例如报告服务），该域名必须发布一条以 v=DMARC1 开头、名称形如 example.com._report._dmarc.reports.example.net 的 TXT 记录（RFC 9990，第 4 节），否则接收方会忽略该地址。

从 none 到 reject

1. 列出所有以该域名发信的服务：邮箱平台、新闻邮件、CRM、账单、客服系统、网站表单。
2. 发布带 rua 的 p=none，并阅读报告。
3. 逐一修复合法来源，直到它们在对齐的情况下通过，优先采用 DKIM，因为 DKIM 通常在转发后依然有效，而 SPF 不能。
4. 升级到 quarantine，可先配合 t=y，然后再考虑 reject。

RFC 9989 指出，用户会向邮件列表发信的域名 SHOULD NOT 发布 reject；仍想使用的域名应先在 none 阶段至少停留一个月，再在 quarantine 阶段停留同样长的时间，并比较结果。任何发布 reject 的域名都 MUST 用 DKIM 为邮件签名。德国 BSI TR-03182 的立场更严格：发信域名 SHOULD 要求 reject。只用于发票和通知的域名，与员工用来参与邮件列表的域名是不同情形。RFC 9989 还要求接收方不要仅凭 p=reject 就拒收，但也承认在实践中，From 行未改动的列表邮件经常被拒收。

不发信的域名

停放域名、防拼写错误域名和仅用于跳转的域名，仍可能出现在伪造的 From 行中。RFC 7208 把为不发信域名设置 SPF 记录称为成熟的最佳实践。以下是一个假设的停放域名的完整记录集：

example.net.         TXT  "v=spf1 -all"
_dmarc.example.net.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"
example.net.         MX   0 .

该 SPF 记录不授权任何人，而 p=reject 在这里没有代价，因为不存在会被误伤的合法邮件。RFC 7505 中的空 MX 表示该域名不接收邮件，因此报告发送到 example.com，后者必须发布 example.net._report._dmarc.example.com。BSI TR-03182 将这一组合列为未使用域名的 MUST 要求。DMARC 策略覆盖子域名，但 SPF 不覆盖，所以任何有自己 A 或 MX 记录的子域名也应设置 v=spf1 -all。

Gmail、Yahoo 和 Outlook.com 对发件人的要求

自 2025 年 11 月起，Gmail 一直在加强执行力度，包括拒收邮件。Google 的规则针对个人 Gmail 账户，不包括 Google Workspace 收件人。Google 和 Yahoo 要求 DKIM 密钥至少 1024 位。Microsoft 会以 550 5.7.515 拒收不符合要求的邮件。三家都接受 p=none，它满足规则，但对伪造邮件没有表达任何处理倾向；请把它当作一个阶段，而不是最终配置。

MTA-STS 和 CAA：另外两条需要检查的记录

MTA-STS（RFC 8461）保护收件：它告诉发件方，除非你的 MX 主机提供带受信任证书的 TLS，否则不要投递。它需要在 _mta-sts.example.com 上有一条 TXT 记录，例如 v=STSv1; id=20261001000000Z;，以及位于 https://mta-sts.example.com/.well-known/mta-sts.txt 的策略文件，其中列出模式、MX 名称和 max_age。先从 testing 模式开始，此时发件方仍会投递，并在 _smtp._tls.example.com 配置了 TLS 报告时上报失败，然后再切换到 enforce。每次策略变更时都要更改 id。

CAA（RFC 8659）指明哪些证书颁发机构可以为该域名签发 TLS 证书，例如 CAA 0 issue "ca.example.net"。公共 CA 在签发前必须检查它；它无法阻止已获授权的 CA 错误签发，浏览器也不使用它。example.com 上的记录覆盖没有自己记录的子域名。请列出你使用的所有 CA，包括 CDN 所用的，否则续期可能失败。TLS 与安全响应头指南对证书有更详细的介绍。

常见的 SPF 和 DMARC 错误及修复方法

免费上线准备快照会检查你的邮件 DNS 哪些方面

免费的上线准备快照无需注册，对一个公开源站运行八项被动检查。它不是渗透测试，也不是六个领域的审计。八项检查中有一项读取邮件 DNS 记录：

• 确切主机名。MX、TXT、_dmarc、_mta-sts 和 CAA 都在你输入的主机名上查询，不会回退到父域名。www.example.com 上缺少记录，并不意味着 example.com 没有保护。若要读取邮件域名的记录，请直接输入该域名本身（输入 example.com 而不是 www.example.com）；它需要能解析到一个地址，快照才能给出评分。
• SPF。只有主机存在 MX 记录时，缺少记录才会被标记（中等）。+all 被标记为高风险，?all 为低风险；~all 和 -all 不产生任何提示。超过十个会触发 DNS 查询的项会被标记（中等），但只统计顶层记录中的项，因为不会跟进 include:。
• DMARC。只有主机存在 MX 记录时，缺少记录才会被标记（中等）。p=none 被标记为监控模式（低），quarantine 或 reject 视为通过。sp、pct、rua 和对齐不在评估范围内。
• MTA-STS 和 CAA。只有主机存在 MX 记录时，缺少 _mta-sts TXT 记录才会被标记（低）；不会获取策略文件。任何 CAA 记录都视为通过，没有则是低级别信号；其内容不会与你的证书比对。
• 不检查：DKIM、TLS 报告和 DNSSEC。

你会得到一个评分和等级、一个加固等级、风险信号和通过检查的数量、最多三条按严重程度排序的信号，以及每一项检查（包括每个邮件 DNS 行）及其评级。无法解析到地址的名称没有评分。网站上线检查清单逐一讲解全部八项检查，DNS 与邮件安全指南则介绍持续审查。

如果想先看这项检查，可以使用免费的 SPF 和 DMARC 检测工具：它运行同一份快照，并把邮件 DNS 检查展开显示在其余七项检查之前。