Defaults.Exposed › 修复 › Guides
你的 SaaS 工具 SPF 一直失败？原因和修复顺序——欧洲版（2026）
发布于 2026-07-08
数据截至 2026-06-29 · 方法论 v7。 基于 261 百万个已评分域名的汇总普查数据。参见我们如何评分。
当一个 SaaS 工具“SPF 失败”时，问题通常不在你的记录本身：要么是邮件没通过 DMARC 对齐，要么是你的 include 链已经超出了 SPF 10 次 DNS 查询的上限。根据 Defaults.Exposed 对 261,086,232 个域名的普查，在 138,927,207 个发布 SPF 的域名中，有 2,119,539 个正处在 9–10 次查询——只差一个 SaaS include 就会跌下悬崖。
以下内容：怎么判断你到底是这两个问题中的哪一个，然后是修复顺序——先扫描，找出这个工具真正的发信域名，把服务商切换到自定义域名 DKIM，只在真正有帮助的地方才添加 SPF include——外加针对 HubSpot、Salesforce、Mailchimp 和 SendGrid 的具体做法。
为什么来自 SaaS 工具的邮件会 SPF 失败？
几乎所有情况都属于这三种模式之一：
| 报告或退信说了什么 | 真正的问题是什么 | 修法 |
|---|---|---|
| SPF 通过，DMARC 仍然失败 | 对齐问题：这个工具在它自己的退信域名上通过了 SPF，不是你的域名 | 开启服务商的自定义域名 DKIM（CNAME） |
SPF permerror | 你的 include 链超出了 SPF 10 次 DNS 查询的上限 | 精简 include；见查询次数过多的修法 |
SPF fail / softfail | 这个工具确实在用你的退信路径发信，但没有出现在你的记录里 | 添加该服务商的 include，或启用它的自定义退信域名 |
数据截至 2026-06-29。
加粗的那一行是大多数人所处的位置。给每个工具都加一行 include: 解决不了这个问题——而且每加一行都让你离第二行更近一步：至少已有 797,263 个域名已经越过了 10 次查询的上限，它们的 SPF 现在返回 PermError，起不到任何保护作用。完整数据见 SPF PermError 报告。
SPF 实际检查的是哪个域名？
不是你 From 标头里的那个。接收方是对照 Return-Path 域名（RFC5321.MailFrom，也叫退信地址或信封发信人）来评估 SPF 的——收件人看到的 From 标头在 SPF 检查本身中完全不起作用。
这一个事实就能解释大多数“SaaS SPF 失败”。你的营销平台发信时用的 Return-Path 类似 [email protected]；SPF 检查的是 vendor.com，而且干干净净地通过了。然后 DMARC 会问：这个通过了 SPF 检查的域名，和你的 From 域名一致吗？不一致，所以 DMARC 里的 SPF 这条腿失败了，你的仪表盘上就显示“SPF 失败”。编辑你自己的 SPF 记录解决不了这个问题——你的记录根本没被查询过。
修复顺序是什么？
- 先运行免费扫描。 它会一次性告诉你 SPF 是缺失、重复、超出查询上限还是正常，以及 DMARC 现状如何——在你动 DNS 之前。
- 找出这个工具实际使用的 Return-Path。 从这个工具给自己发一封测试邮件，读取原始邮件里的 Return-Path 标头（以及 Authentication-Results）。这能告诉你自己处在上表的哪一行。
- 开启服务商的自定义域名 DKIM。 每个正经的 SaaS 工具都提供“域名认证”功能：几条 CNAME 记录，让它能以你的域名做 DKIM 签名。这个签名和你的 From 域名对齐，所以 DMARC 能通过 DKIM 这条腿——而且是持久的，即便邮件被转发也一样。这才是能长久生效的修法。
- 只有当服务商真正用你的退信路径时，才添加它的 SPF include——也就是你已经启用了它的自定义退信域名，或者它确实在信封里用了你的域名发信。给一个用自己域名退信的服务商添加 include，什么都换不到，只会消耗你的查询预算。
- 保存之前先数一数你的 DNS 查询次数。 上限是 10 次已解析的查询，include 会递归计数，而 2,119,539 个域名已经处在 9–10 次——普查的第 99 百分位是 9 次。快到边缘了？先删掉不再使用的工具的 include。刚换过邮件服务商？检查有没有残留的第二条记录——两条 SPF 记录等于一个 PermError。
- 重新扫描并确认。 SPF 在正确的域名上通过，DKIM 已对齐，DMARC 通过。完整参考见如何修复 SPF；服务商操作指南如 GoDaddy 上的 SPF 和 IONOS 上的 DMARC 覆盖了具体的 DNS 面板点击路径。
HubSpot、Salesforce、Mailchimp 和 SendGrid 分别该怎么做？
HubSpot。 在 HubSpot 设置里连接你的发信域名，发布它签发的两条 DKIM CNAME（hs1-… / hs2-…）。这能让 DKIM 和你的 From 域名对齐。除非你已经把 HubSpot 配置成使用你自己的退信域名，否则不需要 HubSpot 的 SPF include。
Salesforce。 在 Salesforce Setup 里创建一个 DKIM 密钥，发布它生成的那对 CNAME。如果 Salesforce 用你组织的退信路径发信，就添加 include:_spf.salesforce.com 并配置退信域名——这是少数几个真正经常需要 SPF include 的大型 CRM 之一。
Mailchimp。 认证你的域名，发布 k2 / k3 这两条 DKIM CNAME。Mailchimp 的对齐只靠 DKIM——已经没有 SPF include 可以加了，从旧教程里抄一条只会白白浪费查询次数。
SendGrid。 完成域名认证（“automated security”）：三条 CNAME，同时处理 DKIM 和你自己子域名上的退信路径。不需要 SPF include。在 SPF 授权了 sendgrid.net 的 740,321 个域名中，只有 18.0% 有强制执行的 DMARC（数据截至 2026-06-29）——大多数 SendGrid 发件方就差最后一步。
Zendesk 及其他所有工具：模式相同。找到该工具的“域名认证”页面，发布它的 DKIM CNAME，只有在该工具文档明确说明它使用你的退信路径时，才去动 SPF。
SPF 对欧洲企业有什么不同吗？
没有——SPF、DKIM 和 DMARC 在任何地方的工作原理都一样。在欧洲不同的是背景：谁在问，以及你的邻居们已经做到了什么程度。
你的 ccTLD 决定了当地的基准线。 欧洲的 ccTLD 发布 SPF 的比例明显高于 .com，但真正把活儿做完——在此之上再加一个强制执行的 DMARC 策略——的域名，在任何地方都是少数：
| TLD | SPF 采用率（占已评分域名） | 强制执行 DMARC（占已评分域名） |
|---|---|---|
| .nl | 75.91% | 29.43% |
| .ie | 70.89% | 8.79% |
| .de | 64.67% | 21.38% |
| .dk | 50.42% | 19.88% |
| .com | 54.14% | 9.50% |
数据截至 2026-06-29。法国：13.65% 强制执行 DMARC；意大利：5.24%。
你的欧洲主机商的默认设置很重要。 有 4,346,526 个域名在 SPF 里授权了 IONOS 的欧盟邮件服务器（_spf-eu.ionos.com）——其中只有 0.3% 以严格的 -all 结尾，1.0% 强制执行 DMARC。OVH 的 2,132,049 个在严格性上表现更好（43.7%），但只有 2.2% 强制执行 DMARC（数据截至 2026-06-29）。如果你从没动过自己的记录，你现在站的就是这些默认设置。
监管机构现在明确点了名。 NIS2 第 21(2)(j) 条要求受监管实体保障其通信安全，欧盟委员会实施法规 (EU) 2024/2690 明确规定了邮件和 DNS 安全措施。邮件认证是其中具体、可核查的一环——而且难得的是，作为合规要求，它是免费的。
关于数据驻留： Defaults.Exposed 的扫描器和普查系统运行在 AWS eu-west-1，我们只公开汇总数据，一次扫描只检查你所询问的那一个域名。
常见问题
我的 SPF 检测工具显示“通过”，但这个工具的仪表盘却说 SPF 失败——为什么？ 检测工具测的是你的记录；接收方测的是这个工具实际使用的 Return-Path 域名，然后 DMARC 把它和你的 From 域名做比对。这是一个对齐失败，不是记录失败——要靠服务商的自定义域名 DKIM 来修，不是靠修改 SPF。
我要不要干脆给我们用的每个工具都加上 SPF include？ 不要。每一个 include 都会递归地消耗 SPF 10 次查询预算的一部分：在 138,927,207 个发布 SPF 的域名中，有 2,119,539 个处在 9–10 次查询，至少 797,263 个已经超标——它们的 SPF 会返回 PermError，起不到任何保护作用（数据截至 2026-06-29）。
加了 include 也能顺带修好 DMARC 吗？ 只有当这个工具用你的退信路径发信、让 SPF 既通过又对齐时才行。对大多数 SaaS 工具来说并非如此——这就是为什么让 SaaS 邮件的 DMARC 通过 的那条腿是对齐的 DKIM，而不是 SPF。
这在欧盟是一项法律要求吗？ 对于 NIS2 监管范围内的实体来说，第 21(2)(j) 条和实施法规 (EU) 2024/2690 把邮件安全变成了一项义务。即便不在监管范围内，保险公司和客户问卷也越来越常问到这个——截至 2026-06-29，没有任何一个欧盟 ccTLD 有超过三分之一的域名达到强制执行的 DMARC 策略（表现最好的 .nl 也只有 29.43%；.it 是 5.24%）。
把报告发给老板
CNAME 生效后，重新运行扫描，把评分报告转发给企业负责人或客户。它会用大白话说明之前哪里在失败、你修了什么、这个域名现在处于什么状态——这正是保险续保或客户安全问卷所需要的书面证据，而不只是你嘴上说说。
免费检查你的域名
私密、仅域名所有者可见地看看 SPF、DKIM 和 DMARC 到底是哪条腿在失败。
检查你的域名 → · 修复 SPF → · SPF PermError：“DNS 查询次数过多” → · 我们如何评分 → · 仅使用汇总数据。数据在欧盟境内存储和处理。