要点速览
- 每次 DNS 变更后，使用 SPF 检查工具确认记录可见，并指向正确的发送服务。
- 规范的 SPF 记录在一个域名下应只有一条
v=spf1TXT 值，而不是多条相互冲突的 SPF 记录。 - 如果缺少 SPF，请使用 SPF 生成器生成记录，然后在大量发送前检查 DKIM 和 DMARC。
发布 SPF 后还应检查什么
SPF 错误通常发生在团队新增了发件服务却忘记更新 DNS，或两个服务商各自要求添加 SPF 记录且都被发布时。邮箱服务商要求每个域名只有一条 SPF 记录。如果有两条以v=spf1开头的记录，即使每条单独看都合理，SPF 也可能验证失败。
输入域名后，查看原始记录及其中的机制。include:机制通常指向外部发送平台。ip4:和ip6:用于授权固定的发送基础设施。mx授权该域名的邮件交换服务器。末尾的策略（通常为-all或~all）告诉接收方应如何严格对待来自未列出系统的邮件。
如果检查工具未找到 SPF 记录，不要以为该域名已可以发信。请使用 SPF 记录生成器创建记录，将其发布为 TXT 记录，并在 DNS 生效后再次测试。如果记录存在但缺少某个合法平台，请在启动活动前添加该发件服务。
请使用确切的发信域名，而不是网站 URL。如果通过子域名发信，请检查该子域名本身。
确认每个邮件平台都已包含在内，并删除重复或过时的条目。
在向大量受众发送之前，检查 DKIM、DMARC 和列表质量。
每次变更发件服务都应检查 SPF
任何新的邮件服务都可能改变您的身份验证配置。新闻简报平台、CRM、客服系统、电商通知应用或销售发信序列工具都可能以您的域名发信。出现这种情况时，应同时检查 SPF 以及 DKIM 和 DMARC。这样可以在各邮箱服务商之间保持一致的发件人身份。
SPF 并不能证明地址列表是干净的。如果您正在准备发布，也请验证收件人。使用邮箱健康检查进行域名层面的检查，使用批量验证工作流处理较大的 CSV 列表。身份验证让邮件获得信任；列表清洁则帮助控制退信和负面互动。
活动前的 SPF 操作清单
在向大型列表发送之前，检查发信域名以及所有专用子域名。确认只有一条 SPF 记录、所有在用的发件服务都已列出，且已删除不再使用的服务商。如果 CRM 或营销平台通过品牌子域名发信，请单独检查该子域名，不要默认根域名已覆盖它。
接下来，将 SPF 记录与实际的活动发送路径进行对比。如果活动通过销售互动平台发送，该平台需要获得授权；如果产品通知通过事务邮件服务商发送，该服务商也需要获得授权。保持这份清单的更新，可以避免团队更换工具时在最后关头出现送达率问题。
最后，检查收件人列表。SPF 告诉邮箱服务商您的发件人已获授权，但不会从导出数据中删除无效地址。对于 CRM、新闻简报或潜在客户列表，请在发送前验证文件，并在活动结束后复查退信结果。退信率低于 3% 属于健康，3-5% 需要清理，高于 5% 属于高风险。
对于共用域名，请将这份清单纳入发件服务的接入流程。当销售、营销、支持和产品团队都使用同一个品牌域名时，一个被遗忘的发件服务就可能影响所有人。在发布前花几分钟检查 SPF，远比活动发出后再诊断身份验证失败划算。
SPF 检查工具常见问题
为什么我的域名显示没有 SPF 记录？
可能是 SPF 记录尚未发布、位于其他子域名，或尚未生效。请检查确切的发信域名，并确认 TXT 记录以 v=spf1 开头。
SPF 中的 include: 是什么意思？
include 机制用于授权另一个域名的 SPF 策略。邮件服务通常会用到它，这样您无需手动列出每个 IP 地址，就能授权其发送基础设施。
SPF 使用 ~all 不好吗？
不一定。软失败在测试阶段很有用，但成熟的配置通常会在所有合法发件服务都已包含并检查后，改用 -all。
仅靠 SPF 能防止伪造吗？
SPF 有帮助，但单靠它还不够。需要 DKIM 和 DMARC 将身份验证结果与可见的发件人（From）域名及策略处理关联起来。