要点速览
配置 SPF 记录
-all（硬失败）
适合大多数配置。未在 SPF 记录中列出的服务器会被标记为身份验证失败。
~all（软失败）
来自未列出服务器的邮件会被接收但会被标记。适合在采用严格策略前测试新的 SPF 记录。
查询次数上限
SPF 记录最多允许 10 次 DNS 查询，超出会导致验证失败。使用此工具确保不超出限制。
如何创建不会误伤正常邮件的 SPF 记录
SPF 记录是位于域名根部的 TXT 记录，告诉接收方邮箱哪些系统获准代表该域名发送邮件。这份清单通常包括用于团队邮件的 Google Workspace 或 Microsoft 365、用于新闻简报的邮件服务商、用于收据和密码重置的事务邮件服务，有时还包括 CRM 或销售互动平台。
创建 SPF 最稳妥的方法，是在改用硬失败策略之前盘点所有发送来源。请检查邮件服务商、CRM、客服系统、计费系统、产品应用，以及任何使用同一域名或子域名发信的陌生客户外联工具。如果某个发件服务未包含在 SPF 中，邮箱服务商可能会将原本合法的邮件视为未经验证。
SPF 还有一个实际限制：诸如 include:， a， mx， exists，以及redirect等机制会触发 DNS 查询，而 SPF 评估最多只允许 10 次 DNS 查询。一条看似整洁但超出该限制的记录，可能在邮箱评估时失败。请保持记录精简，避免重复的 include；当不同团队或工具需要独立的发信配置时，使用专用子域名。
汇总所有以您域名发信的服务，包括日常邮件、新闻简报、应用通知、发票和销售工具。
添加所需的 IP 和 include 域名，选择失败策略，然后复制生成的 SPF 值。
发布记录，等待 DNS 生效，然后使用 SPF 检查工具和 DMARC 检查工具确认结果。
SPF 与 DKIM、DMARC 及列表质量的关系
SPF 必不可少，但它并不是送达率配置的全部。 DKIM 为邮件签名，让接收服务器能够确认邮件在发出后未被篡改。 DMARC 告诉邮箱服务商当 SPF 或 DKIM 与可见的发件人（From）域名不一致时该怎么处理。这些记录共同帮助邮箱服务商判断邮件是否经过授权。
身份验证并不能让质量差的列表变得安全。如果发往过时、拼写错误或有风险的地址，即使身份验证通过，退信率和投诉信号仍会损害发件人信誉。对于营销活动和 CRM 导出数据，请在发送前先使用免费邮箱验证工具或批量验证对列表进行验证。退信率低于 3% 属于健康；3-5% 需要清理和复核；高于 5% 对发信域名而言属于高风险。
对于有多个发件服务的团队，请在发布变更前记录每个 include 的负责人。这样在移除服务商、新增子域名或发送平台更改推荐的 SPF include 时，后续审查会更轻松。
SPF 生成器常见问题
SPF 记录应该发布在哪里？
将生成的值作为 TXT 记录发布在发信域名的根部，例如 example.com。如果通过子域名发信，请将 SPF 记录发布在该子域名上。
应该使用 -all 还是 ~all？
当您确信记录已包含所有合法发件服务时，使用 -all。在梳理或迁移期间使用 ~all，因为它在配置阶段向邮箱服务商发出较温和的信号。
一个域名可以有多条 SPF 记录吗？
不可以。一个域名应只有一条 SPF TXT 记录。如果存在多条 SPF 记录，接收服务器可能返回永久性错误。请将所有发件服务合并到一条记录中。
配置了 SPF 后还需要 DKIM 和 DMARC 吗？
需要。SPF 授权发件服务，DKIM 为邮件签名，DMARC 将身份验证与域名策略关联起来。三种记录协同工作，才能获得现代邮箱服务商的信任。