你的邮件被退回，邮件头显示 spf=fail。眼前是 550 5.7.1 或 550 5.7.26，而客户还在等待一封从未到达的回复。
SPF 失败不是内容问题，而是 DNS 身份验证失败。收件服务器检查 SPF 记录后，发现发件 IP 不在授权列表中，因此可能在邮件进入垃圾邮件夹之前就将其拒收。
自 2024 年二月以来，Google 和 Yahoo 可能在协议层拒收未经身份验证的邮件，而不只是标记为可疑。本指南解释具体错误代码，说明如何在邮件头中找到失败的 IP，并介绍三种能够解决大部分常见 SPF 失败的 DNS 修复方法，帮助你先处理最匹配的原因。
如果你第一次在自己的域名上设置邮箱，请先完善基础 DNS 配置，再排查故障。SPF 问题往往源于初始设置不完整。
什么是 SPF 失败？
收件服务器评估域名的 Sender Policy Framework 记录，却没有在授权列表中找到发件 IP 地址时，就会出现 SPF 失败。SPF 以 DNS TXT 记录发布，列出可代表你发信的 IP 地址和邮件服务。检查失败后，服务器可能直接拒收邮件 (hard fail)，也可能将其作为可疑邮件接收 (soft fail)。DMARC 策略会把两种情况都计为失败。
SPF 检查的是信封发件人，即 SMTP 握手期间协商的 MAIL FROM 地址，而不是收件人看到的 "From" 邮件头。追查故障点时，这一区别很重要。
| SPF 结果 | 记录限定符 | 邮件会怎样 |
|---|---|---|
Hard Fail (fail) |
-all |
IP 未获授权，收件服务器可能按照策略拒收邮件。 |
Soft Fail (softfail) |
~all |
IP 未获授权，邮件被接收但会标记，通常可能进入垃圾邮件夹。 |
| PermError | 语法错误或 10+ 次查询 | 记录无效，包括正常流量在内的发件人都可能无法通过 SPF。 |
| Pass | -all（IP 已列出） |
IP 已获授权，可按正常流程交付。 |
更改任何内容前先读懂错误代码
不同邮件服务器会为 SPF 失败返回不同 SMTP 代码。错误代码表明收件方做出了什么判断以及原因。把 550 5.7.26 当作普通 550 5.7.1 处理会浪费排查时间。修改 DNS 记录前，应先把代码与原因对应起来。
| 服务商 | 错误代码 | 含义 |
|---|---|---|
| Google / Gmail | 550 5.7.26 |
未经身份验证的邮件被拦截，未找到通过验证的 SPF 或 DKIM。这是 Google 2024 年二月批量发件人规则下的常见拒收。 |
| Microsoft / Outlook | 550 5.7.515 |
发件人身份未经验证，SPF 或 DKIM 失败。"Access Denied" 可能在扫描邮件内容前触发。 |
| 通用收件服务器 | 550 5.7.1 |
中继访问被拒绝。这是策略拒收的通用代码，表示收件方对发件 IP 缺乏足够信任。 |
| Soft Fail（已接收） | 邮件头显示 ~all |
SPF 检查失败，但策略较宽松。邮件可能进入垃圾邮件夹，而不是直接被拒收。 |
第 1 步：在邮件头中找到失败的 IP
不要猜测哪个 IP 导致 SPF 失败。打开退回邮件或退信通知的原始邮件头，搜索 Authentication-Results。该邮件头会给出收件方评估的具体 IP 及其判断。
Authentication-Results: mx.google.com;
spf=fail (google.com: domain of team@example.com does not designate
192.0.2.55 as permitted sender)其中包含两项取证数据：发件 IP (192.0.2.55) 和接受检查的域名 (example.com)。接下来确定该 IP 的所有者：
- 最近接入的 SaaS 工具？(HubSpot、Zendesk、Shopify)
- 你的 Web 服务器？(WordPress、cPanel)
- 邮件转发服务？（参见下文的转发陷阱）
然后快速查询当前 SPF 记录：
dig +short txt yourdomain.com | grep spf如果看到不止一行以 v=spf1 开头的内容，就已经找到一个可能的问题。
第 2 步：三种最常见的 SPF 失败修复方法
大多数 SPF 失败可归结为三种根本原因：缺少服务商 include、记录重复，或超过 10 次 DNS 查询限制。请根据第 1 步的发现选择修复方法。
修复 1：缺少 Include（服务商缺口）
你添加了 HelpScout、HubSpot、Zendesk 或 Shopify 事务性邮件等新工具，却没有更新 DNS。该服务会使用尚未授权的 IP 代表你发信。这是接入新服务商后常见的 SPF 失败原因。
失败的记录：
v=spf1 include:spf.trekmail.net -all通过的记录（添加 HelpScout 后）：
v=spf1 include:spf.trekmail.net include:helpscoutemail.com -all在服务商文档中找到所需的 SPF include 字符串，将其加入现有 SPF TXT 记录，不要新建记录。所有实际用于发信的服务都应列出。
修复 2：重复记录（严重语法错误）
每个域名只能有一条 SPF 记录。如果为新工具添加第二条 TXT 记录，而不是并入现有记录，收件方会看到两项冲突策略并判定它们无效。结果是 PermError，可能让域名发出的所有邮件出现 hard SPF fail，包括此前能够正常交付的邮件。
错误，存在两条独立记录：
v=spf1 include:spf.trekmail.net -all
v=spf1 include:_spf.google.com -all正确，合并为一条记录：
v=spf1 include:spf.trekmail.net include:_spf.google.com -all登录 DNS 服务商，删除多余 SPF TXT 记录，并把所有内容合并到一行。重复记录导致的 PermError 可能持续影响所有发件人，直到记录得到修复。
修复 3：10 次查询限制（架构问题）
RFC 7208 将 SPF 评估限制为 10 次 DNS 查询，以免服务器被用作 DNS 放大攻击媒介。include、a 和 mx 等机制都会计入限制，嵌套 include 也会计算，例如服务商的记录又包含其供应商的记录。
超过 10 次查询会产生 PermError，所有发件人的 SPF 都可能失败。请追踪记录，检查当前查询次数：
dig +short txt yourdomain.com手动计算每个 include、a 和 mx 机制，再继续追踪各服务商的嵌套 include。超出限额时，可以采用两种清晰的方法：
- 把发件人分配到子域名。将大批量营销工具移至
marketing.yourdomain.com。该子域名会获得独立于主域名记录的全新 10 次查询额度。 - 扁平化记录。把
include链替换为其解析出的实际 IP，并使用ip4:或ip6:机制。这些机制不计为查询。代价是服务商轮换 IP 后，需要手动更新记录。
还要注意空查询限制。如果链中超过两次查询返回 NXDOMAIN，例如误写为 include:spf.gogle.com，RFC 7208 §11.1 会判定记录无效。嵌套服务商 include 中的一个拼写错误就可能影响整个 SPF 评估。
转发陷阱：为什么合法邮件也会 SPF 失败
有些 SPF 失败与 DNS 配置无关。你向校友地址 (alice@university.edu) 发信，该地址会自动转发到 Gmail (alice@gmail.com)。Gmail 看到邮件来自大学服务器的 IP，而你的 SPF 记录没有授权该 IP，因此即使原始配置正确，SPF 仍会失败。
路径是：你的服务器 -> 大学服务器 -> Gmail。Gmail 会评估最后一跳。仅靠 SPF 无法修复转发失败，因为 SPF 只授权原始发件 IP。转发服务器介入后，IP 检查就不再匹配。
相应的解决方法是 DKIM。DKIM 使用加密方式签署邮件正文和邮件头。转发服务器通常不会修改正文，因此 DKIM 签名往往能够经过中继继续有效。即使 SPF 失败，有效的 DKIM 签名仍可让邮件通过 DMARC 身份验证。
如果你运行基础设施级转发并需要兼容 SPF 的改写，可以了解 Sender Rewriting Scheme (SRS)。转发服务器可用它改写信封发件人，使 SPF 有机会在最终目的地通过。更广泛的转发交付问题可参阅邮件转发设置与修复指南。
继续操作前验证修复结果
更新 DNS 记录后，请等待传播。对大多数服务商而言通常需要 5 到 30 分钟，少数情况下可能需要数小时。随后验证修复是否已经生效。
向 Gmail 地址发送测试邮件，打开原始邮件头并搜索 Authentication-Results。理想结果如下：
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of team@example.com designates
192.0.2.55 as permitted sender)如果仍看到 spf=fail 或 spf=softfail，可能是修复尚未传播，也可能是记录仍有问题。将邮件头中的 IP 与更新后记录里的 IP 对照，两者应当匹配。
也可以直接验证记录：
dig +short txt yourdomain.com确认只有一条记录以 v=spf1 开头，其中包含实际使用的发信服务，并以 -all (hard fail) 或 ~all (soft fail) 结尾。
跨多个域名管理 SPF
对一个域名而言，SPF 管理通常是一次性任务：添加 include、合并重复项并修正查询次数。但如果管理 10、50 或 500 个域名的邮件，每个域名都有自己的 SPF 记录和 SaaS 服务商，逐一手动排查 SPF 失败会带来明显的运营负担。
| 方式 | 所需 SPF 记录 | 由谁管理 IP 信誉 |
|---|---|---|
| DIY / BYO SMTP | 列出所有服务商的完整记录 | 由你手动管理 |
| TrekMail Managed SMTP | v=spf1 include:spf.trekmail.net -all |
TrekMail：IP 轮换、信誉和 DKIM 对齐 |
TrekMail 托管 SMTP 在 $3.50/mo 起的 Starter 计划中提供，可将配置减少为每个域名一个 include。TrekMail 负责 IP 轮换、退信监控、DKIM 对齐和底层交付基础设施。使用 Agency 计划 ($23.25/mo) 时，代理商可以向客户域名应用标准 DNS 模板，不必在大量单独记录中逐个查找 SPF 失败。
如果想实际了解托管交付，可以开始 14-day 免费试用。
SPF 失败简要总结
SPF 失败意味着收件服务器检查 DNS 后没有找到发件 IP，并执行了相应策略。Hard fail (-all) 可能意味着拒收，soft fail (~all) 可能进入垃圾邮件夹。PermError 表示记录损坏，在修复记录前，发件人的 SPF 都可能失败。
按顺序进行修复：
- 在
Authentication-Results邮件头中找到失败的 IP - 如果新服务导致 SPF 失败，添加缺少的服务商 include
- 把重复 SPF 记录合并为一条
- 把 DNS 查询减少到 10 次以下，或将大批量发件人分配到子域名
- 如果转发邮件出现 SPF 失败，请实施 DKIM，因为 SPF 无法可靠地经过中继
先选择正确的修复方法，再通过邮件头验证结果。
