Defaults.Exposed › 修复 › Guides
DMARC 失败但 SPF 和 DKIM 都通过？对齐修复指南（2026）
发布于 2026-07-08
数据截至 2026-06-29 · 方法论 v7。 基于 261 百万个已评分域名的汇总普查数据。参见我们如何评分。
DMARC 要的不只是”通过”——通过 SPF 或 DKIM 的那个域名必须与你的 From 域名匹配。大多数 “SPF 通过、DMARC 失败” 的邮件，是在供应商的退信域名上通过了 SPF，不是在你的域名上。根据 Defaults.Exposed 普查（2026-06-29），在 261,086,232 个已评分域名中，只有 7.4% 在强制执行的 DMARC 策略下以对齐方式通过 SPF。
修复比这团困惑看上去要快。读一读 Authentication-Results 标头，看是哪条腿——SPF 还是 DKIM——在错误的域名上通过；然后要么开启发送服务的自定义域名 DKIM 签名（通常就是几条 CNAME，而且是能挺过转发的修复），要么设置它的自定义回信路径让 SPF 在你的域名上通过。DMARC 只需要一条对齐的腿。
SPF 和 DKIM 都通过，DMARC 怎么还会失败？
因为 DMARC 从来不问”SPF 通过了吗？“它问的是：SPF 或 DKIM 是否为一个与收件人看到的 From 地址匹配的域名通过了？这个附加条件叫对齐，也是 DMARC 的全部意义——没有它，任何人都可以在自己拥有的域名上通过 SPF，同时在 From 标头里显示你的域名。
每项检查认证的是不同的域名：
| 检查 | 它实际评估的域名 | 在哪里看 |
|---|---|---|
| SPF | Return-Path（RFC5321.MailFrom，即退信/信封发件地址）——不是 From 标头 | Authentication-Results 里的 smtp.mailfrom= |
| DKIM | 签名 d= 标签里的域名——签名方选什么就是什么 | Authentication-Results 里的 header.d= |
| DMARC | 你 From 标头里的域名——并且要求 SPF 的域名或 DKIM 的 d= 与之匹配 | Authentication-Results 里的 header.from= |
各个环节通常是这样出错的：你的邮件通讯平台或 CRM 用类似 [email protected] 的 Return-Path 发信，SPF 是对 vendor.com 检查的且通过了，DKIM 以 d=vendor.com 通过了——而 DMARC 失败，因为两个通过的域名都不匹配 yourcompany.com。每项检查都说了实话；但没有一项认证的是你。改你自己的 SPF 记录救不了这个——它根本没被查询过。这和 SaaS 工具的 SPF 失败里讲的是同一个陷阱。
普查数据显示走完这最后一步的发件方有多稀少：261,086,232 个已评分域名中只有 27,640,987 个（10.59%）有强制执行的 DMARC 策略，而在强制策略下以对齐方式通过 SPF 的只有 7.4%。在 SPF 以软失败（~all）结尾的 77.5 百万个域名中，只有 9.2% 处于强制执行的 DMARC 策略之下；在硬失败（-all）发布者中，12,142,351 个被强制执行，42,514,532 个没有。大多数域名止步于 “SPF 通过”——而没有 DMARC 落实它，这几乎保护不了什么。
如何读 Authentication-Results，看出哪条腿没对齐？
通过出问题的服务给自己发一封邮件，打开原始源码，找到 Authentication-Results 标头。典型的未对齐结果长这样：
Authentication-Results: mx.google.com;
spf=pass smtp.mailfrom=bounces.espmail.net;
dkim=pass header.d=espmail.net;
dmarc=fail (p=NONE) header.from=yourcompany.com
按三个对比来读：
- SPF 腿：
smtp.mailfrom=以你的域名结尾吗？这里是bounces.espmail.net——未对齐。 - DKIM 腿：
header.d=以你的域名结尾吗？这里是espmail.net——未对齐。 - DMARC 判定：
header.from=是 DMARC 在守护的域名。两条腿都没匹配上它，所以dmarc=fail——尽管两项单独检查都写着pass。
哪条腿已经涉及你自己的域名（或能被改成涉及），就修哪条。你只需要一条。
宽松对齐和严格对齐有什么区别？
DMARC 提供两种匹配模式，由 DMARC 记录里的 aspf（SPF）和 adkim（DKIM）标签设置：
- 宽松（
r，默认值）：两个域名只需共享同一个组织域名——按公共后缀列表（Public Suffix List）判定的可注册域名。bounce.yourcompany.com与yourcompany.com对齐；DKIM 的d=mail.yourcompany.com也一样。这正是供应商的自定义回信路径和自定义 DKIM（都放在子域名上）能起作用的原因。 - **严格（
s）：**两个域名必须逐字符完全一致。bounce.yourcompany.com就不再与yourcompany.com对齐了。
如果你的记录没提到 aspf 或 adkim，你就处于宽松模式——而且你几乎肯定应该留在那里。对大多数发件方而言，严格模式不带来任何有意义的安全增益，却会悄无声息地弄坏你设置的每一个合法子域名发送源。如果 DMARC 在失败而你的记录里有 aspf=s 或 adkim=s，光这一点就可能是病根。
DMARC 对齐怎么修？
- 动 DNS 之前，先在 defaults.exposed 运行免费扫描。 它会显示你的 DMARC 记录和策略、你的 SPF 和 DKIM 是否配置成可对齐，以及还有什么坏掉了——这样你先修对的那条腿。
- 测试每个发送服务并读取它的 Authentication-Results（如上）。列出所有来源——邮箱服务商、邮件通讯工具、CRM、开票应用——并逐个记下
smtp.mailfrom和header.d是你的域名还是供应商的。 - 给每个供应商启用自定义域名 DKIM 签名——能长久的修复。 每个正经的发送服务都提供”域名认证”：几条 CNAME 记录，让它以
d=yourcompany.com（或某个子域名，在宽松模式下同样对齐）签名。对齐的 DKIM 通常是更容易的修复，也是唯一能挺过转发的修复，因为转发从设计上就会弄坏 SPF。 - 要对齐 SPF，就启用供应商的自定义回信路径（常叫自定义退信域名）——通常是一条 CNAME，比如
bounce.yourcompany.com指向供应商。这样 SPF 就在你的组织域名上通过并对齐。有这个功能就做，但把它当第二条腿，不是对齐 DKIM 的替代品。 - 让对齐保持宽松模式，除非你有明确且理解透彻的理由需要
aspf=s/adkim=s。 - 重新扫描确认两条腿，然后走向强制执行。
p=none的 DMARC 策略只报告、不拦截；等你的真实发送源都对齐之后，通往一条真正保护你的策略的完整路径在修复 DMARC 页面，而 IONOS 上的 DMARC 这类服务商教程涵盖了 DNS 面板里的具体点法。
我该修 SPF 对齐还是 DKIM 对齐？
每个发送来源需要一条对齐的腿。如果只能做一个，这个选择毫无悬念：
| 修复 | 涉及什么 | 能挺过转发吗？ |
|---|---|---|
| 对齐的 DKIM（自定义域名签名） | 在供应商”域名认证”面板里加几条 CNAME | 能——签名随邮件一起旅行 |
| 对齐的 SPF（自定义回信路径/退信域名） | 一条 CNAME，前提是供应商提供 | 不能——任何转发方的 IP 都会顶替供应商的 |
值得知道的特例：Google Workspace 和 Microsoft 365 会默认用它们自己的兜底域名（gappssmtp.com、onmicrosoft.com）给你的邮件做 DKIM 签名——于是 DKIM 显示 pass 而 DMARC 依然失败。这是整个问题最常见的具体形态，它有自己的专门指南：DKIM 通过但 DMARC 依然失败：默认签名陷阱。
常见问题
SPF 和 DKIM 都需要对齐 DMARC 才能通过吗？ 不需要——一条对齐的通过就足够。最佳实践是两条都对齐，这样转发弄坏 SPF 那条腿时，DKIM 那条腿仍然扛着 DMARC 的通过。在 2026-06-29 普查评分的 261,086,232 个域名中，只有 3.87% 完成了 SPF + DMARC + DKIM 的完整三件套。
我的 ESP 后台说 SPF 和 DKIM 已”验证”——为什么 DMARC 还是失败？ “已验证”通常意味着供应商自己的发送在供应商的域名上通过。除非你完成了他们的自定义域名步骤（DKIM CNAME、自定义回信路径），邮件认证的身份是供应商，不是你——而 DMARC 对比的是你的 From 域名。
不做对齐，一条严格的 -all SPF 记录够吗？
不够。严格限定符只是强化了 SPF 对 Return-Path 域名的判定，但 DMARC 仍然要求那个域名是你的。截至 2026-06-29 普查，发布 -all 的域名中只有 12,142,351 个处于强制执行的 DMARC 策略之下——另外 42,514,532 个的严格记录没有任何策略在落实。
为了更安全，我该切到严格对齐（aspf=s/adkim=s）吗？
几乎从来不该。宽松对齐已经要求同一个可注册域名，而冒充者控制不了它。严格模式主要的作用是弄坏你自己的子域名发送源——每当对齐莫名其妙地失败，就查一查它。
DMARC 只在收件人转发的邮件上失败——同样的修法吗？ 那是 SPF 那条腿在传输途中死掉了：转发方的服务器不在任何人为你的回信路径设置的 SPF 记录里。转发邮件的 SPF 修不了；答案是对齐的 DKIM，因为签名能完好无损地挺过转发。详见转发邮件 SPF 失败。
把报告发给负责人
如果你是在替客户或雇主修这个问题，用证据来收尾。CNAME 生效后重新运行免费扫描，把评分报告转发给企业负责人：有日期、说人话、显示 SPF、DKIM 和 DMARC 已对齐并通过。这正是网络保险续保和下一份供应商安全问卷需要的材料——一套有效配置的证明，而不只是”我加了几条 DNS 记录”。
检查你的域名 → · DKIM 通过但 DMARC 依然失败 → · 修复 DMARC → · 我们如何评分 → · 仅使用汇总数据。数据在欧盟境内存储和处理。