Defaults.Exposed › 报告
什么是 SPF——以及我该如何修复我的 SPF 记录？（2026）
发布于 2026-07-01
数据截至 2026-06-29 · 方法论 v7。 对 261 百万个已评级域名的汇总普查数据。SPF（发件人策略框架，Sender Policy Framework）是一条 DNS 记录，列明允许哪些服务器代表你的域名发送邮件。参见我们如何评级。
SPF 是你 DNS 中的一行内容，它宣告”这些服务器可以以我的名义发送邮件——其余的都视为可疑”。 在 261 百万个域名中，有 53.21% 发布了 SPF 记录。这听起来很健康，但仅有一条记录并不能保护你：真正决定未列出的发件人是被拒绝还是被放行的，是那个末尾限定符，而相当大一部分记录设置得过于宽松，实际上什么都没改变。以下是 SPF 的真正作用、我们最常见的错误，以及如何修复你自己的记录。
什么是 SPF 记录？
当一台邮件服务器收到一封声称来自你域名的邮件时，它会查找你的 SPF 记录，并检查发送方服务器是否在你的批准列表中。记录会以一条针对不在列表中的一切内容的指令结尾：
-all（硬失败，hardfail）——拒绝未列出的发件人。这才是动真格的设置。~all（软失败，softfail）——接受但标记为可疑。大多数邮件仍会被投递。?all（中立，neutral）——什么也不做；等同于没有任何立场。+all——接受来自任何人的任何邮件。这是主动制造危险，绝不应发布。
在发布 SPF 的 139 百万个域名中，只有 39.3% 使用了严格的 -all，而 55.8% 使用了较宽松的 ~all。并且有 36,014 个域名发布了 +all——这是一封公开邀请函，告诉全世界任何人都可以以它们的名义发送邮件。
悄悄让 SPF 失效的那些错误
- DNS 查找次数过多。 SPF 的查找次数上限为 10 次（RFC 7208）；一旦超过，整条记录就会以 “permerror” 失败并被忽略。有 7,958 个域名（占拥有 SPF 域名的 0.01%）触碰了这个上限——通常是因为为第三方发件人串联了过多的
include:语句。 - 发布
+all。 罕见但灾难性——它彻底禁用了 SPF，并为伪造者背书。 - 以为 SPF 能阻止冒充。 单靠它并不能。SPF 检查的是技术层面的发送路径，而不是人们看到的”发件人（From）“地址。在所有域名中，有 32.4% 发布了 SPF 但没有 DMARC——因此可见的发件人仍然可以被伪造。SPF 是管道，DMARC 强制策略才是那把锁。参见 没有 DMARC 的 SPF。
我该如何修复我的 SPF 记录？
- 只发布一条 SPF 记录——一条以
v=spf1开头的 TXT 记录。绝不要发布两条；那会自动导致失败。 - 列出每一个合法发件人——你的邮箱服务商、营销平台、CRM、客服系统——使用它们文档中给出的
include:值。 - 以
-all结尾——当你确信列表已完整时。如果需要留出安全余地，可先从~all起步，然后逐步收紧。参见修复 SPF。 - 保持在 10 次查找以内——如果接近上限，就展平或合并 include。
- 然后添加 DMARC——SPF 和 DKIM 共同支撑 DMARC，这才是真正能阻止他人以你的域名发送邮件的控制手段。
常见问题
SPF 记录长什么样？
一条 DNS TXT 记录，例如 v=spf1 include:_spf.google.com -all。其中的 include: 条目是你批准的发件人，而末尾的 -all 会拒绝其他所有人。
~all 和 -all 哪个更好？
-all（硬失败）更强——它告诉收件方拒绝未列出的发件人。~all（软失败）通常仍会投递邮件。截至 2026-06-29，39.3% 的 SPF 记录使用 -all，55.8% 使用 ~all。
SPF 能阻止别人伪造我的域名吗？ 单靠它不能。SPF 不管理可见的”发件人（From）“地址。你需要将 DMARC 设为强制执行。有 32.4% 的域名有 SPF 但没有 DMARC，因而仍然可被伪造。
为什么我的 SPF 记录看起来没问题却”失败”了？
最常见的原因是它超过了 10 次查找的上限并返回 permerror。有 0.01% 拥有 SPF 的域名遇到了这个问题。请减少 include: 查找的数量。
修复 SPF 费用高吗？ 不高——这是一次免费的 DNS 更改。真正的功夫在于把发件人列表做得完整而准确，而不是花钱。
免费检查你域名的 SPF
查看你的 SPF 记录、它的末尾限定符，以及它是否完整——私密进行，且仅域名所有者可见。
检查你的域名 → · 修复 SPF → · 修复 DMARC → · 我们如何评级 → · 仅汇总数据。数据在欧盟境内存储与处理。