这是给网站交付需求使用的合成教学例，不是客户成果、真实账号测试或认证。
截图换行，不等于DNS记录边界
网站或邮件交接后，截图中可能出现两段SPF文字。关键是：它们属于两条TXT资源记录，还是同一条记录内的两个字符串。混为一谈，可能在“清理”时破坏原本正常的发信配置。
| 所填DNS结构 | 选中的SPF记录数 | 有限结论 |
|---|---|---|
| 两条TXT都以v=spf1开头 | 2 | 选择阶段PERMERROR_MULTIPLE |
| 一条TXT含两段字符串，另有普通验证记录 | 1 | 只完成选择，尚未求值 |
| 只有无关站点验证记录 | 0 | NONE：未提供SPF策略，不代表已查明邮件故障 |
运行填好的例子
下载有限规则Node检查器和已填写输入。使用Node 24或更新版本，不需要账号或API，也不联网。
node checks.mjs spf-record-selection spf-record-selection.json输入用嵌套数组表达边界：外层每项是一条TXT，内层字符串拼成同一条记录。第一组是两条分别含虚构sender-a和sender-b的策略；第二组在-all之前分成两段，并包含一条无关站点验证记录。检查器只数策略记录，不解析include目标、查询上限或发信授权。
安全的交接证据要求
索取准确DNS名称、带时间的RRset导出、约定授权发信方，以及脱敏的服务商配置说明。截图只作辅助；先向DNS负责人确认记录边界，再讨论修改。两个发信服务，不代表应并存两条独立SPF记录。
不能直接用本例自动合并include、删除服务商或覆盖策略。include链还可能有额外限制；成功选中记录，也不代表SPF、DKIM、DMARC全部通过。真实邮件头与收件服务器判断要另行授权测试。
域名均为虚构。资源不查询DNS、不修改邮件，仅检查所填普通小写v=spf1示例的选择阶段，不是完整SPF求值器，也不保证进收件箱。
官方依据与边界
RFC 7208第3.2—3.3节：区分多条SPF记录与同一TXT记录内多个字符串。
来源于2026年10月15日核验。输入与验收规则为原创教学设计；正式实施前还要核对当前平台版本及实际交付合同。