SPF Stopped Working After You Switched Email Provider — The Migration Fix (2026)

Objavljeno 2026-07-08

Figures as of 2026-06-29 · methodology v7. Aggregate census data across 261 million graded domains. See how we grade.

SPF usually breaks after an email-provider switch because the new provider’s record was added next to the old one. Two v=spf1 records are a permanent error — SPF voids entirely. 1,013,416 domains — about one in 138 of those that attempt SPF — are in that state, according to the Defaults.Exposed census of 261 million domains. Merge them into one.

The fix takes about ten minutes: scan the domain to see exactly what the migration left behind, list every SPF record at your authoritative nameservers, merge them into a single record that includes only your new provider, and re-verify with dig. This guide walks each step, plus the DKIM and nameserver checks most migrations forget.

Why did SPF break right after the migration?

Because the new provider’s setup guide said “add this TXT record” — and you did, next to the old one. That is the one thing the SPF standard doesn’t allow. RFC 7208 (§3.2, error result prescribed in §4.5) permits exactly one v=spf1 record per domain; a receiver that finds two or more must return PermError rather than guess which is authoritative. PermError means SPF is void: not the old record, not the new one, no SPF at all.

And it doesn’t stop there. DMARC treats a PermError as a fail on the SPF leg, so your mail now depends entirely on DKIM. If the new provider’s DKIM isn’t set up yet either — common mid-migration — you’re sending unauthenticated at exactly the moment you changed infrastructure, which is when receivers scrutinise you hardest.

This is the copy-paste that voids protection when you switch providers, and it is not rare: 1,013,416 domains publish two or more SPF records right now — about one in 138 of the 139 million-strong population that attempts SPF, according to the Defaults.Exposed census of 261 million domains (data as of 2026-06-29). The full numbers on the two-records trap have their own report; this page is the procedural fix.

What did the migration leave behind?

Five leftovers cause almost every post-migration SPF failure. Check them in this order:

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 — steps below
Old provider’s `include:` 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 fully drained from the old system
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 — step 6 below
Record updated only at the old nameservers	Different answers depending on who you ask; intermittent failures	Fix the zone at the authoritative nameservers; verify both sets during cutover

How do I fix it? The migration checklist

Run the free scan at defaults.exposed first. It reads your live DNS and tells you whether you have multiple SPF records, a missing include, or a DKIM gap — diagnose before touching anything.
List every SPF record at the authoritative nameservers. dig +short NS yourdomain.com, then dig +short TXT yourdomain.com @<nameserver> against one of them. Count the strings starting v=spf1. The only safe count is 1.
Merge to a single record. One record, starting v=spf1, containing your new provider’s include and any other sender you still use (invoicing tool, CRM, newsletter platform), one terminal -all or ~all. Example — old Google Workspace, new Microsoft 365, mid-drain:
```
Before:  "v=spf1 include:_spf.google.com ~all"
         "v=spf1 include:spf.protection.outlook.com -all"

After:   "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"
Later:   "v=spf1 include:spf.protection.outlook.com -all"
```
Provider values and DNS-panel quirks are in the setup guides for Google Workspace and Microsoft 365.
Delete the extra records. Merging without deleting fixes nothing — the PermError comes from the count.
Keep the old provider’s include only while the old system still sends — scheduled reports, an old CRM connector, a forgotten mailbox. Once the drain is done, remove it: a stale include leaves the old infrastructure permitted to send as you, and every include costs DNS lookups against SPF’s hard cap of 10 — at least 797,263 domains have voided SPF by blowing that cap (census, 2026-06-29).
Set up the new provider’s DKIM — and don’t delete the old selectors yet. New selectors sign new mail; old selectors must stay published until every message signed with them has been delivered and any forwards settled. Full walkthrough in DKIM failing after switching email tools.
If you changed nameservers too, check both. DNS migrations often ride along with email migrations. Query the old and the new NS set directly (dig TXT yourdomain.com @old-ns and @new-ns) — until registrar delegation fully propagates, some receivers still ask the old servers, so the fixed record must exist at whichever set answers.
Re-run the scan and confirm SPF shows a single valid record with a pass.

Which domain does SPF actually check?

Receivers evaluate SPF against the Return-Path (RFC5321.MailFrom) domain — the bounce address — not the From header your recipients see. After a migration this matters twice: your new provider may use its own bounce domain until you configure a custom one, and SPF “passing” on a domain that isn’t yours won’t align for DMARC. The fix for that is the new provider’s DKIM, signed with your domain.

Migrating and rebranding at the same time?

Changed the domain as well as the provider? Treat them as two jobs. The new domain needs the full stack — SPF, DKIM, DMARC — from day one; use the new-domain email checklist. The old domain stays authenticated for as long as forwarding or reply traffic runs through it, and gets explicitly locked down (not just abandoned) once it’s parked. An old domain with leftover, half-broken SPF is a spoofing target wearing your former name.

Frequently asked questions

Can I keep two SPF records while I migrate? No. There is no grace period in the standard — two v=spf1 records are a PermError from the moment the second one exists, and 1,013,416 domains are sitting in that state as of the census (2026-06-29). The migration-safe pattern is one record carrying both providers’ includes during the overlap.

How long should I keep the old provider’s include? Until nothing sends through the old provider — typically the length of your overlap window, days to a few weeks. Watch the Return-Path of anything still arriving via the old system; when that traffic stops, remove the include and re-check your lookup count.

Why does a checker still show my old record after I fixed it? DNS caching honours the record’s TTL, and if your nameservers changed, some resolvers still query the old set. Verify directly at the authoritative nameservers with dig TXT yourdomain.com @<ns> — if the answer is right there, the fix is done and the caches will catch up. If it’s wrong at one NS set, see ‘SPF record not found’ — the real causes.

Do I need to change DMARC when I switch provider? Usually not the record itself — it names your report mailbox and policy, not your provider. But your DMARC results depend on the SPF and DKIM you just migrated: expect a dip in reports during cutover, and confirm both legs pass before tightening policy. Start at fix SPF if the scan shows the SPF leg still failing.

Send the owner the report

If you’re doing this migration for a client, finish with evidence. Re-run the free scan once the merge is live and forward the graded report to the business owner: SPF, DKIM and DMARC passing on the new provider, in plain language, dated. That’s the artefact they file for the cyber-insurance renewal and the next supplier security questionnaire — proof the migration left the domain better authenticated than it started.

Check your domain → · DKIM failing after switching email tools → · ‘SPF record not found’ — the real causes → · How we grade → · Aggregate data only. Data stored and processed in the EU.