01
先列实际发件方
初始机制表是空的，~all 只是草稿结尾。只有确认服务商提供的 include 域名或 IP 网段后才添加。
- 示例地址用于演示，不能原样当作生产记录发布。
邮件开发工具
SPF 记录生成器
按实际发件来源添加机制，再核对 TXT 文本、顺序与发布前提示。
SPF 记录生成器
尚无发件机制，请只添加已确认的来源。
v=spf1 ~all
可见直接 DNS 查询项：0 / 10
TXT 字节数：11
这不是完整递归查询数；页面不会读取 include 或 redirect 的目标。
有序机制
~all— all · 可执行
仅在浏览器本地处理，不发送 DNS 查询或更新。
结尾与重定向
redirect 会替代 all；先前选择的 all 会保留。
结果已就绪，发布前请查看提示。
发布前核对
- 尚未列出发件来源，此草稿不宜直接发布。
给域名接入新邮件服务时，常见问题不是记不住语法，而是不知道原来的发件来源会不会被新规则漏掉。SPF 记录生成器把每条机制按执行顺序列出来，避免把 include 和 IP 网段当作无序清单。
也可以把已有 TXT 值粘到检查模式。SPF 记录生成器会标出语法位置、不可达机制与已知风险；它只是本地静态检查，完整 DNS 查询预算和线上发布状态仍须另查。
为什么使用 SPF 记录生成器
看清机制顺序，也看清静态检查的范围。
查询数字注明口径
计数只包括当前 TXT 中可见的直接查询项。include 后面的依赖链没有展开，SPF 记录生成器不会把这个数字伪装成真实总查询次数。
先盘点发件来源，再检查结尾
02
按首次匹配顺序排好
上下移动机制会改变 SPF 的判定路径。启用 redirect 后，原来选过的 all 会暂存，但输出只保留 redirect。
- 修改输入或选项后，旧结果立即过期，复制与下载暂时停用。
03
核对警告的适用范围
检查模式可粘贴一条 TXT 值，查看出错字符位置、不可达项和可见直接项数。
- 10 次上限还包括 include 和 redirect 的下游链，本地页面无法展开。
一条记录里的关键行为
有序机制表
include、ip4、ip6、a 和 mx 都可设置限定符，生成的 TXT 保留表单中的先后次序。
旧记录静态检查
SPF 记录检查会保留粘贴的原文，同时做 SPF 语法检查，并核对网段前缀及结尾策略。
查询预算说明
可见直接项数提示顶层记录是否拥挤，并解释它与完整 SPF DNS 查询限制的差别。
本地判断的边界
- 不会读取线上 DNS
- SPF 记录生成器不查询已发布的 TXT，也查不到第二条 SPF 记录或 void lookup；发布后要再做线上核对。
- 超过 255 字节不等于无效
- 一条 DNS TXT 记录可以由多个字符串拼接。不要为了拆分长 SPF TXT 记录而创建两条独立记录。
- 语法正确不保证投递
- 具体 MAIL FROM 域名、发件 IP、DMARC 对齐和收件方策略都会影响结果，静态文本无法证明邮件可送达。
- 缺少结尾只给警告
- 没有 all 或 redirect 时，SPF 隐含 neutral。工具会提示这项策略风险，但不会把它误判为语法错误。
SPF 记录生成器常见问题
什么是 SPF 记录，我的域名为什么需要它？
SPF 记录让收件方检查某个发件 IP 是否获准使用该 MAIL FROM 域名。先盘点实际发件服务，再为域名发布一条 TXT 策略。
记录末尾应该用 ~all 还是 -all？
~all 表示软失败，-all 表示失败。先确认所有合法来源已列出并做线上验证，再决定是否收紧；本页默认 ~all 不是投递保证。
什么是 SPF 的 10 次 DNS 查询限制？
RFC 7208 按一次实际评估路径限制会触发 DNS 的项，嵌套 include 也计入。这里仅展示顶层可见项，不能据此断定总预算通过。
光靠 SPF 能阻止邮件伪造吗？
不能。SPF 检查的是信封域名与发件 IP；可见 From 的对齐仍需结合 DMARC，且收件方还会使用其他判断。
域名上有两条 SPF 记录怎么办？
应在 DNS 控制台合并为同一条 SPF TXT 策略。多条匹配的 SPF 记录会产生永久错误；本地检查无法发现线上重复项。
还有 SPF 策略问题？