Updating Your SPF Record When Switching Email Providers
Step-by-step guide to updating your SPF record when migrating email providers. Avoid deliverability gaps with a safe parallel-running approach.
You're switching email providers. Maybe you're moving from Google Workspace to Microsoft 365, swapping Mailchimp for Klaviyo, or migrating your transactional email from SendGrid to Postmark. The migration plan covers mailbox setup, data transfer, and DNS changes -- but one critical step often gets missed or done in the wrong order: updating your SPF record.
Get the SPF update wrong and you'll have a gap where some or all of your email fails authentication. Order confirmations bounce, marketing campaigns hit spam, and your team's emails get flagged. This guide walks you through the safe way to update SPF during a provider migration.
The Golden Rule: Add Before You Remove
The most important principle of SPF migration is this: add the new provider's include before you start sending through them, and don't remove the old provider's include until you've completely stopped sending through them.
During the transition period, your SPF record will contain both providers. That's not just okay -- it's required. If you remove the old provider too early, emails still flowing through the old system will fail SPF. If you add the new provider too late, emails from the new system will fail SPF.
v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all
This example shows a domain mid-migration from Google Workspace to Microsoft 365. Both providers are authorized simultaneously until the migration is complete.
Never remove the old provider's SPF include on the same day you switch over. Emails can remain queued for hours or even days. Wait until you're certain no messages are still being sent through the old provider.
The Migration Timeline
A safe SPF migration follows a specific sequence. Rushing through these steps or skipping the parallel-running period is how deliverability gaps happen.
Check your current SPF record
Before making any changes, document your existing SPF record and its lookup count. Use SPF Record Check to get a baseline. Note every include mechanism and what service it belongs to.
Add the new provider's include
Add the new provider's SPF include to your existing record. Do this before you start sending any email through the new provider. Use the free SPF record generator to build the updated record with both providers included.
Verify the updated record
After DNS propagation, check the record with SPF Record Check. Make sure the record is valid and the total lookup count is within the 10-lookup limit. Having both providers temporarily may push you close to the limit -- that's fine for the transition period.
Begin sending through the new provider
Start your migration. Move mailboxes, update sending configurations, redirect email flows. During this phase, both the old and new providers are actively sending email from your domain, and both are authorized by your SPF record.
Confirm the migration is complete
Verify that all email is flowing through the new provider. Check that no messages are still being sent through the old service. Look at your email headers, provider dashboards, and sending logs to confirm.
Wait 48-72 hours
Even after the migration looks complete, wait two to three days. Emails can sit in retry queues, scheduled sends might still be configured on the old platform, and some edge cases (like forwarded messages) might still reference the old provider.
Remove the old provider's include
Once you're confident no email is being sent through the old provider, remove its include from your SPF record. Verify the updated record one more time.
Common Migration Scenarios
Google Workspace to Microsoft 365
Before migration:
v=spf1 include:_spf.google.com -all
During migration (both active):
v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all
After migration:
v=spf1 include:spf.protection.outlook.com -all
This migration temporarily uses 5-7 DNS lookups during the parallel period. If you have other includes in your record, check that you stay within 10 total lookups. If you're over the limit temporarily, consider using the subdomain approach to give yourself more headroom.
Mailchimp to Klaviyo
Before migration:
v=spf1 include:_spf.google.com include:spf.mandrillapp.com -all
During migration:
v=spf1 include:_spf.google.com include:spf.mandrillapp.com include:spf.klaviyo.com -all
After migration:
v=spf1 include:_spf.google.com include:spf.klaviyo.com -all
SendGrid to Postmark
Before migration:
v=spf1 include:_spf.google.com include:sendgrid.net -all
During migration:
v=spf1 include:_spf.google.com include:sendgrid.net include:spf.mtasv.net -all
After migration:
v=spf1 include:_spf.google.com include:spf.mtasv.net -all
Handling the Lookup Limit During Migration
The parallel-running period means extra includes in your SPF record. If you're already using 8-9 lookups, adding another provider can push you over the 10-lookup limit. Here are your options:
Temporarily use ~all instead of -all. Switching from hard fail to soft fail during the migration means emails that exceed the lookup limit get a softfail result instead of fail. Most mailbox providers treat softfail more leniently. Switch back to -all after removing the old provider.
Use a subdomain for one email stream. Move marketing or transactional email to a subdomain during the migration. This gives that stream its own SPF record and lookup budget. You might find the subdomain approach works so well that you keep it permanently.
Clean up unused includes first. Before starting the migration, audit your SPF record for services you no longer use. Removing one dead include might be all you need to fit both providers.
Verification Between Steps
Don't just make changes and hope for the best. Verify at each stage of the migration:
- After adding the new include, send a test email through the new provider and check the headers for
spf=pass - During the parallel period, spot-check emails from both providers to confirm both pass SPF
- After removing the old include, verify that all email still passes SPF authentication
Use SPF Record Check to validate your record's syntax and lookup count at each step.
Don't Forget DKIM and DMARC
SPF is just one piece of the authentication puzzle. When you switch providers, you also need to update your DKIM records -- each provider has its own DKIM signing keys. If you've been using the old provider's DKIM key, it won't work for the new provider.
Your DMARC policy should already be in place and doesn't need to change during the migration, but monitor your DMARC reports closely during the transition. They'll show you if any email is failing authentication so you can catch problems early.
Set up monitoring with Deliverability Checker before you start the migration. Daily monitoring during a provider switch lets you catch authentication failures the same day they happen, not weeks later when your bounce rates spike.
After the Migration
Once the old provider is fully removed and everything is running through the new provider, do a final check:
- SPF record contains only active providers -- verify with SPF Record Check
- DKIM is configured and passing for the new provider
- DMARC reports show clean authentication results
- Lookup count is back within a comfortable range
Document the final SPF record and the date of the change. The next time you migrate, you'll be glad you kept a record of what changed and when.
Related Articles
Never miss an SPF issue
Monitor your SPF, DKIM, DMARC and MX records daily. Get alerts when something breaks.
Start Monitoring