ESP Migration Playbook: Switch Providers Without Losing Sender Reputation

Changing email service providers is one of the riskiest things an email program does. Mailbox providers have learned to trust a specific combination of IPs, signing domains, volume patterns and engagement. Change all of those on the same day and Gmail, Outlook and Yahoo see what looks like a brand-new sender with a very large list.

The good news: a migration does not have to cost you deliverability. With a clear timeline, authentication in place before cutover, a gradual parallel ramp and a clean suppression transfer, most senders keep the bulk of their reputation intact. This playbook walks through each step, week by week.

Step zero: make sure migration will fix your problem

Teams often switch providers hoping to escape a deliverability problem. Some problems move with you, and a new platform just gives them fresh infrastructure to damage.

Run your domain through the sender reputation checker and the blacklist checker before you decide. If you are listed or your complaint rate is high, fix that on your current platform first.

The migration timeline at a glance

Small programs on shared IPs can compress this toward six weeks. Enterprises with several dedicated IPs should plan for eight to twelve.

Weeks 1 to 2: plan and choose

Build an inventory

Write down everything the old platform touches. You will be surprised how much there is.

• Every sending domain and subdomain, with its current SPF, DKIM and DMARC records.
• Every IP you send from, and whether it is shared or dedicated.
• Every integration: CRM, ecommerce platform, signup forms, analytics, data warehouse, webhooks.
• Every automation: welcome series, cart recovery, receipts, re-engagement, sunset rules.
• Your current volumes by day and by stream (marketing versus transactional).

Export your data

Export contacts with engagement history (last open, last click, signup date, source), campaign performance and, above all, suppression data. More on that below.

Choose the destination with deliverability in mind

Ask each shortlisted vendor the same questions:

• Will I start on a shared pool or a dedicated IP? If dedicated, is warmup automated or manual?
• Can I use custom DKIM on my own domain and a custom return-path for SPF alignment?
• How are bounces, complaints and unsubscribes handled, and can I import my suppression list?
• What reporting do I get on bounces by code and complaints by provider?

Options differ a lot here. Brevo and Mailchimp are simple marketing platforms on shared pools. Amazon SES and Postmark are sending infrastructure for teams with developers. SendPulse is one example of a destination that includes a dedicated IP on its SMTP Pro plan and a built-in verifier for cleaning lists on the way in. Our bulk email services comparison covers the trade-offs in detail.

Weeks 3 to 4: authentication before cutover

Authentication is the step most likely to break something, because it affects mail from both providers during the overlap. The goal is simple: both platforms pass SPF, DKIM and DMARC at the same time, and neither is removed until the old one has stopped sending.

SPF: add, do not replace

Add the new provider’s include next to the old one:

example.com.   TXT   "v=spf1 include:_spf.oldesp.example include:spf.newesp.example ~all"

Two constraints matter. First, one domain can have only one SPF record, so edit the existing one rather than creating a second. Second, SPF allows at most 10 DNS lookups. Adding a second ESP often pushes busy domains over the limit, which causes a PermError and fails SPF for everyone. Check the count with the SPF checker after every change.

If you use a custom return-path (bounce) subdomain at each provider, SPF is evaluated on that subdomain instead, which can keep your root record lean.

DKIM: separate selectors for each provider

Each provider signs with its own selector, so both can live side by side:

old._domainkey.example.com.   CNAME   old._domainkey.oldesp.example.
s1._domainkey.example.com.    CNAME   s1.dkim.newesp.example.

Use 2048-bit keys where the provider allows it. The important detail is the d= value in the signature: it must be your domain (or a subdomain of it) for DMARC to align. Confirm each selector with the DKIM checker, then send a test message and read the Authentication-Results header with the header analyzer.

DMARC: hold your policy

If you are at p=quarantine or p=reject, stay there. There is no reason to drop to p=none if both providers sign with aligned DKIM, and doing so removes your protection against spoofing during a period when attackers know you are busy. Route aggregate reports to a mailbox or analyzer you actually check, and look for new failure sources every day during the overlap. Our email authentication guide explains how the three records work together.

Rebuild and test everything else

• Recreate templates, preserving the List-Unsubscribe and List-Unsubscribe-Post headers for one-click unsubscribe.
• Set up a branded tracking domain so links do not point at a shared ESP domain.
• Rebuild automations and test each trigger with internal addresses.
• Register the sending domain in Google Postmaster Tools and, for dedicated IPs, in Microsoft SNDS.

Transfer your suppression list before anything sends

This is the step teams forget, and it is one of the most expensive mistakes in email. Every address your old platform learned not to mail must be blocked on the new one before its first send.

Export and import:

1. Hard bounces, including historic ones.
2. Spam complaints from feedback loops.
3. Unsubscribes, across all lists and preference categories.
4. Manual suppressions, such as legal requests or known bad actors.
5. Role and disposable addresses you filtered at signup, if you track them.

Then verify the rest of the list. A migration is the ideal moment to remove invalid and mistyped addresses, and our verification tools comparison covers the options. Keep hard bounces under 2% on every send during warmup.

Weeks 5 to 8: warm up with a parallel send

Why run both providers at once

During warmup, the old platform keeps carrying most of your volume while the new one gradually earns trust. The total amount of mail from your domain stays steady, which protects domain reputation, and the new IPs see only your best recipients at first.

The mechanics are straightforward:

1. Split each campaign audience into two cohorts.
2. Send the “new” cohort through the new provider and the rest through the old one.
3. Increase the new cohort’s share as metrics stay healthy.
4. Sync unsubscribes, bounces and complaints between platforms daily, or better, in real time via webhooks.

Warm by engagement, not by list order

Mailbox providers judge new infrastructure mainly by how recipients react. Start with people who engage the most.

On a dedicated IP, daily volume on the new infrastructure can grow quickly at first and more slowly later. Watch per-provider results: Gmail, Microsoft and Yahoo each warm at their own pace, and you can hold volume steady at one provider while growing at the others. For detailed ramp schedules, see our IP and domain warmup guide.

Shared pools need a lighter ramp

If your new provider places you on a shared pool, the IPs already have history. You still need to introduce your domain gradually, because the domain is new to that infrastructure, but the ramp can usually be shorter.

Keep transactional mail steady

Receipts and password resets should never be the guinea pigs. Move transactional streams after marketing has settled, or keep them on a separate subdomain and provider throughout. Our transactional vs marketing guide explains why.

Monitoring and rollback

What to watch daily

Your ESP’s delivery rate only tells you that mail was accepted, not where it landed. During warmup, look at:

• Google Postmaster Tools: domain reputation, spam rate (keep it under 0.1%, never above 0.3%) and authentication results.
• Microsoft SNDS: IP status colors and trap hits for dedicated IPs.
• Bounce codes: a jump in 4xx deferrals such as 421 means a provider is throttling you.
• DMARC aggregate reports: new failure sources point to a misconfigured record or template.
• Seed or panel tests: weekly inbox versus spam placement by provider.

Agree rollback triggers in advance

Decide when you will pause before you start, so nobody argues about it in the middle of a bad week. Reasonable triggers:

• Gmail domain reputation falls to Low or Bad for several days in a row.
• Any campaign on the new provider bounces above 5%.
• Complaint rate on the new provider approaches 0.3%.
• A dedicated IP turns red in SNDS or appears on a major blocklist.

If a trigger fires, shift volume back to the old provider, find the cause and restart the ramp from a lower step. Losing two weeks is far cheaper than losing two months.

Weeks 9 to 16: cutover and cleanup

Complete the cutover

Once the new provider carries full volume with stable metrics, stop sending from the old one. Keep the account open (but idle) for at least four more weeks in case you need to roll back.

Remove old records last

After four weeks of stable full-volume sending, remove the old provider’s SPF include and DKIM selector. Recheck SPF lookups and DMARC reports afterwards to confirm nothing else relied on them.

Lock in the gains

• Tighten DMARC toward p=reject if you are not there yet.
• Automate engagement-based sunset rules so the list does not decay again. Our list hygiene guide has a practical model.
• Document the final setup: records, selectors, IPs, integrations and owners. You will need it for the next migration, and most programs switch providers every few years.

Common migration mistakes

Most failed migrations share a handful of causes. Each one is easy to avoid when you know to look for it.

Cutting over in one send

The classic error is moving 100% of volume on launch day because the old contract ends on Friday. Negotiate a few weeks of overlap with your old vendor before you sign with the new one. A month of double subscription costs far less than a quarter of degraded placement.

Changing the From domain at the same time

Your domain carries most of your portable reputation. If you also rebrand, switch to a new sending subdomain and change providers in the same month, mailbox providers see a stranger. Change one variable at a time: migrate first, then introduce a new domain later with its own warmup.

Forgetting the “invisible” senders

Invoices from billing systems, alerts from monitoring tools and notifications from help desks often send as your domain through the old provider or their own servers. When you remove the old SPF include too early, those streams start failing DMARC. Your DMARC aggregate reports will show every source, so review them before you delete anything.

Losing preference and consent data

Unsubscribes are obvious, but preference centers, consent timestamps and signup sources are easy to drop during export. Without them you cannot prove consent or honor topic-level opt-outs. Map every custom field before you import, and keep a copy of the original export.

Breaking links and tracking

Old campaign links may point to a tracking domain that stops resolving once the old account closes. Keep old tracking CNAMEs in place for several months, and set up a branded tracking domain on the new provider from day one.

Judging success by delivery rate

A 99% delivery rate only means receiving servers accepted the mail. It says nothing about the spam folder. Judge the migration by Postmaster Tools reputation, complaint rate, click rate by mailbox provider and seed placement.

Who owns what during the migration

Migrations stall when everyone assumes someone else is handling a step. Assign owners early.

A short daily stand-up during weeks 5 to 8 keeps everyone looking at the same numbers.

Migration checklist

Use this as a final pass before each phase.

Before any send from the new provider

• Inventory of domains, IPs, integrations and automations complete
• New SPF include added, lookup count under 10
• New DKIM selectors published and aligned with your domain
• DMARC policy unchanged and reports flowing
• Branded tracking and return-path domains configured
• Suppression list fully imported
• Remaining list verified and inactive contacts excluded
• Postmaster Tools and SNDS access set up
• Rollback triggers agreed and written down

During warmup

• Only engaged cohorts on the new provider
• Unsubscribes and bounces synced between platforms
• Daily checks of reputation, bounces and complaints

After cutover

• Old account idle but open for four weeks
• Old SPF and DKIM records removed after stable sending
• Sunset automation active on the new platform

Follow the plan, resist the pressure to rush the ramp, and your new provider will inherit a sender that mailbox providers already trust.