Defaults.Exposed › 报告
SPF 错误配置报告：多数 SPF 记录设置得过于宽松（2026）
发布于 2026-06-29
数据截至 2026-06-29 · 方法论 v7。 针对发布 SPF 记录的 138,927,207 个域名的汇总普查数据，来自 261 百万个已评级域名。参见我们如何评级。
拥有 SPF 与正确设置 SPF 并不是一回事——而且大多数发布 SPF 的域名都设置得太弱，起不了多大作用。 在拥有 SPF 记录的 139 百万 个域名中，有 55.8% 以 ~all（softfail，软失败）结尾——这是一种宽松设置，它告诉接收方”这可能是伪造的，但仍然投递它”。只有 39.3% 使用严格的 -all。SPF 被广泛采用，但多数情况下被削去了利爪。
“all” 机制：SPF 成败的关键所在
每条 SPF 记录都以一个 “all” 机制结尾，它规定了如何处理来自不在你列表中的服务器的邮件。这正是 SPF 的全部意义所在——也是它最常被削弱的地方：
| 结尾 | 含义 | 拥有 SPF 的域名 |
|---|---|---|
-all（hardfail，硬失败） | 拒绝未列出的发件人——严格的、本应采用的设置 | 39.3% |
~all（softfail，软失败） | “可能是伪造的，但仍然接受它” | 55.8% |
?all（中立） | 不表态——实际上没有任何保护 | 3.0% |
+all | 授权整个互联网以你的名义发送邮件 | 36,014 个域名 |
| 其他 / 无 | redirect/include-only 或没有结尾的 all | 1.8% |
头条结论是：softfail（~all）是最常见的设置，占 55.8%——比 hardfail 还多。单凭其本身，softfail 提供的保护很弱：它请求接收方不要信任未列出的邮件，但又不拒绝它。
危险的边缘情况
+all—— 36,014 个域名。 这是最糟糕的 SPF 取值：它明确告诉全世界，任何服务器都被允许以该域名的名义发送邮件。这几乎总是复制粘贴的失误，而且严格来说比根本没有 SPF 还要糟。- DNS 查询过多 —— 7,958 个域名。 SPF 最多允许 10 次嵌套 DNS 查询；超过后，该记录就成了接收方视为损坏的 “permerror”。它比人们担心的要罕见（占 SPF 记录的 0.01%），但一旦发生，就会悄无声息地使你的整个 SPF 失效。
softfail 真的是个问题吗？
如果有 DMARC 作为后盾就不是。现代最佳实践是 ~all 加上 quarantine 或 reject 的 DMARC 策略——这种搭配既能给你严格的强制执行，又不会破坏转发的邮件。问题在于大量域名使用 ~all 却背后没有强制执行的 DMARC——只有10.59% 的所有域名强制执行 DMARC——这使得 softfail 几乎毫无作用。设置为 ~all 的 SPF 是达成目的的手段；没有 DMARC，它只是一个建议。
常见问题
SPF 中 ~all 和 -all 有什么区别？
-all（hardfail）告诉接收方拒绝来自不在你列表中的服务器的邮件。~all（softfail）告诉它们仍然接受邮件，但标记为可疑。55.8% 拥有 SPF 的域名使用 ~all；39.3% 使用 -all。
使用 ~all（softfail）安全吗？
安全——但只有在与强制执行的 DMARC 策略（quarantine 或 reject）配合使用时才安全。单凭其本身，softfail 提供的保护很弱。
+all 有什么作用？
+all 授权互联网上的每一台服务器以你的域名发送邮件——比没有 SPF 还糟。36,014 个域名有此设置，几乎都是出于失误。
SPF 的”查询过多”错误是什么？ SPF 最多允许 10 次嵌套 DNS 查询；超过后，记录就以 “permerror” 失败并被忽略。它影响 7,958 个域名。
检查你的 SPF 是否设置正确
发布 SPF 只完成了一半工作；严格地设置它并用 DMARC 作为后盾才是另一半。私密且免费地检查你的域名。
检查你的域名 → · 修复 SPF → · 修复 DMARC → · 为什么我的邮件进了垃圾箱 → · 仅汇总数据。数据在欧盟存储和处理。