Email deliverability
Fixing SPF PermError: How to Merge Two Company Email TXT Policies
When two SPF TXT policies cause PermError, identify every active sender, merge the authorized mechanisms into one policy, and verify DNS and real mail.
Why do two SPF TXT policies cause an error?
If mail starts failing after a new sending tool is connected, check whether the same DNS owner name has two values beginning with v=spf1. RFC 7208 requires permerror when more than one SPF policy is selected. This does not prohibit unrelated TXT records. A PermError does not mean every receiver must reject every message, so inspect actual delivery as well.
Find the checked domain and its DNS manager
Read the MAIL FROM domain used for the SPF check in a bounce or Authentication-Results header; it can differ from the visible From address. Query TXT at that exact owner name through the service controlling the authoritative nameservers. Distinguish the root from a subdomain, count values starting with v=spf1, and save the current values and test results before editing.
Inventory senders before deleting anything
The mailbox may not be the only sender. Quotation tools, order notifications, and newsletters can use the same domain. Deleting one policy blindly can break a live service. List each sending path, owner, last use, sending domain, and current provider-recommended SPF value, then compare the list with real sending history.
Merge authorized senders into one policy
Do not concatenate two complete SPF strings. Use v=spf1 once at the start, review the needed include or ip4 mechanisms, and place a single ending such as ~all or -all at the end. The sample v=spf1 include:_spf.google.com include:sender.example ~all only illustrates the shape; sender.example is not a real provider value. Replace it with your provider's exact instructions. Do not mix a dedicated subdomain policy with the root policy.
Check the DNS lookup limit
One record can still fail if include, a, mx, and other lookup-producing terms exceed the limit. RFC 7208 limits these terms to ten during evaluation. Remove unused senders first and justify retained mechanisms with provider documentation and actual use. Blind IP pinning or flattening can miss a provider's future server changes.
Verify public DNS and real sending separately
A saved DNS form is not proof. Query the authoritative public DNS again to confirm exactly one SPF policy at the name. After propagation, send test mail from each path, including the human mailbox and transaction alerts, to an external inbox and inspect SPF results. SPF pass does not guarantee From-domain alignment, DKIM, or DMARC. The Gmail 550 guide and domain-mail diagnostic are useful next steps, but confirm live settings against your provider's current documentation.
The real goal is a clear sending inventory
Close the incident only after confirming one policy at the exact owner name, all active senders included, and successful tests from each sending path. When a provider changes, update the existing policy and sender inventory rather than adding another SPF row. Relevant references are the Gmail 550 authentication guide, the domain-mail diagnostic tool, and RFC 7208 record-selection rules.
Start with OfficialMail
Start operating with one official primary mailbox.
Use one primary mailbox as your company's official address and review every domain-connection value directly in the mailbox.