How to Fix SPF, DKIM, and DMARC After Switching Email Providers

You switched email providers. Now something isn't working. Maybe your DMARC reports are showing failures. Maybe some emails aren't arriving. Maybe everything looks fine but you got a report from a user saying something went dark.

Email provider migrations break authentication more often than not. The reason is simple: your new provider sends from different IP addresses and uses different DKIM selectors. Your old DNS records point to the old infrastructure. Until you update them, your emails authenticate against infrastructure that isn't sending them anymore.

Here's how to fix it, in the right order.

Why Email Provider Migrations Break Authentication

When you send email, receivers check two things:

1. SPF — is the sending IP in your DNS record's allow list?
2. DKIM — does the signature on the email match a public key in your DNS?

Both of these point to your provider's infrastructure. When you switch providers, those pointers stop pointing to anything that sends your email. SPF starts failing because the new provider's IPs aren't in your old record. DKIM fails because the new provider signs with a key your DNS doesn't have.

The fix is to update your DNS records to point to the new infrastructure. But the order matters, and so does the timing.

Step 1 - Update SPF First

SPF is the most impactful and the easiest to fix. Your new provider gives you an SPF mechanism - usually an include: statement pointing to their sending infrastructure.

v=spf1 include:_spf.newprovider.com ~all

Add this to your existing SPF record. Don't delete the old provider's include: yet - keep both during the transition. Having an extra include that points to infrastructure you're no longer using is harmless. Removing an include that points to infrastructure you're still using breaks things.

Once you've added the new include, wait a few minutes for DNS to propagate, then test:

nslookup -type=TXT yourdomain.com

Confirm your SPF record now includes the new provider. Then send a test email and check your DMARC report - SPF should pass for your new provider's infrastructure.

Step 2 - Add DKIM from the New Provider

Your new provider gives you a DKIM selector and public key. The selector is usually something like newprovider._domainkey.yourdomain.com. You add this as a TXT record in your DNS.

Do not delete your old DKIM record during the migration. Keep both active. The old DKIM key will stop being used as soon as your new provider starts signing, but it causes no harm while it sits in DNS.

The new DKIM record looks like:

newprovider._domainkey.yourdomain.com  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA..."

Add this, wait for propagation, then test: send an email from your new provider and check the email headers. You should see a DKIM-Signature header with your new selector in it (s=newprovider), and DMARC reports should show DKIM passing for your domain.

Common mistake: using the wrong selector name. Your provider tells you the selector - it might be s1 or default or something they define. Use exactly what they give you. A wrong selector means the signature doesn't match your DNS record and DKIM fails.

Step 3 - Keep DMARC at p=none During the Transition

Do not change your DMARC policy during the migration. Keep it at p=none.

This means: if something fails authentication, nothing gets blocked. You want that. During the transition, it's normal for some emails to still fail while old infrastructure gets phased out and new infrastructure gets validated.

Once both SPF and DKIM are confirmed working for the new provider, and you're seeing consistent passes in your DMARC reports, then - and only then - consider moving to p=quarantine or p=reject.

Common Migration Mistakes That Break Email

Deleting old DNS records before validating new ones. This is the most common cause of migration-related email failure. Keep everything active until you've confirmed everything works. Then clean up old records one at a time.

Forgetting that some providers use subdomain selectors. Not all DKIM records go on the apex domain. Some providers use selector._domainkey.yourdomain.com and some use selector.yourdomain.com for the subdomain. Your provider tells you where to put it. If your DNS provider has restrictions on subdomain creation, this can be a blocker.

Assuming DNS propagation is instant. DNS changes can take anywhere from a few minutes to 48 hours. The theoretical maximum is 72 hours, though it's usually faster. Don't test from the same DNS resolver that's cached your old records - use a DNS lookup tool or a different network.

Not monitoring during transition. "It seems fine" isn't good enough. Check DMARC reports every day during migration. You want to see that SPF and DKIM are consistently passing before you move to enforcement.

How Long to Wait Before Enforcing DMARC After Migration

The safe minimum is two weeks at p=none after you've confirmed both SPF and DKIM are passing. Four weeks is better if your email volume is low or you have a complex multi-sender setup.

The reason for waiting: some senders only appear in reports periodically. A quarterly billing system might only send once a quarter - if you only monitor for three days, you'll miss it. Four weeks of data covers most periodic sending patterns.

The data you're looking for before moving to enforcement: consistent SPF pass, consistent DKIM pass, zero unexpected failures from sources you don't recognize. If you see anything unfamiliar in the reports, investigate it before you enforce.

How to Tell If Your Migration Was Successful

1. DMARC reports show SPF pass for your new provider's IPs - confirm the sending IPs in the report match your new provider's range
2. DMARC reports show DKIM pass with your new selector - the selector value in the DKIM signature should match your new DNS record
3. No unexpected failures - any authenticated source that isn't your new provider needs to be investigated before you enforce
4. No user complaints about missing email - this is your real-world test; users notice email failures faster than reports do

The cleanest way to get this visibility quickly: use a tool that aggregates DMARC reports and summarizes them by domain and result, rather than reading raw XML. You'll see the summary in minutes instead of spending an hour parsing individual reports. We tested DMARCFlow for this and found it turns each aggregate report into a readable per-source view: sending IP, message count, DKIM and SPF results side by side, and which signing domain was used. Instead of opening the raw XML and matching IPs against your provider's documentation, you see at a glance which sources are aligned and which are failing - which is exactly what you need during a migration when you're checking whether the new provider is authenticating cleanly.

FAQ

Should I remove the old SPF include immediately after migration? No. Remove it only after you've confirmed all your email is sending through the new provider and old infrastructure is fully retired. Premature removal breaks email for anyone still routing through the old system.

What if my new provider doesn't provide DKIM? Some transactional email providers don't offer DKIM signing. In that case, you can only use SPF for authentication, and your DMARC policy options are more limited. Ask the provider - if they can't sign DKIM, they may not be suitable for sending from your domain at scale.

Can I run two email providers simultaneously during a migration? Yes - this is actually the recommended approach. Run both in parallel for a short period, with both sets of SPF includes and both DKIM selectors active. Once you've validated everything from the new provider works, retire the old setup.

My DMARC report shows DKIM failing for some emails - should I be worried? Depends on the source. If it's your new provider's IPs and DKIM selector, investigate the DNS record - a typo in the DKIM TXT value is the most common cause. If it's from a source you don't recognize, it could be someone spoofing your domain, which is exactly what DMARC is supposed to catch.