Email Deliverability During ESP Migration: How to Switch Without Losing Reputation
Migrating to a new email service provider? Learn how to switch ESPs without damaging deliverability, including DNS changes, IP warmup, and list migration.
Switching email service providers is one of the riskiest email operations. Done poorly, it breaks authentication, resets IP reputation, and drops deliverability for weeks. Done carefully, you can transition without your recipients noticing.
Migration Risks
What Can Go Wrong
| Risk | Impact | How to Prevent |
|---|---|---|
| Authentication breaks | SPF/DKIM failures → spam or rejection | Update DNS before sending from new ESP |
| New IP has no reputation | Throttling and spam filtering | Warm up gradually |
| Suppression list not migrated | Emailing people who unsubscribed or complained | Export and import all suppressions |
| DNS propagation gap | Old records cached, new records not visible | Lower TTL before changes |
Migration Plan
Prepare DNS (2 weeks before)
Lower TTL on SPF and DKIM records to 300 seconds. This ensures DNS changes propagate quickly when you make them.
Set up the new ESP
Configure your sending domain in the new ESP. Generate DKIM records and note the SPF include value. Don't send anything yet.
Update DNS records
Add the new ESP's SPF include to your existing record (keep the old ESP's include too). Add new DKIM records alongside existing ones. Wait 48 hours for propagation.
Migrate suppression lists
Export unsubscribes, bounces, and complaints from the old ESP. Import them into the new ESP before sending any email. This is the most commonly skipped step — and the most dangerous to skip.
Warm up the new ESP
Start sending small volumes through the new ESP to your most engaged subscribers. Gradually increase over 4–6 weeks.
Run both ESPs in parallel
During warmup, split your sends: some through the old ESP, some through the new. Monitor deliverability on both.
Complete the cutover
Once the new ESP is fully warmed and deliverability is stable, stop sending from the old ESP. Remove the old ESP's SPF include and DKIM records from DNS.
Monitor during migration
DNS changes during migration can break authentication. Monitor your SPF, DKIM, and DMARC throughout the transition.
Critical: Suppression List Migration
The most commonly missed step. Your old ESP has lists of addresses that should never be emailed:
- Hard bounces — Addresses that don't exist
- Unsubscribes — People who opted out
- Spam complaints — People who reported you as spam
- Manual suppressions — Addresses you've blocked for any reason
If you don't migrate these to your new ESP, you'll email people who've already told you to stop. This generates immediate complaints and bounces that can damage your reputation on the new platform from day one.
Export Everything
From your old ESP, export:
- Complete unsubscribe list with dates
- Hard bounce list
- Spam complaint list
- Any custom suppression lists
Import Before Sending
Load all suppression data into your new ESP before sending a single email. Verify the import was successful by spot-checking known suppressed addresses.
DNS Management During Migration
The Overlap Period
During migration, your SPF record should include both ESPs:
v=spf1 include:_spf.google.com include:old-esp.com include:new-esp.com ~all
This uses more DNS lookups but ensures authentication passes regardless of which ESP sends a particular message. Monitor your lookup count — if you're at the limit, consider using subdomains.
DKIM Coexistence
Both ESPs can have DKIM records simultaneously since they use different selectors. Keep the old ESP's DKIM records active until you've fully migrated.
After Migration
Once you've completely stopped sending from the old ESP:
- Remove the old ESP's SPF include
- Wait 1–2 weeks, then remove old DKIM records
- Restore DNS TTL values to normal (3,600+ seconds)
- Verify authentication still passes with our checker
Common Migration Mistakes
Migrating Entire List at Once
Don't import your full list and blast from the new ESP. Start with engaged subscribers and expand gradually. Treat the new ESP like a new domain — it needs warmup.
Forgetting About Automated Flows
Transactional emails, drip sequences, and automated flows need to be recreated in the new ESP. Test every automated email before going live.
Not Testing Authentication
After every DNS change, send test emails and verify SPF, DKIM, and DMARC all pass. Don't assume — verify.
Rushing the Timeline
A proper migration takes 6–8 weeks. Rushing it means inadequate warmup, missed suppressions, and authentication gaps. Plan the timeline before you start.