ESP migration: switching email providers without losing deliverability

After this lesson you can plan an ESP migration in the right order and prove, from the outside, that the new path works before your reputation depends on it. The core fact first: switching ESPs is a partial cold start dressed up as an admin task. Your domain reputation travels with you. Your sending infrastructure, your DKIM path, your bounce handling, and your list intelligence do not. Senders who treat the switch as data entry lose weeks of placement to a move nobody warned them about; senders who treat it as a controlled re-warming barely feel it. Migrations are one of the most reliable decay triggers we know, and almost every guide to them is written by an ESP with a side to take. This one isn't.

What changes and what doesn't

Recall from the sender reputation lesson that reputation attaches to your authenticated domain and to the sending IP. The domain is yours; it comes along. Nearly everything else is replaced:

• New sending infrastructure. Your mail now leaves from IPs you have never used, usually a different shared pool with its own history. To every receiver, the path is unfamiliar.
• New DKIM records. Each ESP signs through its own selectors and CNAMEs. Mailchimp puts a k1._domainkey CNAME pointing at dkim.mcsv.net; Klaviyo uses km1 and km2 pointing at klaviyodns.com. Nothing transfers; the new ESP's records must be created from scratch.
• New Return-Path. The bounce domain, the address the envelope claims, changes with the provider, and with it the domain SPF alignment is judged against.
• Stranded engagement history. The old ESP knows who opens, who went quiet, who complained. The new one starts blind unless you carry that intelligence over yourself.
• Old records left behind. The departing ESP's DNS entries do not clean themselves up. They sit in your zone until someone removes them, and mostly nobody does.

Same domain, new everything else. That is why placement can dip after a migration in which, as far as the sender can tell, nothing changed.

Export the suppression list first

Before you create a single record at the new ESP, export your suppression list: every unsubscribe, hard bounce, and complainer the old system has been quietly holding back for you. This is the asset people forget, precisely because it's invisible. Nobody misses a list of people they don't mail.

Import your subscribers into a new ESP without it and the new system sees them all as fresh, willing recipients. The first campaign then mails people who unsubscribed (a legal problem in every jurisdiction covered in the email law lesson, and a guaranteed source of complaints), plus addresses that already hard-bounced. Those are the worst possible opening signals on a path that has no history to absorb them.

Export your engagement segments at the same time, at minimum "opened or clicked in the last 90 days". You'll need them for the ramp. And do all this exporting while your old account is fully active; exports are exactly the kind of thing that gets awkward after you cancel.

Authenticate before the first send

The new ESP's authentication setup must be complete and verified before the first message leaves through it. Not mostly done. Done, and confirmed from public DNS.

The failure this prevents is the one our ESP checkers exist to catch: the setup that looks finished but isn't. Brevo will show a domain as verified once its verification TXT record is added, but if the DKIM CNAMEs were skipped, mail still signs as sendinblue.com and your domain builds no reputation from any of it. Kit setups where the Verified Sending Domain flow was never completed send from Kit's shared domain, outside your DMARC's coverage entirely. The dashboard's green tick and a working authentication path are two different claims.

Checking the new records from the outside is exactly the job our per-ESP spam checkers do: each page, the Klaviyo checker or the Mailchimp one for instance, probes the record names that provider's official setup docs specify, on whatever domain you give it. One honest limit: some providers issue per-account record names (Constant Contact's numeric selectors are the known case), so a miss there reads "not found at the usual names", not "broken". The paste-level mistakes these probes catch are old friends by now: a DNS host silently appending your domain to a CNAME name so the record answers at k1._domainkey.example.com.example.com, or an SPF include pasted as a second v=spf1 record, which makes SPF permanently fail on domains that had it working for years.

The overlap, and who moves first

A one-day cutover is the amateur move. Run both ESPs in parallel and move traffic across gradually, because the new path is unknown infrastructure and needs the same treatment as any cold start: the warming logic from the shared-vs-dedicated lesson applies unchanged. Lead with the engaged segments you exported, grow volume over days to weeks depending on your scale, and slow down if you see deferrals.

Your mail streams don't all have to move at once, and shouldn't. Move the engaged marketing stream first; it builds the new path's reputation fastest and can best afford a rough day. Move transactional last, once the path has proven itself, because a password reset in spam is the failure you can least afford.

Keep the old ESP's DNS records in place until the final stream has moved. Mail still flowing through the old provider still needs its authentication; deleting those records mid-overlap silently breaks every message that hasn't migrated yet. Tidiness can wait a few weeks.

Prove it from the outside

Two checks close the migration. First, send a real message through the new path to a mailbox you control, open the raw source, and find the Authentication-Results header: the receiving server's own verdict line. You want spf=pass and dkim=pass, and the DKIM d= value should be your domain, not the ESP's shared one. Second, run the per-ESP checker on your new sending domain and the full health check on the whole setup, because internal dashboards report what the ESP believes, and you've just seen how far that can drift from what receivers observe.

The migration you'll forget you did

The most common migration artifact our checker meets is not from the migration being planned. It's from one the domain owner has half-forgotten: an SPF record that still includes an ESP the business left two years ago. We flag these as dead includes, and they are pure downside. Each one spends part of SPF's 10-lookup budget, and each one keeps authorizing sending infrastructure you no longer control, so mail leaving that provider's shared systems can still pass your SPF. The last step of a migration, after the final stream has moved and a real message has verified clean, is deleting the old ESP's records and re-running the health check to confirm the zone holds only what you currently use.

Next comes the Part 4 checkpoint, where you audit your own list practice and sending setup against everything this part taught.

Terms from this lesson

• ESP migration - moving your sending from one email service provider to another; the domain's reputation comes along, the infrastructure and records do not.
• cutover - the moment a mail stream stops sending through the old ESP and starts through the new one.
• overlap period - the stretch where both ESPs run in parallel, streams moving across one at a time as the new path earns trust.
• suppression list - the old ESP's record of unsubscribes, hard bounces, and complainers; export it before anything else or the new ESP will mail them again.
• re-warming - ramping volume on the new path engaged-segments-first, because new infrastructure has no history and gets the cold-start treatment.
• dead include - an SPF include for an ESP you no longer use: it spends lookup budget and authorizes infrastructure that stopped being yours.

Check yourself

1. What should you export from the old ESP before setting anything up at the new one?

Your email templates, so campaigns keep their designThe suppression list and engagement segments, while the old account still has full accessThe DKIM private keys, so the new ESP can reuse themNothing; subscriber lists sync automatically between major ESPs

2. When should the new ESP's authentication records be verified?

After the first campaign, which doubles as a live testOnly if the old ESP's records have already been removedBefore the first message is sent through the new path, from public DNS, not just the ESP dashboardVerification is unnecessary when the dashboard shows the domain as verified

3. When is it safe to delete the old ESP's DNS records?

At the start of the migration, so the zone stays tidyNever; old ESP records should stay as a fallbackAs soon as the first campaign sends successfully from the new ESPAfter the last mail stream has moved and a real message from the new path has verified clean

Scenario

Your client is moving their 40,000-subscriber store from Mailchimp to Klaviyo. Their plan: this Friday evening, finish the Klaviyo setup, delete the Mailchimp DNS records to keep things clean, and send Monday's newsletter to the full list from Klaviyo.

What do you change about this plan?

Nothing; a clean single cutover avoids confusing mailbox providers with two sendersReorder it: export suppressions and segments first, verify Klaviyo's records from outside before any send, then overlap both ESPs with engaged segments moving first and Mailchimp's records staying until the last stream movesKeep the Friday cutover but buy a warm-up service for the weekend so Klaviyo's path has engagement by MondaySend Monday's newsletter through both ESPs at once, then keep whichever performs better