Merge SPF records
How it works
Collect
Paste records, or fetch the domain's — if it has more than one, the merge runs immediately because that domain is failing SPF right now.
Merge
Every mechanism is pooled, duplicates removed, redirect= converted to include:, +all dropped, and the rest ordered ip4, ip6, a/mx, include.
Count
Includes are expanded recursively and the DNS lookups counted against the limit of ten, the same way a receiver does it.
Publish
One record, ready to copy, with the split shown if it is over 255 characters and the notes on what to delete.
Why two records is worse than none
RFC 7208 is explicit: a domain with more than one TXT record starting with v=spf1 gets a permanent error. Receivers do not pick the first one or merge them; they treat SPF as failed for every message. This is not a soft signal — under a DMARC policy it means every message that relied on SPF alignment fails DMARC too. And it is common, because every service you add says "add this SPF record" and a second TXT record is the obvious thing to add. Half the SPF faults I find on client fleets are this one.
What merging involves
Pool every mechanism, drop the duplicates, and put them in an order that helps: ip4 and ip6 first because they cost nothing, then a and mx, then the includes. Choose one all — the strictest of the sources by default, since a record that ended in -all was presumably meant to. Convert any redirect= to an include, because redirect only works alone. Then count the lookups, because the reason the records were separate is often that someone hit the limit and gave up.
The ten-lookup limit
Every include, a, mx, ptr, exists and redirect costs one DNS lookup, and includes cost their own includes recursively. Google Workspace alone is one; Microsoft 365 is one; a sending tool, a CRM, a helpdesk and a marketing platform take the rest, and the record is over the limit before anyone noticed. The tool counts the merged record the way a receiver would. If it is over ten, the fix is to remove includes for services that no longer send for you — there are always some — and only then to consider flattening.
After you publish
Delete the other records. All of them. An old record left "just in case" is the permerror all over again. Then wait out the TTL and run the SPF checker from a resolver that has not seen the domain, and send a test message to a Gmail address and read the Authentication-Results header. spf=pass is the only result that means the job is done.
Frequently asked questions
Can I have two SPF records?
No. More than one TXT record beginning v=spf1 is a permerror and SPF fails for every message from the domain. Merge them into one.
Can I split a long SPF record into two TXT records?
Not into two records. If it is over 255 characters, publish it as two quoted strings inside one TXT record — receivers concatenate them. The tool shows the split.
Which all mechanism should I use?
-all if you are confident every legitimate sender is in the record. ~all if you are still discovering senders. With DMARC at p=reject the difference is minor; without DMARC, -all is the only enforcement you have.
Why did the tool convert redirect= to include:?
redirect= replaces the whole record with another domain's and cannot coexist with other mechanisms. In a merged record an include achieves the same lookup.
The merged record is over ten lookups — now what?
Remove includes for services you no longer use. If it is still over, flatten the largest include into its ip4 ranges, and diary a quarterly check because flattened records go stale.
Last reviewed
What to run next
The checks that most often follow this one.
More in this category
Guides that go deeper
When the tools tell you something is wrong
The diagnostics here are free and always will be. When the fix is bigger than a DNS record, this is the work I do.
Deliverability rescue
Mail landing in spam, replies gone quiet, or a domain suddenly blocked. I find the actual cause rather than guessing, and fix it.
- Authentication and alignment failures
- Blocklist delistings and reputation repair
- Gateway and filter-level blocks
- A written report on what broke and why
Email & sending infrastructure
Sending domains, inboxes, authentication and warmup, built to survive volume instead of burning down in a month.
- Domain and inbox fleets at any scale
- SPF, DKIM, DMARC and tracking domains
- Google Workspace — Silver Partner
- Handover documentation you actually own
Domain, DNS & migration
Changing registrar, mail provider or host without a day of downtime or a week of mail silently failing.
- Registrar and nameserver moves
- Workspace and Microsoft 365 migrations
- MX, SSL and subdomain cutover
- Staged rollout with rollback at every step
Monitoring & retainer
Infrastructure drifts. Records get edited, certificates expire, domains get listed. Ongoing eyes on the fleet.
- Scheduled checks across every domain
- Alerts before your clients notice
- Monthly reporting
- Priority response when something breaks
Start with a call
Bring a domain and the symptom. I will tell you what is actually wrong and whether you need me at all — plenty of people leave that call able to fix it themselves.
Thirty minutes, no pitch
We will run the checks together on your actual domains, and you will leave knowing what is broken, what it takes to fix, and what it should cost. If that is a job you can do in-house, I will say so.