SPF broke after switching email provider
The new provider’s wizard said “add this TXT record”, and you did, next to the old one. Two records starting v=spf1 on the same domain make a receiver return PermError, and a PermError means your SPF authorises nobody, including the provider you’ve moved to. So the first move is to ask your authoritative nameservers what they publish, count the strings that start v=spf1, and only then merge down to the one record the standard allows.
Two records where the standard allows one
RFC 7208 section 3.2 permits exactly one v=spf1 record per domain. A receiver that finds two or more must return PermError, the error result prescribed in section 4.5, rather than guess which record is authoritative. PermError voids SPF entirely: the receiver applies neither the old record nor the new one, and evaluates your mail as though you’d published no SPF at all.
There’s no grace period in the standard. Two v=spf1 records are a PermError from the moment the second one exists, which is the moment you pasted the wizard’s value in. The migration-safe pattern is one record carrying both providers’ includes through the overlap, and the rest of this page is how to get there.
DMARC treats an SPF PermError as a fail on the SPF leg, so alignment then rests on DKIM alone. If the new provider’s DKIM isn’t published yet, the domain is sending unauthenticated at the moment the infrastructure changed, which is also the moment receivers have the least history to trust you on.
Ask the authoritative nameservers first
A checker tells you the symptom. The zone tells you the cause, and the zone lives at whichever nameservers are authoritative for your domain today, which may or may not be the ones your DNS panel belongs to. Find them, then query one of them directly:
dig +short NS yourdomain.com
dig +short TXT yourdomain.com @<nameserver>Count the strings starting v=spf1. The only safe count is 1. If you see two, you’ve found the cause and can skip the rest of the diagnosis. If you see one and mail is still failing, the leftover is something else, and the table below covers what else it can be.
The scan reads the same live DNS and reports multiple SPF records, a missing include or a DKIM gap in one pass, which is worth doing before you edit anything, because a migration rarely leaves exactly one thing behind.
What the migration left behind
Five leftovers account for post-migration SPF failures. Check them in this order, because the first one masks the others.
| What got left behind | What you see | The fix |
|---|---|---|
The old SPF record, still in DNS next to the new one (two v=spf1 records) | Checkers report multiple SPF records or PermError; SPF stops working entirely | Merge into one record, delete the rest |
The old provider’s include: still inside your one record | SPF works, but you’re wasting DNS lookups and the old provider’s servers can still send as you | Remove it once mail has drained from the old system |
The new provider’s include: never added | Mail from the new provider fails SPF at receivers | Add it to the single existing record, never as a new record |
| DKIM selectors not created for the new provider | dkim=fail, or signatures from the provider’s default domain; DMARC has no second leg | Publish the new selectors |
| The record updated only at the old nameservers | Different answers depending on who you ask; intermittent failures | Edit the zone at the authoritative nameservers; verify both sets during cutover |
The first row is the one that hides the other four. While two records exist, the receiver isn’t reading either of them, so a missing include or a wrong qualifier inside one of them produces no separate symptom until you’ve merged.
Merge to one record, then delete the rest
One record, starting v=spf1, containing the new provider’s include and any other sender you still use (invoicing tool, CRM, newsletter platform), and one terminal -all or ~all. During the overlap the old provider’s include stays in, after the new one. Later, once the old system has stopped sending, it comes out.
Before: "v=spf1 include:spf.oldprovider.example ~all"
"v=spf1 include:spf.newprovider.example -all"
After: "v=spf1 include:spf.newprovider.example include:spf.oldprovider.example -all"
Later: "v=spf1 include:spf.newprovider.example -all"Merging without deleting fixes nothing, because the PermError comes from the count. Publish the merged record, then remove each other v=spf1 string at the same nameservers, and query again until the count is 1.
A merge is a decision about what to keep, and it isn’t a concatenation of both records’ mechanisms. SPF caps a record at ten DNS lookups, and each include: spends lookups against that cap. Of the 150,103,209 domains publishing SPF in the September 2026 census (of the 316,600,902 graded or dead), 7,408 have blown the lookup cap and voided SPF that way. A record that has swallowed two providers plus each tool anyone ever signed up for is how a domain joins them.
Drain the old provider before you drop its include
Keep the old provider’s include only while the old system still sends. Scheduled reports, an old CRM connector, a forgotten mailbox: each of those keeps producing mail with your domain in the Return-Path until someone turns it off, and each one fails SPF the day you remove the include ahead of it.
Watch the Return-Path of anything still arriving through the old system. When that traffic stops, remove the include and query the record again. A stale include leaves the old infrastructure permitted to send as you, which is a permission you meant to revoke when you left, and it keeps spending lookups you may want back.
DKIM, and the domain SPF checks
Publish the new provider’s DKIM selectors as part of the cutover, and keep the old selectors published until every message signed with them has been delivered and any forwards have settled. Mail in transit at the moment you delete a selector arrives with a signature nothing can verify. If you’re unsure which selectors the old provider used, find your DKIM selector walks the headers.
Receivers evaluate SPF against the Return-Path (RFC5321.MailFrom) domain, the bounce address, and pay no attention to the From header your recipients read. After a migration this matters twice. The new provider may use its own bounce domain until you configure a custom one, so SPF passes on a domain that isn’t yours, and a pass on someone else’s domain won’t align for DMARC. The fix for that is the new provider’s DKIM, signed with your domain.
DMARC, and a rebrand at the same time
A provider switch doesn’t change the DMARC record itself, because that record names your reporting address and your policy, and neither mentions a provider. The DMARC results do change: expect a dip in the aggregate reports during cutover, and confirm both legs pass on the new provider before tightening policy. What a report line looks like when one leg passes and the other doesn’t is covered under DMARC.
Changing the domain as well as the provider is two jobs. The new domain needs SPF, DKIM and DMARC from day one, since it has no history at receivers and inherits none from the old name. The old domain stays authenticated for as long as forwarding or reply traffic runs through it, and gets explicitly locked down once it’s parked. An old domain abandoned with half-broken SPF is a spoofing target wearing your former name.
Verify at the source, then let the caches catch up
Once the count is 1 at an authoritative nameserver, the fix is done, and a checker that still shows the old record is reading a cache. DNS resolvers honour the record’s TTL, and if the nameservers changed as part of the move, some resolvers are still querying the old set until the registrar delegation has propagated. Query both sets directly and compare:
dig TXT yourdomain.com @old-ns
dig TXT yourdomain.com @new-nsIf the answer is right at the authoritative nameservers, the caches will catch up on their own and there’s nothing further to publish. If the two sets disagree, fix the zone at whichever set is still answering for you, because receivers will keep asking it until delegation completes.
When both sets agree and one TTL has passed, run the scan again and confirm SPF shows a single valid record with a pass, DKIM shows the new selectors, and DMARC reports both legs aligned. The record you could see in the panel wasn’t the problem; the count was, and you’ve now verified it at the only place that counts. The rest of the SPF page covers the qualifier and lookup decisions that come next.
Figures as of 5 September 2026, from the September 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.