SPF 是什么？

核心解释

SPF 通常存放在 TXT 记录中，收件服务器可据此检查发信来源是否获得域名授权。

SPF 验证的其实是哪一个身份

SPF（Sender Policy Framework）让域名通过 DNS TXT 记录声明哪些主机有权代表它发送邮件。收件服务器把实际连接 IP 与 SMTP 会话中的 MAIL FROM 域名或 HELO 身份进行核对，得到 pass、fail、softfail、neutral、temperror 等结果。它并不是简单检查用户在邮件客户端看到的 From 标题。

这一区别很重要：攻击者可能让信封发件人与可见 From 不同，从而在 SPF 通过的同时冒用显示品牌。DMARC 会进一步要求 SPF 验证域或 DKIM 签名域与可见 From 对齐，补上单独使用 SPF 时的身份间隙。

一条 SPF 策略如何被展开

• 记录以 v=spf1 开始，ip4、ip6 可以直接授权网段，a、mx、include、exists 等机制会触发不同形式的 DNS 查询。
• 解析按从左到右进行，遇到首个匹配机制后返回对应限定符；末尾 -all 通常表示未授权来源应失败，~all 表示软失败。
• include 常用于授权 SaaS 发信平台，但被引用域的策略变化会同步影响当前域名，因此需要定期清理已停用服务。
• SPF 规定会产生 DNS 查询的机制和修饰符总数上限，过度嵌套可能导致 permerror，使原本合法的邮件无法得到通过结果。

转发、群组和多平台发信为何容易失败

邮件被传统转发时，新的中转服务器 IP 往往不在原始发件域 SPF 授权范围内，因此 SPF 可能失败，即使邮件内容没有被修改。SRS 可以重写信封发件人以保留可验证路径；DKIM 若签名仍完整，也可能帮助 DMARC 继续通过。

企业同时使用官网、工单、营销、账单和招聘平台发信时，遗漏某个平台会造成合法邮件失败，长期保留无用 include 又会扩大授权范围。建立发信资产清单，比机械堆叠服务商记录更可靠。

实际应用与信息解读

完整取得 SPF 文本后，可以直接展示授权机制、all 策略与明显语法问题。授权网段属于发信权限，不代表该地址一定正在发信；include 指向某服务商通常说明域名可能接入该平台，但历史残留记录也很常见。

查不到 SPF 时，先确认查询名称、TXT 响应与临时 DNS 错误。只有记录确实不存在且域名承担发信时，才适合提示邮件身份保护可能不足；域名用途未知时，状态应保留为未知。

重点关注

SPF 能减少域名被直接冒用发信，但通常需要与 DKIM、DMARC 一起使用。

常见问题

一个域名可以发布多条 SPF 记录吗？

同一名称不应发布多个独立 v=spf1 记录，这会造成永久错误。多个发信来源应合并进一条经过控制的策略。

~all 和 -all 有什么区别？

~all 表示 softfail，通常用于过渡或观察；-all 明确表示未匹配来源未获授权。收件方最终如何处理仍受 DMARC 和本地策略影响。

SPF 通过为什么 DMARC 仍可能失败？

DMARC 还要求 SPF 验证使用的域与可见 From 域对齐。若两者不同，SPF 本身可以 pass，但不能为该可见身份提供 DMARC 对齐。