Switching ESP without losing deliverability comes down to one fact: your domain reputation follows you, your IP reputation and engagement history do not. Done right, a switch is a 6-week parallel run where the new provider takes 3% of volume in week 1 and 100% by week 6, with both sets of DNS records live the whole time. Done wrong, it is a suppression list left behind, cold IPs hit with full volume on day one, and a complaint rate that jumps from 0.05% to 0.3% inside a fortnight. I've moved sending between Mailchimp, SendGrid, Amazon SES, Mailgun and self-hosted Postfix and PowerMTA boxes, and the failures are the same every time regardless of the provider names.
This article is provider-agnostic. If your move is SendGrid to your own server, the runbook is in migrating from SendGrid to a dedicated SMTP server.
What transfers and what does not
Domain reputation transfers. IP and engagement history do not. Everything else is a data export.
| Asset | Transfers? | Why |
|---|---|---|
| Domain reputation | Yes | Gmail and Microsoft score example.com on its own, whoever carried the mail |
| IP reputation | No | The new provider's IPs are strangers to every receiver, whether shared or dedicated |
| Engagement history | No | Opens and clicks live in the old ESP's database, not in the receiver's view of you |
| Suppression lists | Only if you export them | Bounces, complaints and unsubscribes are not visible to the new ESP |
| DKIM signature | No | New provider, new key, new selector |
| Feedback loop enrolment | No | FBLs are registered per IP range, the new provider handles their own |
| Postmaster Tools data | Yes | Tied to the domain, keeps reading across the switch |
If your domain reputation reads High in Google Postmaster Tools, you arrive with the most valuable asset intact. Gmail still throttles your new IPs for a few weeks, but the throttle lifts faster than for an unknown domain. The split between the two scores is in domain reputation vs IP reputation.
If domain reputation reads Low or Bad, switching provider does not fix it. You carry the problem with you and warm cold IPs on top of it. That is the worst combination there is.
The four things that break deliverability during a switch
Every failed migration I've seen hit at least one of these.
| Failure | What happens | Typical damage | Prevention |
|---|---|---|---|
| Cold IPs at full volume | 421 and 451 deferrals within hours at Gmail and Microsoft, queue backs up | 30 to 60% of a day's mail delayed or dropped | Ramp from 3% of volume, hold when 4xx passes 5% |
| Suppression list left behind | You re-mail people who unsubscribed or complained | Complaint rate 0.05% to 0.3%+ in 7 to 10 days | Export all five lists, load before the first send |
| DKIM alignment gap | New provider signs with a different domain or no signature, DMARC fails | At p=reject, mail is refused outright; at p=none, reputation erodes quietly | Sign with your own domain on the new path, test with a Gmail Show Original before volume |
| Sudden volume shift | Receivers see the old path drop to 0 and a new path appear at 100% on the same day | Reads as a compromised domain, temporary Medium or Low reputation | Overlap the two paths for at least 4 weeks |
DKIM is the sneaky one. Many marketing platforms sign with their own domain by default, d=sendgrid.net instead of d=yourdomain.com. That passed DMARC only because SPF aligned through their bounce domain. Change the bounce domain on the new provider and neither aligns, and p=reject does what it says. Verify alignment on a 50-message test batch before anything real moves.
The parallel-run method
Run both providers at once and move a share of volume each week. The old provider stays live as your rollback path. Assumes around 30,000 a day; scale the percentages, not the calendar.
| Week | Old ESP share | New ESP share | New path daily volume | Segment on the new path |
|---|---|---|---|---|
| 0 | 100% | 0% | 50 seeds | Internal and seed addresses only |
| 1 | 97% | 3% | ~900 | Opened or clicked in the last 30 days |
| 2 | 85% | 15% | ~4,500 | Engaged in the last 90 days |
| 3 | 60% | 40% | ~12,000 | Engaged in the last 180 days |
| 4 | 25% | 75% | ~22,500 | Full list minus 12-month inactives |
| 5 | 5% | 95% | ~28,500 | Everything except transactional |
| 6 | 0% | 100% | 30,000 | All mail, old ESP idle for 7 clean days |
Two rules. First, the new path only gets your most engaged people early on. Week 1 is 900 messages to people who opened last month, not 900 random addresses. Second, split by recipient, not by campaign, so you get a same-day comparison of delivered rate per provider.
Week 5 is the one people skip. Leaving transactional mail on the old provider one more week costs a few dollars and gives you a fallback if the new IPs hit a blocklist. The per-IP ramp numbers are in IP warm-up schedule explained.
DNS sequencing
Add before you remove. Remove only after the last message has left the old provider.
| Record | Week 0 (before first send on the new path) | Week 6 (after old ESP goes idle) |
|---|---|---|
| SPF | Add the new provider's include or ip4: entries next to the old include | Remove the old include |
| DKIM | Add a new selector with the new provider's key, distinct name from the old one | Remove the old selector's TXT or CNAME |
| DMARC | No change | No change until reports show 2 weeks of full alignment on the new path |
| Return-Path / bounce domain | Add the new provider's bounce CNAME on a fresh subdomain | Remove the old bounce CNAME |
| Tracking domain | Add the new click-tracking CNAME | Remove the old one after the last old campaign's links expire |
| PTR (dedicated IPs only) | Set reverse DNS on every new IP before day 1 | No change |
Two traps. SPF has a 10 DNS lookup limit and most domains sit at 7 or 8 already, so a second include can push you into PERMERROR, which Gmail treats as a fail. Use ip4: entries where the new provider publishes fixed IPs, or flatten the old include for now. And if you are at p=reject, do not loosen it for the migration. Test alignment on the seed batch in week 0 instead.
How to measure during the switch
You need per-path numbers. A blended 98% delivered rate hides a new path running at 91%.
| Metric | Where to read it | Green | Hold volume | Roll back |
|---|---|---|---|---|
| Domain reputation | Postmaster Tools, Domain reputation tab | High | Medium for 3+ days | Low |
| IP reputation (new path) | Postmaster Tools, IP reputation tab | Medium climbing to High by week 3 | Medium flat for 2 weeks | Low or Bad |
| 4xx deferral rate | New provider's logs, per day | under 2% | 5 to 15% | over 15% for 24 hours |
| Complaint rate per path | Postmaster Tools spam rate plus provider FBL | under 0.1% | 0.1 to 0.3% | over 0.3% |
| Delivered rate per mailbox provider | Both ESPs' dashboards, side by side | within 1 point of the old path | 1 to 3 points behind | more than 3 points behind |
| Hard bounce rate on the new path | New provider's dashboard | under 1% | 1 to 2% | over 2% |
During a switch you expect IP reputation on the new path to start at Medium or lower and climb. You do not expect domain reputation to move at all. If it does, the usual cause is the suppression list. How to read the graphs is in the Google Postmaster Tools guide.
Google's bulk sender requirements put the complaint line at 0.3% with 0.1% as the target, and require SPF, DKIM and DMARC on every path. Both providers count toward the same domain-level spam rate, so a bad week on the new path drags the old path too.
What to export from any ESP
Do this before you sign the new contract. Some platforms cut API access the day you downgrade.
- Hard bounces. Every address that returned a 5xx. Re-mailing these on cold IPs is the fastest route to a 5% bounce rate.
- Spam complaints. Every FBL hit. Each one repeats if you mail it again.
- Global unsubscribes. A legal obligation under CAN-SPAM and GDPR.
- Per-list unsubscribes. Easy to miss because they sit under each list.
- Blocks. Receiver-side rejections the old ESP stopped retrying.
- 90 days of engagement events. Opens and clicks with timestamps, to rebuild the 30, 90 and 180-day segments.
- Delivered rate per mailbox provider. Your baseline. Knowing Gmail delivered 98.4% on the old path is what tells you 96% on the new path is a problem.
- Templates and the unsubscribe link logic. Especially the one-click
List-Unsubscribeheader, which platforms inject silently and raw SMTP does not.
Use the API for the suppression exports, not the UI. Dashboards paginate and people miss pages. On a 200,000 address list the five exports combined usually run 5,000 to 15,000 addresses.
Which switches are risky
The type of IP you are leaving and the type you are moving to matters more than the provider names.
| Switch type | Risk | Warm-up needed | What you lose | Example |
|---|---|---|---|---|
| Shared pool to shared pool | Low | 1 to 2 weeks | Nothing much, the new pool is already warm | Mailchimp to Klaviyo, Mailgun to SendGrid |
| Shared pool to dedicated IPs | Medium | 4 to 6 weeks | Time, while the dedicated IPs build history from zero | SendGrid shared to Amazon SES dedicated, or to your own server |
| Dedicated to dedicated | High | 4 to 6 weeks, re-warm at full existing volume | The entire IP reputation you spent months building | Own Postfix box to a new host, SES dedicated to Mailgun dedicated |
| Marketing platform to raw SMTP | Medium on reputation, high on operations | Depends on IP type | The tooling: unsubscribe handling, bounce parsing, FBL processing, segmentation | Mailchimp or Klaviyo to a self-hosted MTA |
Dedicated-to-dedicated surprises people. You already send 100,000 a day and your domain is warm, yet the new IPs still start at a few hundred each. The only shortcut is keeping the old IPs live for the whole overlap.
Marketing platform to raw SMTP is the opposite. What bites is finding in week 2 that nothing is processing bounces into a suppression table, because the platform did that silently. SendGrid vs a dedicated SMTP server walks through what the platform was doing for you.
Timelines by switch type
| Switch type | Preparation | Parallel run | Total to full volume |
|---|---|---|---|
| Shared to shared, under 5,000/day | 2 to 3 days | 1 to 2 weeks | about 2 weeks |
| Shared to shared, over 50,000/day | 1 week | 3 to 4 weeks | about 5 weeks |
| Shared to dedicated | 1 week | 6 weeks | 7 weeks |
| Dedicated to dedicated | 1 week | 6 weeks | 7 weeks |
| Marketing platform to raw SMTP | 2 to 3 weeks (engineering) | 6 weeks | 8 to 9 weeks |
Add 2 weeks to any row if you cannot run both providers in parallel, because you have no rollback and must ramp more slowly. Add 4 weeks if domain reputation reads Low before you start, because you are repairing and migrating at once and the ramp has to be half speed.
How BulkEmailSetup helps
We build the dedicated side of a switch: your own server, your own IPs, SPF/DKIM/DMARC/PTR configured with selectors that do not clash with your current provider's records, bounce and complaint parsing wired to a suppression table you can load your exports into, and a warm-up schedule sized to your list. You run the parallel-run table at your pace with both paths live, and the reputation you build belongs to you rather than to the next provider you leave.
Basic is $549 one-time, covering 1 SMTP server, 3 dedicated IPs, 25,000 emails/day and unlimited contacts. Higher tiers scale to 15 IPs and 200,000 emails/day. See pricing, or start with migrating from SendGrid to a dedicated SMTP server if that is the specific move you are planning.
Frequently asked questions
Does my sender reputation transfer when I switch ESP?
Partly. Domain reputation transfers, because Gmail and Microsoft score your sending domain on its own and do not care which provider carried the mail. IP reputation does not transfer, because the new provider's IPs are new to every receiver. Engagement history also stays behind, so segmentation built on opens and clicks has to be re-exported before you leave.
How long does it take to switch ESP safely?
Plan for 6 weeks of parallel sending plus a week of preparation. The new path starts at around 3% of daily volume in week 1 and reaches 100% by week 6. Senders under about 5,000 a day can compress this to 2 to 3 weeks. Senders moving from shared IPs to dedicated IPs should not compress it at all, because the dedicated IPs start with zero history.
Which ESP switches are the riskiest for deliverability?
Dedicated IP to dedicated IP is the riskiest because you re-warm from zero while your volume is already high. Shared pool to shared pool is the safest, since the new provider's pool already has reputation and you only need 1 to 2 weeks of ramp. Shared to dedicated sits in between: a full 4 to 6 week warm-up, but you finish with reputation you control.
What must I export from my old ESP before I cancel?
Five lists at minimum: hard bounces, spam complaints, global unsubscribes, per-list unsubscribes and blocks. Then the last 90 days of open and click events, your templates, and your delivered rate per mailbox provider as a baseline. On a 200,000 address list the combined suppression export is usually 5,000 to 15,000 addresses, and every one of them hurts if it leaks back in.
Should I change my DMARC policy during an ESP migration?
No. Leave DMARC exactly where it is until the new path has shown 100% alignment in the aggregate reports for two full weeks. Add the new SPF entries and a new DKIM selector before you send anything through the new provider, keep the old provider's records live for the whole parallel run, and remove them only after the last message has left the old system.
How do I know the switch is hurting deliverability?
Three numbers, checked daily. A 4xx deferral rate on the new path above 5% means you are ramping too fast. A complaint rate above 0.1% at Gmail on the new path means the suppression list did not come across cleanly, and 0.3% is Gmail's hard limit. A Postmaster Tools domain reputation drop from High to Medium within the first two weeks means both of those together.
