Migrating ESPs Without Destroying Your Sender Reputation

Switching email providers resets your IPs, your DKIM keys, and every provider assumption about your traffic. A migration plan that carries your reputation across.

An ESP migration is a reputation event disguised as a procurement decision. New IPs with no history, new DKIM selectors, new bounce domains, new sending patterns: from a mailbox provider's perspective, a familiar domain suddenly behaving like a stranger. Most migration horror stories are not caused by the new platform being worse. They are caused by moving everything at once and leaving the suppression list for later.

What moves with you and what resets

Gmail and Yahoo weight the authenticated domain heavily, so a domain with years of clean history carries that history to any infrastructure, provided the DKIM d= domain stays the same. Microsoft leans more on IP reputation, which is why Outlook.com is routinely the roughest destination during a migration: your new IPs start as unknowns there regardless of how good your domain looks.

Everything platform-specific resets. Feedback loop registrations tied to the old ESP's IPs, the old platform's suppression automation, allowlist entries referencing specific ranges, and the delivery heuristics your team learned by experience: all of it needs re-establishing. Write the inventory down before you sign the new contract, not after.

The suppression list is the crown jewels

Every address that hard bounced, complained, or unsubscribed on the old platform must be suppressed on the new one before the first campaign leaves it. Miss this step and the new infrastructure re-mails years of accumulated dead addresses and complainers in its first sends, on unwarmed IPs, at the exact moment providers are deciding what this new traffic is. It is the single most common cause of catastrophic migrations.

Export from the old ESP: unsubscribes, spam complaints, hard bounces with reasons, and any manual suppressions. Import into the new platform's global suppression, and verify with a test segment that the import actually enforces. Unsubscribe suppression is also a compliance obligation, which makes this the one migration step with legal consequences attached.

The parallel-running playbook

Timing and the calendar

A migration needs six to twelve weeks of calendar room between kickoff and full cutover, plus slack for the surprises. That rules out the run-up to whatever your peak season is: retail senders do not migrate in October, and B2B senders avoid the fiscal-year-end push. The worst possible plan is the one driven by a contract end date that lands a hard cutover in a high-stakes week; renegotiate a month of overlap with the old provider if you have to. It is cheaper than the alternative.

During the parallel phase, expect blended metrics. The same campaign will perform differently per platform because the IPs differ, so instrument reporting by sending infrastructure from day one. The comparison is not old versus new platform features; it is per-provider placement and deferral behaviour on each infrastructure, week over week.

Signals you are moving too fast

Rising 4.7.x deferrals from any major provider on the new IPs, Postmaster Tools IP reputation stuck at Low, SNDS turning yellow, or complaint rates on the new stream exceeding the old one for the same content all mean the same thing: hold or reduce volume on the new side and let it stabilize. The warming curve is a ceiling, not a schedule to be met. Providers do not care about your project plan, and pushing through deferrals converts a slow week into a filtered month.

Treat the migration as a deliverability project with a procurement side effect, and sequence it so that at every moment some infrastructure with intact reputation is carrying your critical mail. Platforms are interchangeable. The identity you authenticated for years, and the suppression history that protects it, are not.