How do you migrate from one ESP to another safely?

ESP migrations go wrong in predictable ways: authentication breaks, suppressions don't transfer, IP warmup gets skipped, and suddenly you're in a deliverability hole that takes months to crawl out of. The senders who migrate cleanly are the ones who treat it as a project with a checklist, not a configuration task they handle in a day.

So before you touch anything, document your current setup. That means your sending domains, authentication records (SPF, DKIM, DMARC), tracking domains, suppression lists, active automations, templates, and integrations. Your new ESP needs everything your old one had, and it's much easier to set it up correctly when you're looking at a complete reference rather than rebuilding from memory.

Export your suppression lists first. Hard bounces, unsubscribes, and complaint records need to travel with you. Failing to import suppressions means you'll immediately email people who opted out or bounced. That's a compliance problem and a reputation problem at the same time.

Set up authentication on your new ESP before sending a single message. Add new DKIM selectors for the new platform, update your SPF record to include the new ESP's sending infrastructure, and verify your DMARC is still pointing at a valid reporting address. You can verify your setup with our free SPF Checker.

Then warm up your new IPs properly. Even if you've been sending for years, new IP addresses have no history with mailbox providers. Start with your most engaged subscribers, the ones who open and click regularly, at a fraction of your normal volume. Build up gradually over several weeks before moving your full list. Skipping this step is the most common cause of migration-related deliverability damage.

Keep both ESPs active in parallel for at least four to eight weeks. Run tests, monitor logs, shift traffic gradually, and don't cancel the old account until you're confident everything is working correctly on the new one.