Defaults.Exposed › 修复 › Guides
转发邮件 SPF 失败——为什么你修不好它，以及真正有效的办法（2026）
发布于 2026-07-08
数据截至 2026-06-29 · 方法论 v7。 基于 261 百万个已评分域名的汇总普查数据。参见我们如何评分。
转发邮件的 SPF 你没办法修好——转发在设计上就会破坏 SPF，诚实的解法是能扛住转发的对齐 DKIM。这是普查级别的规模问题：根据 Defaults.Exposed 对 261 百万个域名的普查，在 138,927,207 个发布 SPF 的域名中，有 7,355,985 个单靠 Namecheap 的转发 include 撑着，其中严格 SPF 的比例只有 <0.1%。
以下内容：为什么你写不出任何能扛住转发的 SPF 记录、为什么 SRS 和 ARC 不是你能掌控的工具，以及真正管用的修法——用你自己的域名做 DKIM 签名，作为你的 DMARC 通过项——外加唯一一种连 DKIM 也保不住的情况（会改写邮件的邮件列表）以及该怎么处理这部分残余问题。
为什么转发会破坏 SPF？
接收方是对照 Return-Path（RFC5321.MailFrom）域名，而不是 From 标头来检查 SPF 的。当你直接发信时，你服务器的 IP 在你的 SPF 记录里，检查通过。而当你的收件人把邮件自动转发出去——转到私人 Gmail、通过大学的邮箱别名、经由注册商的转发产品——是转发方的服务器在重新发送这封邮件，而它通常仍会把你的域名留在 Return-Path 上。最终接收方这时候问的是：这台转发服务器有没有被授权写进你的 SPF 记录？
它没有，而且永远不会有：转发方不是你选的，你根本不知道它的存在，同一封邮件明天经由另一个服务转发，又会从另一个 IP 那里失败。SPF 只回答一个问题——“这个 IP 是不是 Return-Path 域名授权过的服务器？”——对转发邮件而言，真实答案就是不是。这个失败是 SPF 按规范正常工作的结果，不是你的记录写错了。
普查数据显示这条路径有多主流：有 7,355,985 个域名授权了 Namecheap 的邮件转发 include（spf.efwd.registrar-servers.com）——这是单个服务商的转发产品，出自 139 百万个 SPF 发布者——其严格 SPF 比例只有 <0.1%，强制执行 DMARC 的比例更是只有 0.2%。这种软性模板不是粗心大意：转发恰恰就是严格的 -all 会误伤的地方，而这个产品本身就是转发的服务商，自然照此发货。完整的限定符故事见我们的 ~all 与 -all 报告，各服务商的对比全景见哪家邮件服务商的 SPF 最强。
我能不能干脆把转发方的服务器加进我的 SPF 记录？
不能——原因就是这整篇文章要讲的：
- 你没法穷举转发方。 任何地方的任何收件人，都可以把你的邮件经由任何服务转发出去。你的 SPF 记录得列出你事先根本不可能知道的服务器。
- 就算列出来也会背离初衷。 大型转发服务为数以百万计的客户中转邮件。把它们的 IP 段写进你的记录，它们任何一个用户中转的邮件——包括伪造者的——都会以你的名义通过 SPF。
同样的逻辑也排除了“把限定符放宽以让转发生效”这条路：限定符根本不是转发邮件失败的原因，而且一旦启用了 DMARC，它能改变的东西比大多数指南说的要少得多——见限定符数据。记录本身不是这里的杠杆。别再去拉它了。
SRS 和 ARC 呢——它们不是能修好转发吗？
它们确实在处理这个问题——但都不归你部署：
| 机制 | 邮件被转发时它做了什么 | 谁掌控它 | 修好了你的 DMARC 吗？ |
|---|---|---|---|
| SPF | 失败：转发方的 IP 不在你的记录里 | 你负责发布；转发让它失效 | 否 |
| SRS（发件人重写方案） | 转发方把 Return-Path 重写成自己的域名，这样它的重新发送能通过 SPF | 转发方 | 否——SPF 的通过归了转发方的域名，和你的 From 对不上 |
| ARC（RFC 8617） | 转发方对原始认证结果加封；最终接收方可能信任这条封存链 | 转发方和接收方 | 有时——由接收方自行决定，不由你决定 |
| 对齐的 DKIM | 签名随邮件一起传递，转发之后依然能验证通过，且带着你的域名 | 你 | 是 |
数据与机制状态截至 2026-06-29。
SRS 解决的是转发方自己的 SPF 问题，不是你的：重写 Return-Path 改变的是谁的 SPF 被检查，而你的 From 标头——DMARC 真正保护的域名——完全没被动过。ARC 是基础设施运营方之间的信任决策。如果哪篇指南让你作为域名所有者去“实施 SRS”，那它把你和转发服务商搞混了。
我怎么才能让邮件扛住转发？
让对齐到你域名的 DKIM，成为你的 DMARC 通过项。DKIM 签名是携带在邮件标头里的密码学证明：只要签名内容没被改动，不管邮件最终落到哪里、经过多少台服务器中转，它都能验证通过。DMARC 只需要一项对齐通过——SPF 或 DKIM——所以当转发让 SPF 这条腿失效时，对齐的 DKIM 依然能让邮件保持已认证状态。
- 动 DNS 之前，先在 defaults.exposed 运行免费扫描。 它会显示你有没有 DKIM、是否在用你自己的域名签名，以及你的 DMARC 现状——这样你修的是真正的缺口，而不是和你的 SPF 记录较劲。
- 确认转发确实是你的问题。 在受影响邮件的 Authentication-Results 标头里，直发邮件通过 SPF，转发的副本则会从转发服务的 IP 那里失败。如果 SPF 和 DKIM 都通过但 DMARC 依然失败，那你的问题其实是对齐——见 DMARC 失败但 SPF 和 DKIM 都通过。
- 为你自己的域名启用 DKIM 签名，在每个发信服务上都这样做——先是邮箱服务商，再是各个 ESP 和事务性发件服务。服务商默认往往用它自己的域名签名，这样对不上齐；你要的是
d=yourdomain。从如何修复 DKIM 开始，其中有 Google Workspace 和 Microsoft 365 的具体操作路径。 - 验证的是对齐，而不只是通过。 签名里的
d=域名必须和你的 From 域名一致；在别人域名上的dkim=pass对你的 DMARC 毫无帮助。 - 别去动你的 SPF 记录。 让它对你的直发邮件保持准确——它仍然能认证你大部分的流量，也仍然是你的第二条 DMARC 腿。只是别再想着让它覆盖转发方。
- 重新扫描，然后有计划地分阶段推进 DMARC 强制执行——见下一节，以及 p=none 到 p=reject 的上线指南。
这种组合——SPF 加上靠对齐 DKIM 撑起的强制执行 DMARC——才是扛得住转发的模式，而它很少见：在发布 ~all 的 77.5 百万个域名中，只有 9.2%（7,116,774 个） 用强制执行的 DMARC 策略撑起了它，而在 261 百万个已评分域名中，只有 3.87%（10,092,481 个） 完整具备 SPF + DKIM + 强制执行 DMARC 这三件套，数据来自普查（2026-06-29）。
会改写邮件的邮件列表呢？
有一种转发路径连对齐的 DKIM 也扛不住：会修改邮件内容的邮件列表——比如加个 [list-name] 的主题标签、加个退订页脚、剥离某个附件。签名内容一变，正文哈希就对不上了，DKIM 也随之失败（dkim=fail: body hash did not verify 有它自己的专门指南）。此时 DMARC 的两条腿都断了，只有邮件列表自己能缓解这个问题（From 重写、ARC 加封）。
这部分残余问题，正是分阶段 DMARC 强制执行存在的意义。带着 pct 逐步推进 p=quarantine、同时观察汇总报告，能让你看清楚有多少真实邮件流量是经由会改写内容的邮件列表——在 p=reject 策略开始把它们拒收之前看清楚。如果你的用户重度依赖邮件列表，不要直接跳到 reject；但也别永远停在 p=none。分阶段上线指南 讲的就是怎么逐步推进。
常见问题
转发也会破坏 DKIM 吗？ 普通转发不会：签名随邮件一起传递，在最终接收方那里依然能验证通过。DKIM 只有在签名内容在传输途中被改动时才会失败——邮件列表的主题标签和页脚就是典型情形——这也是为什么这部分邮件列表残余问题是靠 DMARC 策略分阶段来处理，而不是靠 DNS 里的任何设置。
我要不要把限定符从 -all 换成 ~all，好让转发不再失败？ 换限定符不会让转发方通过——限定符根本不是它们失败的原因。有意思的是，Namecheap 的转发 include——7,355,985 个域名，是普查中规模最大的专职转发人群（2026-06-29）——其严格 SPF 比例只有 <0.1%：对转发产品来说，软性 SPF 可以说才是正确的模板。限定符实际会改变什么，见~all 与 -all 报告。
为什么我直接发信时 SPF 通过，一旦被别人转发就失败了？ 接收方检查的是最后一台转发服务器的 IP有没有被你的 Return-Path 域名的 SPF 记录授权。直发：你的服务器，在你的记录里，通过。转发：转发方的服务器，不在你的记录里，失败。你的记录没变——变的是发信的 IP。
我能自己搭 SRS 来解决这个问题吗？ 只有当你就是转发方本身时才行。SRS 运行在执行转发的那台服务器上，就算它真的在运行，得到的那个 SPF 通过也归属于转发方的域名，和你的 From 对不上——你的 DMARC 仍然需要靠 DKIM 这条腿。
既然转发反正会破坏 SPF，那 SPF 是不是就没意义了？ 不是。大多数邮件都是直接送达的，在这种情况下 SPF 正如设计所愿地生效，它仍然是你 DMARC 的两条腿之一。在普查的 261,086,232 个域名中（2026-06-29），有 138,927,207 个发布了 SPF——通过 SPF 修复页面 让你的记录保持准确，剩下被转发的那部分交给 DKIM 来扛。
把报告发给老板
如果你是在替客户或雇主修这个问题，用证据收尾。等自定义域名 DKIM 上线、DMARC 也已分阶段推进后，重新运行免费扫描，把评分报告转发给企业负责人：带日期、用大白话写清楚，展示这个域名即便邮件被转发也依然保持认证状态。这正是网络保险续保和下一份供应商问卷需要的凭证——一份记录在案的前后对比，而不是一句“我打开了个什么开关”。
检查你的域名 → · DMARC 失败但 SPF 和 DKIM 都通过 → · 修复 DKIM → · 我们如何评分 → · 仅使用汇总数据。数据在欧盟境内存储和处理。