How to Keep Deliverability Intact When Switching ESPs
Switching ESPs is the kind of task that gets postponed indefinitely. Your current platform is mediocre, support takes days to respond, and the price goes up every year. But the thought of migrating is scarier than all of that combined. The main fear: losing the inbox placement you spent months building.
That fear is legitimate. A rushed migration can absolutely tank your inbox rate. Done with a plan, the move goes through without incident. This article covers the specific steps, the right sequence, and the mistakes worth avoiding.
Why deliverability drops when you switch ESPs
When you move to a new provider, your sending infrastructure changes. Different IP addresses. Different SMTP servers. From a mailbox provider's perspective, email from your domain arrived from one source yesterday and from a completely different one today. The trust built up with the old IP does not transfer.
Domain reputation does carry over. Gmail, Yahoo, and Outlook tie reputation to the From domain, not just the IP. But IP reputation still matters. On a new dedicated IP you have zero history. On a new ESP's shared IP you inherit someone else's history, which could be clean or not.
The third source of trouble is configuration errors. An SPF record that did not get updated, a missing DKIM entry for the new ESP, a stale DMARC policy. Everything that "just worked" on the old platform needs a manual check during the move.
Preparation: what to do before you migrate
Migration starts before you sign up at the new ESP. It starts with an audit of where you stand today.
- Record your current metrics. Open rate, click rate, bounce rate, spam complaints, inbox placement at each major provider (Gmail, Yahoo, Mail.ru, Outlook). These numbers are your baseline. Without them you cannot tell whether deliverability actually declined after the move.
- Export your suppression lists. Hard bounces, unsubscribes, spam complaints. This is your "do not mail" list, and it cannot get lost in the move. Send to suppressed addresses on the new platform and you will see a complaint spike that takes time to recover from.
- Validate your list. Run the full database through a validator before migrating. Addresses that worked six months ago may have gone dead. Migrating a dirty list guarantees problems from the very first send.
- Document your automations. Trigger sequences, welcome series, cart abandonment flows, re-engagement campaigns. Everything running automatically on the old ESP needs to be rebuilt on the new one. Write down the conditions, delays, and templates.
- Decide on IP type at the new ESP. Shared or dedicated. If you send more than 50,000 emails per month, a dedicated IP gives you more control but requires a warmup. Shared IP skips warmup but makes you dependent on your neighbors.
DNS records: configure before the first send
This is the foundation. Errors here are expensive. Every ESP uses its own SMTP servers, which means SPF and DKIM both need updating.
SPF
Add the new ESP's include to your SPF record. Do not remove the old include until the migration is fully complete — during the transition, mail may go out through both platforms. Watch the 10 DNS-lookup limit.
DKIM
Each ESP generates its own DKIM key pair. Add the CNAME or TXT record for the new ESP. Keep the old DKIM record in place as long as any mail is going out through the previous platform.
DMARC
If you already have p=reject, confirm the new ESP passes domain alignment. If alignment fails, your own DMARC policy will reject mail from the new service. Test before going live.
Custom tracking domain
Set up your own domain for click and open tracking. By default the ESP uses its own tracking domain, which may carry reputation damage from other customers. A custom tracking domain also helps with DMARC alignment.
After setting everything up, send test messages to Gmail, Yahoo, Mail.ru, and Outlook addresses. Check the headers: SPF pass, DKIM pass, DMARC pass. If any check fails, do not start the migration.
Migration strategy: gradual, not all at once
The most common mistake is flipping all traffic in a single day. On the old ESP you sent 100,000 emails a week. On the new one: zero on day one, then 100,000 on day two. To spam filters, that looks exactly like a spam attack launching from a fresh IP.
The right approach is running both ESPs in parallel for two to four weeks, shifting traffic in stages.
Traffic migration schedule
| Week | New ESP | Old ESP | Who to move |
|---|---|---|---|
| 1 | 10–15% | 85–90% | Most engaged subscribers (opened in the last 14 days) |
| 2 | 30–40% | 60–70% | Active subscribers (opened in the last 30 days) |
| 3 | 60–70% | 30–40% | Core list (opened in the last 60 days) |
| 4 | 100% | 0% | Full cutover, old ESP decommissioned |
If metrics dip in week three, roll back to week two proportions and diagnose before moving forward.
Starting with your most engaged subscribers is not arbitrary. They open, they click. Gmail and other providers see positive engagement signals from the new IP and start extending trust. Sending the first batch to people who have not opened in three months is a reliable way to poison the new IP's reputation before it even gets started.
IP warmup on the new ESP: what to keep in mind
If you are moving to a dedicated IP, warmup is required. The logic is the same as starting from scratch: low volumes first, scaling up gradually. The difference is that your domain already has a reputation, which speeds things up.
Since 2024, Gmail has weighted domain reputation above IP reputation. If your domain shows High status in Google Postmaster Tools, warming a new IP may take two weeks rather than four. The provider already knows your domain and is willing to extend some trust even to an unfamiliar IP.
On a shared IP, no warmup is needed — the ESP has already warmed those addresses. But sending quality still matters. If your new ESP is tolerant of spammers, its shared IPs may already be dirty on day one.
A strict anti-spam policy is a good sign in an ESP. If they turn away customers with dirty lists, their shared IPs stay clean. Choose a provider that does not accept everyone.
Monitoring: what to check every day
During the migration you check metrics daily. Not weekly, not when you get around to it. Every day. One missed anomaly turns into a week of cleanup.
Bounce rate
Compare against your baseline from the old ESP. A bounce increase on the new platform means some addresses failed validation or the receiving server is rejecting an unfamiliar IP.
Spam complaints
The threshold is 0.1%. Complaints can tick up briefly during migration: mail lands in spam, subscribers do not recognize the sender because the reply-to or tracking domain looks different.
Inbox placement
Google Postmaster Tools shows where your mail lands. If the spam rate jumps from 2% to 15%, stop the migration and audit your DNS records, content, and sending patterns.
Delivery latency
Delays are an early sign of throttling. The provider is accepting mail from your new IP slowly because it does not yet trust it. Normal in week one, but if delays grow instead of shrinking, pull back volume.
Set up Google Postmaster Tools before the migration starts. If your domain is not verified yet, do that first. Data appears with a 24–48 hour lag, so you need monitoring in place before traffic moves, not after.
Mistakes that kill deliverability during migration
Switching all traffic on day one
Even with perfect DNS configuration. A sudden volume spike from a new IP reads as a spam campaign to filters. Phase the traffic over two to four weeks.
Losing your suppression list
You export contacts from the old ESP and import them to the new one — but forget the suppression list. The result: mail goes to addresses that previously complained about spam. One import like that can land a fresh IP on a blocklist within 24 hours.
Removing the old ESP's SPF/DKIM before migration ends
As long as any mail goes out through the old service — trigger sequences, transactional notifications — its DNS records must stay. Remove them only after a full cutover.
Changing your sending domain at the same time as your ESP
New IP plus new domain means zero reputation on both dimensions. If you want to change domains, treat it as a separate project: first complete the ESP migration with the old domain, then warm the new domain afterward.
Treating all mailbox providers the same
Gmail delivers fine while Outlook throttles everything. Different providers react to a new IP differently. Track metrics separately per major provider and adjust volumes per provider if needed.
Transactional and marketing mail: migrate them separately
If your old ESP handles both marketing campaigns and transactional mail (order confirmations, password resets, notifications), do not move them together.
Transactional mail is more critical to the business: a customer who does not receive an order confirmation is a lost sale. Move it last, once you are confident the new ESP is stable. Or consider a dedicated transactional service (Postmark, Amazon SES) to separate the streams entirely, which prevents marketing complaint spikes from affecting transactional delivery.
Marketing campaigns generate more complaints by nature. When both types share an IP, a bad marketing send drags down transactional delivery. Separating the streams is standard practice at 50,000+ emails per month.
Migration checklist
Work through this in order. Skipping any item is a potential deliverability problem.
- 1.Record current deliverability metrics on the old ESP.
- 2.Export and import suppression lists (bounces, unsubscribes, spam complaints).
- 3.Validate your list before importing to the new ESP.
- 4.Configure SPF, DKIM, and DMARC for the new service. Leave the old records in place.
- 5.Set up a custom tracking domain.
- 6.Send test messages and confirm SPF/DKIM/DMARC all pass in the headers.
- 7.Verify your domain in Google Postmaster Tools.
- 8.Move 10–15% of traffic (engaged subscribers) to the new ESP.
- 9.Monitor metrics daily. Compare to baseline.
- 10.Increase volume by 15–20% every three to four days.
- 11.Rebuild automations and trigger sequences on the new ESP.
- 12.Move transactional mail last.
- 13.Shut down the old ESP after full cutover and remove its DNS records.
After the migration: the first 30 days
The old ESP is off, the migration is done. But you are not in the clear yet. The first month on a new platform is when IP reputation is still settling.
Do not spike volume. If you were sending 80,000 emails a week on the old platform and reached that level by the end of the migration, hold it steady. Jumping to 150,000 "because there's a sale" can trigger throttling or spam folder placement.
Keep comparing against the baseline you recorded before the move. A 5–10% drop in open rate is normal variance. A 30% drop means something broke: DNS, segmentation, or mail going to suppressed addresses.
At the 30-day mark, run a full audit. Compare all key metrics against pre-migration numbers. If inbox placement is at the same level or better, the move worked. If it is lower, narrow it down to a specific provider and a specific segment.
Key takeaways
An ESP migration is a four-to-six week project, not a one-day technical task. It needs preparation, staged traffic transfer, and daily monitoring. Your domain retains its reputation, but a new IP needs warmup. DNS records have to be in order before the first send. Suppression lists cannot get lost. Traffic moves in stages, starting with the most engaged subscribers.
Follow that sequence and deliverability holds. If your old ESP was weak and you are moving to a platform with clean IPs and real anti-spam enforcement, inbox placement may actually improve. The migration is not a threat. It is a chance to clean house.
Validate your list before you migrate
A dirty list on a new ESP means a failed first send. Validate your addresses before import and start the migration with a clean slate.
Validate your list in uChecker