SPF 记录完整配置指南：语法、示例与常见错误

SPF（Sender Policy Framework）是发布在域名 DNS 中的一条以 v=spf1 开头的 TXT 记录，用来声明哪些邮件服务器有权代表你的域名发信。它配置在域名的 DNS 服务商处，主机记录通常填 @（根域名），记录内容由 ip4、include 等机制和结尾的 all 限定符组成。添加记录并等待 TTL 生效后，可使用在线 SPF 检查工具验证记录是否解析正确。本文系统讲解 SPF 语法、五步配置流程、主流邮箱服务商示例以及部署中的常见错误。

什么是 SPF 记录

SPF 是发布在域名 DNS 中的一条以 v=spf1 开头的 TXT 记录，用于声明哪些服务器有权代表该域名发送邮件。当收件服务器收到一封声称来自你的域名的邮件时，会查询并解析这条记录，判断实际发信 IP 是否在授权范围内，再决定是否信任邮件来源。SPF 于 2014 年随 RFC 7208 成为正式标准，如今 Gmail、Outlook、QQ 邮箱等主流邮箱服务商都会对来信执行 SPF 校验。

需要特别注意的是，SPF 校验的是邮件信封上的 Return-Path（退信地址，也称 bounce 地址）域名，而不是收件人在邮件客户端看到的 From 显示地址。因此仅配置 SPF 并不能阻止发件人显示地址被仿冒，显示地址层面的防伪需要配合 DKIM 签名与 DMARC 对齐机制才能完成。

SPF 如何工作

SPF 的完整校验过程发生在收件方的邮件服务器上，可以概括为以下四步：

1. 收件方在 SMTP 会话中获取连接方的发信 IP，并从邮件信封的 Return-Path 中提取发件域名（即退信地址中 @ 后面的部分）。
2. 收件方向 DNS 查询该域名以 v=spf1 开头的 TXT 记录；如果域名没有发布 SPF 记录，判定结果为 none。
3. 收件方用实际发信 IP 按顺序匹配记录中的 ip4、ip6、a、mx、include 等机制，逐条判断该 IP 是否获得授权。
4. 匹配结束后给出最终判定：pass（授权通过）、fail（明确拒绝）、softfail（可疑但不拒绝）、neutral（不表态）或 none（无策略），该结果会继续参与 DMARC 评估与反垃圾系统的综合判断。

SPF 语法详解

一条 SPF 记录由版本标识、若干授权机制（mechanism）和结尾的 all 组成，各部分以空格分隔，按从左到右的顺序评估。下表逐项说明常用机制的含义：

机制	含义与用法
v=spf1	SPF 版本标识，必须位于记录最开头，收件方据此识别这是一条 SPF 记录。
ip4: / ip6:	授权指定的 IPv4/IPv6 地址或网段，例如 ip4:203.0.113.10、ip4:198.51.100.0/24，不消耗 DNS 查询次数。
a	若当前域名（或 a:example.com 指定域名）的 A/AAAA 记录解析出的 IP 与发信 IP 一致，则判定通过。
mx	若域名 MX 记录所指向邮件服务器的 IP 与发信 IP 一致，则判定通过，会消耗 DNS 查询次数。
include:	引入第三方域名的 SPF 记录继续评估，例如 include:_spf.google.com，是接入第三方发信服务最常用的机制，会消耗查询次数。
exists:	对指定域名做 A 记录查询，只要能解析出任意 IP 即通过，多用于特殊的粒度化策略场景。
ptr:	校验发信 IP 的 PTR 反向解析是否指向目标域名，因查询开销大且结果不稳定，官方已不推荐使用。
redirect=	将整条记录的评估转交给另一个域名的 SPF 记录，常用于多个域名统一维护同一套策略。
exp=	指定一个域名，其 TXT 记录内容可作为 fail 时的解释信息返回，实际部署中使用很少。
all	结束标记，表示对前面所有机制都未匹配的发信来源采取何种处置，必须放在记录末尾。

每个机制前还可以加限定符（qualifier）来指定匹配后的判定结果：+ 表示通过（默认，可省略）、- 表示拒绝、~ 表示软拒绝、? 表示中立。结尾 all 的四种写法对比如下：

写法	含义	严格度	使用建议
-all	Fail，未匹配任何机制的发信 IP 一律拒绝	最高	生产环境推荐，来源盘点完整后应使用此项
~all	SoftFail，未授权来源标记为可疑，但不直接拒收	中	部署初期的观察期使用，确认无漏配后收紧
?all	Neutral，对未匹配来源不表态	低	仅建议在测试阶段使用
+all	Pass，允许任何 IP 代表该域名发信	无（等于关闭 SPF）	禁止使用，任何人都可仿冒你的域名

如何配置 SPF

为一个新域名配置 SPF 推荐按以下五步进行，顺序不要颠倒：

1. 盘点所有发信来源。列出所有会使用该域名对外发信的系统：自建邮件服务器（如 Postfix、Exchange）、第三方事务邮件与营销邮件服务、办公邮箱（Google Workspace、Microsoft 365、腾讯企业邮箱、阿里企业邮等），以及客服系统、账单系统、监控告警等容易被遗漏的自动化发信点。遗漏合法来源是 SPF 上线后正常邮件被拒的首要原因。
2. 编写 SPF 记录。把固定的自建服务器出口 IP 写成 ip4:/ip6: 机制，把第三方服务写成其官方文档提供的 include: 机制，最后以 all 收尾。初次上线建议先用 ~all，观察一段时间确认无正常来源漏配后再改为 -all。
3. 在 DNS 服务商添加记录。登录域名所在的 DNS 控制台，新增一条 TXT 类型记录：主机记录填写 @（代表根域名，部分服务商要求填写完整域名或留空），记录值粘贴完整的 v=spf1 字符串。一个域名只能存在一条 SPF 记录。
4. 等待 TTL 生效。新记录的传播速度取决于 TTL 设置与各地递归 DNS 的缓存，通常几分钟内可见，也可能需要数小时。计划变更前可先将 TTL 临时调低（如 300 秒），切换完成后再调回。
5. 在线验证。记录生效后，使用 SPF 检查工具输入域名查看解析结果，确认记录唯一、语法正确、包含全部预期来源且 DNS 查询次数未超限；随后发出一封测试邮件，通过 邮件头分析确认收件方给出的 SPF 判定为 pass。

主流邮箱服务商 SPF include 示例

接入第三方邮箱或发信服务时，一般只需在记录中包含服务商指定的 include 域。常见服务商的 SPF 配置如下表：

服务商	SPF 记录
Google Workspace（Gmail 企业版）	v=spf1 include:_spf.google.com ~all
Microsoft 365 / Outlook	v=spf1 include:spf.protection.outlook.com ~all
腾讯企业邮箱	v=spf1 include:spf.mail.qq.com ~all
阿里企业邮	v=spf1 include:spf1.dm.aliyun.com -all
SendGrid	v=spf1 include:sendgrid.net ~all
Mailchimp	v=spf1 include:servers.mcsv.net ~all

提示：各服务商的 include 域名可能随其基础设施调整，实际配置时请以服务商官方文档给出的 SPF 值为准。同时使用多个服务时，把多个 include 合并进同一条记录，并留意整条记录触发的 DNS 查询次数不要超过 10 次上限。

完整 SPF 记录示例

下面给出三个典型场景的完整记录，可直接对照修改后使用。

场景一：只有一台自建服务器发信，授权单个固定 IP，其余来源全部拒绝：

# 仅允许自建服务器 203.0.113.10 代表本域名发信
v=spf1 ip4:203.0.113.10 -all

场景二：全站使用 Google Workspace 发信，不保留自建服务器，观察期使用 ~all：

# 授权 Google Workspace 的发信服务器集群
v=spf1 include:_spf.google.com ~all

场景三：自建服务器与两个第三方服务并存，所有来源写进同一条记录并以 -all 收紧：

# 多来源组合：自建服务器固定 IP + Google Workspace + SendGrid
# ip4 不消耗 DNS 查询次数，两个 include 各引入一次查询
v=spf1 ip4:203.0.113.10 include:_spf.google.com include:sendgrid.net -all

SPF 的 10 次 DNS 查询上限

SPF 规范要求收件方在评估一条记录时最多执行 10 次 DNS 查询。include 的嵌套展开以及 mx、ptr、exists 机制都会消耗查询次数，大型服务商的 include 内部往往还会再嵌套两三层；一旦查询总数超过 10，收件方会直接返回 permerror，其效果等同于该域名完全没有配置 SPF。而 ip4:、ip6: 是字面量匹配，不产生任何 DNS 查询。

规避查询超限的建议：一是定期清理不再使用的 include，接入新服务前先用 SPF 检查工具统计当前查询次数；二是在查询次数紧张时，请服务商提供经过扁平化（SPF flattening）的记录，或使用支持自动扁平化的 DNS 服务；三是不要为了省查询而手动把 include 替换成服务商当前的 IP 段——这些地址池经常变动，IP 一变化就会导致正常邮件大面积认证失败。

SPF 常见错误

以下错误在实际部署中出现频率最高，配置时请逐项排查：

• 同一域名存在多条 SPF TXT 记录。两条以 v=spf1 开头的 TXT 记录会直接导致 permerror，必须把所有来源合并进同一条记录。
• 漏写 v=spf1 版本标识。没有版本标识的 TXT 记录不会被当作 SPF 记录解析。
• 结尾使用 +all。这等于显式放行互联网上的任何人，SPF 防护完全失效，比不配置更具迷惑性。
• 长期停留在 ~all 不敢收紧。softfail 只是过渡手段，观察期结束后应及时改为 -all，否则未授权来源几乎不会受到实质拦截。
• 误以为 SPF 能校验 From 显示地址。SPF 只校验 Return-Path 域名，显示地址仿冒要靠 DMARC 的对齐（alignment）要求来约束，必要时让 SPF 或 DKIM 与 From 域名对齐。
• TTL 尚未生效就反复修改。查询到旧记录并不代表配置失败，应先用 DNS 查询工具确认各地解析状态，避免在缓存窗口内来回变更造成混乱。

SPF 与 DKIM、DMARC 的关系

SPF、DKIM、DMARC 是邮件认证的三件套，缺一不可：SPF 解决“发送 IP 是否被授权”的问题，DKIM 通过数字签名保证邮件内容在传输中未被篡改，DMARC 则告诉收件方当 SPF 与 DKIM 都无法与 From 域名对齐时应如何处置（none、quarantine 或 reject），并提供聚合报告供域名所有者回溯仿冒情况。建议在 SPF 验证通过后继续完成 DKIM 签名与 DMARC 策略部署，按 DMARC 部署指南 从 p=none 观察逐步收紧到 p=reject。配置完成后，可以用 DMARC 检查工具确认策略记录，用 邮件头分析工具查看真实邮件的 SPF/DKIM/DMARC 认证结果。