Migrating email providers without breaking SPF, DKIM or DMARC

Why a migration touches four records, not one

Moving mail from one provider to another — self-hosted to a cloud suite, one cloud suite to another, or consolidating several domains onto one provider — looks on the surface like changing a single MX record. In practice, four separate DNS-published pieces all need to agree before mail flows correctly: MX decides where incoming mail is routed, SPF decides which outgoing servers are authorized to send as your domain, DKIM decides whether a receiver can verify that an outgoing message wasn’t altered, and DMARC decides what happens to mail that fails the other two — see SPF, DKIM and DMARC explained for how the three work together in the steady state this guide is migrating to. A migration is risky specifically because these four normally change together but don’t update atomically: DNS propagates on its own schedule, and the new provider typically needs its own records published and verified before you can safely rely on it for anything real.

The order that keeps mail flowing throughout

The sequence below keeps every step reversible and verified before the next one depends on it, rather than changing everything at once and finding out what broke afterward.

Step 1: inventory what’s actually live today

Before changing anything, record your current state with AdminKit’s free, account-free checks: MX lookup for your current mail hosts and their priorities, SPF check for every service currently authorized to send as your domain, DKIM check for your current selector(s), and DMARC check for your current policy and reporting address. This list is what you’ll be comparing against at the end to confirm nothing legitimate got dropped along the way — and it’s the only reliable way to catch a sending service (a CRM, an invoicing tool, a helpdesk) that was authorized under the old provider and that you’d otherwise forget exists.

Step 2: lower TTLs ahead of the cutover

Every DNS record carries a TTL controlling how long a resolver may cache the previous answer before re-checking — see DNS propagation and TTL explained for realistic timelines. Lowering the TTL on your MX, SPF and DKIM records a day or more before you plan to change them means a mistake you catch quickly can also be rolled back quickly, instead of staying cached at a stale value for hours after you’ve already fixed it.

Step 3: dual-publish SPF for both providers

Add the new provider’s include (or ip4/ip6) mechanism to your SPF record alongside the old provider’s — don’t remove the old one yet. Re-run SPF check after adding it: stacking two providers’ mechanisms temporarily is exactly the kind of change that can push a record over RFC 7208’s 10-DNS-lookup limit, so confirm you’re still under it before moving on — see fixing SPF “too many DNS lookups” (PermError) if the check flags it. Keep both providers authorized until you’re confident nothing is still sending through the old one (Step 6 covers how to confirm that).

Step 4: publish the new provider’s DKIM selector, then verify before signing switches

Your new provider will generate its own key pair and selector name — publish the TXT record it gives you, then confirm it with DKIM check before the provider actually starts signing with it. This is the same overlap principle covered in how to rotate a DKIM key without breaking mail, applied here to two different providers’ keys running in parallel rather than two versions of your own: mail already in transit when signing switches over still carries whichever selector’s signature was live at send time, so both the old and new provider’s selector records need to stay published and valid through the transition, not just the new one. See DKIM selector and record mistakes that break signing for the syntax errors that most often undermine a selector that otherwise looks right.

Step 5: leave DMARC policy alone, and watch what it reports

Resist the urge to change your DMARC policy as part of the same cutover — keep it at whatever it already was (or publish a new record at p=none if you didn’t have one) so it does one job during the migration: tell you, via its rua aggregate reports, whether mail from the new provider is actually passing SPF and DKIM alignment before you’ve committed to it. Reading DMARC aggregate reports and rolling out to p=reject safely covers how to read those reports in detail. If reports show the new provider’s source passing cleanly, you have real evidence the migration is working, not just an assumption based on the records looking correct.

Step 6: cut over MX, then confirm before touching anything else

Once the new provider is accepting mail correctly and SPF/DKIM are both verified for it, update your MX records to point at the new provider. Re-run MX lookup afterward — how to read an MX lookup result covers the common case where a lookup still briefly shows the old hosts due to TTL caching rather than a failed change, so don’t assume the cutover failed before the old TTL has had time to expire everywhere.

Step 7: retire the old provider’s records, not delete them outright

Once mail has been flowing through the new provider cleanly for a period you’re confident covers any mail still in flight from before the cutover, remove the old provider’s SPF mechanism and revoke (rather than delete) its DKIM selector by publishing an empty p= value at that selector’s hostname, the same pattern how to rotate a DKIM key without breaking mail uses for a same-provider key rotation. A revoked selector fails cleanly and is obviously intentional if anyone investigates later; a deleted record just looks like a mail setup nobody finished configuring.

The mistake that causes most post-migration delivery problems

Mailbox migration and mail-sending migration aren’t always the same event. A billing system, support desk, marketing platform or internal application often keeps sending transactional mail through the old provider’s SMTP relay well after user mailboxes have already moved to the new one — and if that sender was only authorized through the old provider’s SPF include, it silently starts failing SPF the moment that include is removed. Checking DMARC aggregate reports (Step 5) for every sending source still appearing there, not just the ones you remember configuring, is what catches this before it causes a delivery problem instead of after one is already reported to you.

Final verification pass

Once the old provider’s records are retired, run all four checks again — MX lookup, SPF check, DKIM check and DMARC check — and compare the result against the inventory from Step 1. Every legitimate sending source from the original list should still be authorized somewhere in the new setup; anything that’s missing is worth tracking down before you consider the migration finished, not after someone reports mail that never arrived.

This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.