邮件送达率
解决 SPF PermError：如何合并两条企业邮箱 TXT 策略
当同一域名的两条 SPF TXT 策略导致 PermError 时，先核实所有实际发信服务，再合并授权项并验证 DNS 和真实邮件。
为什么两条 SPF TXT 策略会报错？
接入新的发信工具后若部分收件方拒信，请查看同一 DNS 主机名下是否有两条以 v=spf1 开头的策略。RFC 7208 规定选出多条 SPF 时返回 permerror，这不表示其他用途的 TXT 也只能有一条。PermError 也不代表所有收件方必定拒信，还需检查实际投递结果。
找到被检查的域名和 DNS 管理处
从退信或认证结果中找出 SPF 实际检查的 MAIL FROM 域名，它可能不同于可见的 From 地址。到当前权威名称服务器所指向的 DNS 平台，查询该主机名下的 TXT。区分根域名和子域名，统计 v=spf1 的条数，并在修改前备份原值及测试结果。
删除前先盘点发信服务
除了公司邮箱，报价工具、订单通知和通讯邮件也可能使用同一域名。直接删除其中一条策略可能让仍在使用的服务失去认证。逐一记录发信路径、负责人、上次使用时间、发信域名和供应商当前推荐的 SPF 值，再与实际发信记录核对。
将授权发信方合并进一条策略
不要直接拼接两条完整的 SPF 字符串。开头只保留一次 v=spf1，核对需要的 include 或 ip4，结尾只保留一个 ~all 或 -all。示例 v=spf1 include:_spf.google.com include:sender.example ~all 仅展示结构，sender.example 并非真实供应商值，必须换成自身供应商提供的准确内容。专用子域名的策略也不要与根域名混淆。
同时检查 DNS 查询上限
即使合成一条，include、a、mx 等会触发查询的项目过多也会出现另一种 PermError。RFC 7208 将评估中的此类项目限制为十次。先移除不再使用的发信工具，再依据供应商文档和真实使用记录决定保留项。盲目固定 IP 或平铺记录可能错过供应商之后的服务器变更。
分别验证公开 DNS 与实际发信
DNS 管理界面显示保存成功并不等于完成。重新查询权威公开 DNS，确认该名称下只有一条 SPF。传播后，从人工邮箱和交易通知等每条发信路径向外部邮箱发送测试邮件并查看 SPF 结果。SPF 通过不保证 From 域名对齐、DKIM 或 DMARC 通过。可以继续参照 Gmail 550 指南和域名邮件诊断工具，但真实域名配置仍须与供应商最新文档核对。
关键不是一行文字，而是清楚的发信责任
确认准确名称下只有一条 SPF、所有现用发信服务都已包含，并且各路径测试通过后，才能稳妥结束排错。下次更换服务时先更新现有策略和负责人清单，不要再加一条 SPF。相关参考包括 Gmail 550 认证排查指南、域名邮件诊断工具和 RFC 7208 的记录选择规则。