Defaults.Exposed › 报告
SPF +all：任由整个互联网冒名发信的那些域名（2026）
发布于 2026-07-03
数据截至 2026-06-29 · 方法论 v7。 对 261 百万个已评级域名的汇总普查。所有数据均为汇总统计——绝不针对某个企业的单条记录。参见我们如何评级。
36,014 个域名的 SPF 记录以 +all 结尾——这是一份已公开、可被机器读取的声明，表示互联网上的每一台服务器都获准以它们的名义发送电子邮件。 这是最罕见的 SPF 错误配置（占发布者的 0.03%），也是最自毁的一种：缺失记录只是让接收方各凭启发式判断，而 +all 却是明确地告诉他们冒名者是合法的。
SPF 记录中的 +all 是什么意思？
末尾的 all 机制带有一个限定符——它决定了对不在你名单上的发件人应作何裁决。-all 拒绝他们，~all 怀疑他们——而 +all 批准他们。当接收方拿一封伪造邮件去核对一条 +all 记录时，会返回一个干净的 SPF 通过。一句话就是这样的危害：你的防护反倒替冒名者作了担保。而且由于 SPF 通过能满足 DMARC 的 SPF 一侧，这个通过还能帮助一封仿冒邮件穿过那个原本就是为了拦住它而建立的系统。
分布图：“欢迎垫”聚集在哪里
+all 到处都有，但极为稀薄——不过其比率因后缀而有明显差异。计数来自普查；比率 = 每 10,000 个该 TLD 的 SPF 发布者中的 +all 记录数：
| TLD | +all 域名数 | 每万个的比率 |
|---|---|---|
| .be | 1,399 | 22.5 |
| .nl | 1,965 | 8.8 |
| .eu | 672 | 6.6 |
| .fr | 1,147 | 6.2 |
| .net | 1,640 | 3.6 |
| .org | 1,392 | 2.8 |
| .com | 16,636 | 2.4 |
| .de | 732 | 1.3 |
比荷卢—法国这一簇尤为突出：一个 .be 的 SPF 发布者带有 +all 的可能性大约是 .com 发布者的 9 倍（每万个 22.5 对 2.4）。如此集中的模式很少意味着成千上万个各自独立的失误——最合理的解释是存在一个共同源头：某个区域性的托管面板、注册商模板或教程文章附带了 +all，然后被复制沿用了许多年。同样的指纹也出现在严重程度低一档的地方：.za 有 22.6% 的 SPF 记录以中立的 ?all 结尾，这个全国性的异常值指向的是同一个方向。
一个域名怎么会落到 +all 的地步？
三条途径，都很无辜：
- 那个永远没结束的调试。
+all会让每一个 SPF 问题都消失——邮件畅通，报错停止。有人为了打通一次上线把它设成了这样，而这条记录在事件结束后依然存活了下来。 - 误读了语法。 如果你从没见过限定符对照表，
+看起来就像是”允许我的名单”的意思。本意是-all，那个字符却把它反了过来。 - 继承来的模板。 正如分布图所暗示的，有些记录一到手就已经是坏的，来自某个面板或指南。
只需改一个字符的修复
把 +all 改成 -all——或者改成 ~all，并在其背后配上强制执行的 DMARC。一条 TXT 记录里的一个字符，免费，而且只要 DNS 更新就会生效——通常在一小时内。没有比这更快的安全改进能在一个域名上实现了。
常见问题
SPF 记录中的 +all 是什么意思？ 它授权互联网上的每一台服务器以你的域名发送电子邮件——与 SPF 的目的正好相反。截至 2026-06-29，有 36,014 个域名发布了它。
+all 比根本没有 SPF 记录更糟糕吗？
在最要紧的那一点上，是的：没有记录只是让接收方去猜，而 +all 却能把一封伪造邮件转化为一个干净的 SPF 通过——这个通过甚至还能帮它穿过 DMARC。有些过滤器还会把 +all 本身当作垃圾邮件信号，所以它连你的合法邮件也可能一并伤害。
我该如何检查自己的域名是否有 +all？
读取你的 TXT 记录（dig TXT yourdomain.com），或者运行免费检查——一个宽松的限定符会被立即标记出来。
为什么会有模板默认用 +all？ 最合理的解释是它不会产生任何支持工单——每一次投递都”成功”，包括那些欺诈性的。我们数据中的区域聚集现象，与其说是成千上万个个人选择，不如说更符合模板默认值的特征，尽管普查看到的是记录，而非它们的作者。
检查你的结尾
大多数把”欢迎垫”摆在门外的域名所有者，压根不知道它在那里。读一读你自己的门垫只要半分钟，而重写它只花一个字符。
检查你的域名 → · 修复 SPF → · ~all 对 -all → · 错误配置名人堂 → · 仅汇总数据。数据在欧盟境内存储和处理。