Switching ESPs without killing deliverability

Every CMO has the same migration story: "our previous ESP was expensive, the new one promised the same deliverability, we cut over on a Friday, and our open rates fell off a cliff the next Tuesday." The cliff is real and predictable. ESP migration is one of the highest-risk operations in email marketing, and the failure mode (slow degradation across weeks rather than a single visible incident) makes it hard to attribute. This is the playbook that prevents the cliff.

Why a flip-the-switch cutover fails

Three things change simultaneously when you migrate ESPs. First, the sending IP changes. Even on a dedicated IP from the new ESP, the IP has no recipient history — Gmail treats it as untrusted until it accumulates engagement. Second, the authentication chain changes. SPF includes update, DKIM keys rotate, the new ESP's DKIM domain becomes the alignment anchor for DMARC. Third, the message rendering and headers change, often in subtle ways that affect spam scoring.

Recipients see all three changes at once and mailbox providers respond by treating you as a new sender even though your recipient list and content have not changed. The result is a 4-6 week reputation rebuild, during which inbox rate sags by 20-40 points and open rates fall accordingly.

The mistake is treating ESP migration as an IT cutover instead of a deliverability operation. The IT side (data export, list import, template port) is the easy part. The deliverability side requires graduated traffic shifting and active reputation building on the new platform.

The 4-week dual-send window

The migration unit is the week. Each week, a defined percentage of your sending volume moves from the old ESP to the new ESP, with the same campaigns running on both platforms during the transition. The standard schedule:

• Week 1: 90% old / 10% new. New ESP sends to your most engaged decile only — recipients with 30-day open rates above 60%. These recipients tolerate the new sending IP and generate strong engagement signals from day one.
• Week 2: 70% old / 30% new. Expand the new ESP to all 30-day engaged recipients. Continue to send your weakest segments through the old ESP.
• Week 3: 40% old / 60% new. New ESP now handles the majority. Monitor Postmaster Tools daily for the new ESP's sending domain.
• Week 4: 10% old / 90% new. Old ESP retains only the lowest-engagement segments (which would otherwise damage the new ESP's reputation while it is still building).
• Week 5: 0% old / 100% new. Full cutover. Optionally retain old ESP for two more weeks as a rollback safety net.

Dual-sending the same content from two platforms is billed twice for those weeks — that is the cost of safe migration. The alternative (a 6-week deliverability depression) costs revenue worth far more than four weeks of double ESP fees.

IP warmup at the new ESP

The dual-send schedule above is also an IP warmup curve for the new ESP's IP (whether dedicated or shared within the ESP's pool). Starting at 10% of normal volume, the IP receives gradual exposure to your recipient base. By week 4, it is at 90% of normal volume — a natural ramp that mailbox providers interpret as legitimate growth, not as a spam burst.

For dedicated IPs at high-volume senders, even the 4-week ramp may be too aggressive. ESPs like SendGrid, Mailgun and SparkPost recommend 6-week ramps for sends above 500,000/day. Adjust the dual-send schedule accordingly: 95/5, 85/15, 70/30, 50/50, 25/75, 0/100 across six weeks instead of four.

On shared IP pools (Mailchimp, Klaviyo, ActiveCampaign, Brevo), the IP itself has reputation from other senders. Your warmup is more about establishing your domain on that IP pool than warming the IP itself. The 4-week schedule still applies because Gmail and Outlook track per-domain reputation independently of IP.

Staging DNS: SPF, DKIM, DMARC

DNS changes need to be live before the new ESP starts sending. Specifically:

• SPF: add the new ESP's include statement alongside the old one. Both ESPs need to be authorised during dual-send. Watch the 10-DNS-lookup limit; SPF flattening may be required.
• DKIM: publish the new ESP's DKIM public key at the selector they require. The old ESP's DKIM remains active for the same period. Each ESP signs its own messages with its own key.
• DMARC: if you have a strict policy (p=quarantine or p=reject), test the new ESP's alignment in monitoring mode for the first week. Both ESPs must produce DMARC-aligned mail or one of them will be quarantined.
• Return-Path / Bounce domain: typically the new ESP requires its own bounce subdomain. Set up the CNAME records they specify and verify in their console.
• BIMI: if you have BIMI live, the BIMI record is domain-level and continues to apply across both ESPs as long as DMARC alignment is maintained on both.

Schedule DNS changes 48 hours before the first dual-send. DNS propagation across global resolvers can take that long, and starting sends before propagation results in SPF failures and DKIM mismatches that look exactly like a spammer.

The 48-hour rollback plan

Things go wrong. Plan for it. The rollback plan should include:

• Old ESP account remains active and billable through week 6 minimum. Do not cancel until full migration stability is confirmed.
• List sync runs in both directions: subscribers added to the new ESP also appear in the old ESP for the migration period. If you have to roll back, the old ESP's list is current.
• Defined rollback triggers: inbox rate drops below 70% at any major provider for two consecutive sends, OR Postmaster reputation drops to Bad, OR complaint rate exceeds 0.4% for two consecutive sends.
• Single decision-maker for rollback. The deliverability lead, not a committee. Migration projects with rollback decisions distributed across stakeholders never roll back fast enough to matter.

A clean rollback within 48 hours of detection rebuilds the old ESP's reputation in 1-2 weeks and avoids the multi-month damage of a stalled migration.

Active monitoring through migration

Daily metrics during migration weeks:

• New ESP domain reputation in Postmaster Tools. Should climb from Low to Medium within 7-10 days, Medium to High within 21-28 days.
• Inbox-placement test results across 20+ providers. Run twice weekly for the first 4 weeks, then weekly.
• Bounce and complaint rates per ESP. Compare new vs old to detect any segment that responds badly to the new sending pattern.
• Open and click rates per ESP. Engagement on the new ESP should match or exceed the old ESP within 2 weeks for the engaged segments. If not, investigate rendering differences first.
• Deferral and throttling logs. New ESPs sometimes get throttled by Gmail or Yahoo for the first 7-10 days at higher volumes.

Post-migration: closing out the old ESP

After 6 weeks of stable sending on the new ESP with deliverability metrics matching pre-migration baselines, the old ESP can be retired. The cleanup checklist: remove the old ESP's SPF include (do not leave dead includes — they consume DNS lookups), revoke the old DKIM key (publish it as a deprecated key for 30 days first to handle in-flight mail), update internal documentation, archive the old ESP's campaign data for compliance retention, and only then cancel the billing.

Keep the old ESP's suppression list — it is more valuable than most people realise. Recipients who complained or unsubscribed at the old ESP need to remain suppressed at the new ESP. Most ESPs will import a suppression list during onboarding; verify the import completed before the first dual-send.

Frequently asked questions