Email Deliverability Problems: Why Switching ESPs Won't Fix Them

Here is a conversation we have every single week. A sender's open rates collapse, their mail starts landing in spam, and their first instinct is to blame the platform: "Mailchimp ruined our deliverability, we are moving to Brevo." Three months and one painful migration later they are back in the spam folder, minus the migration cost. Email deliverability problems almost never live in the ESP, because the two things mailbox providers actually judge (your domain's reputation and your list's quality) move with you to the new platform on day one. We are SpamCipher, the cold email platform built for unlimited email sending and automated cold email, and the only platform that can promise you 90%+ inbox placement. We make that promise precisely because we fix the things a platform switch cannot touch. This guide explains what actually causes deliverability problems, why the migration honeymoon always ends, the five legitimate reasons to switch anyway, and the six-step diagnostic that finds your real problem before you spend a quarter moving vendors.

The most expensive mistake in email

Switching ESPs to fix deliverability is expensive in every direction at once. The migration itself burns weeks: exporting lists, rebuilding templates and automations, re-wiring integrations, retraining the team. The new platform's IPs and sending patterns force a re-warm-up period where volume has to ramp carefully. And the opportunity cost compounds quietly: every week spent migrating is a week not spent fixing the actual cause, which means the problem is often worse by the time the new platform is live.

The reason this mistake is so common is that it feels rigorous. Migrating is hard, visible work, and hard work feels like it should fix hard problems. But mailbox providers do not grade effort, they grade signals, and the signals that put you in the spam folder (bounces, complaints, spam-trap hits, dead engagement) are generated by your list and your practices, not by your vendor's logo. Move the same list and the same practices to a new vendor and you have relocated the problem, not solved it.

There are real cases where the ESP is the problem, and we cover them honestly below, because pretending otherwise would be its own kind of dishonesty. But they are the minority, and every one of them is checkable in an afternoon. The six-step diagnostic later in this piece is that afternoon. Run it before you sign the migration contract, not after.

What actually causes email deliverability problems

When mail lands in spam, one or more of six causes is responsible, and they are worth ranking by how often we actually see them. Notice as you read that only one of the six belongs to the platform.

• 1. List quality. The most common cause by a wide margin. Lists decay at roughly 2-3% per month, purchased and scraped lists arrive with double-digit invalid rates, and every dead address is a future hard bounce. Cross the 2% bounce line that Gmail, Outlook, and Yahoo enforce and filtering begins; hit a recycled spam trap and a blacklist can follow. If your list has not been through real validation recently, this is the first suspect, and it follows you to any ESP on earth.
• 2. Domain reputation. Mailbox providers keep a running score on your sending domain, built from your bounce rate, complaint rate, spam-trap hits, engagement, and volume history. This is the single most misunderstood fact in this topic: the score is attached to your domain, not to your platform. A domain that earned a bad reputation on ESP A carries that reputation, in full, to ESP B. The mechanics are covered in Sender Reputation 101; the short version is that reputation is a ledger, and switching vendors does not zero a ledger kept by Google.
• 3. Engagement collapse. Providers rank your mail partly on how recipients treat it: opens, replies, and moves-to-inbox push you up; deletes-without-reading and ignores push you down. A tired list that stopped engaging drags placement down slowly and invisibly, and no infrastructure change re-interests a bored audience.
• 4. Complaint rate. The 0.3% spam-complaint ceiling is the hardest line the providers enforce. Complaints come from sending people mail they did not expect or cannot easily escape: no visible unsubscribe, misleading subjects, wrong frequency. All of that is content and practice, none of it is platform.
• 5. Broken or missing authentication. SPF, DKIM, and DMARC are mandatory for bulk senders since 2024, and a failed or misaligned record suppresses deliverability across the board. This one is a genuine infrastructure cause, but it lives in your DNS, not in the ESP, and it migrates with you unless someone actually fixes the records. Our authentication guide walks every record.
• 6. Shared infrastructure, the one real ESP cause. On a shared IP pool, you inherit some reputation from your pool neighbors. If your ESP tolerates spammers on your pool, their behavior taxes your placement. This is real, it is checkable, and it is the legitimate core of the switching argument, but note how far down the list it sits, and that dedicated IPs or a cleaner pool fix it without a migration more often than not.

What your ESP controls, and what it never touches

The clean way to think about any deliverability decision is to sort the variables by who owns them. The split is starker than most senders expect.

The ESP genuinely controls:

• Its IP pools and their hygiene: whether spammers get onboarded, policed, and evicted from the shared ranges you send on.
• Bounce and feedback-loop processing: how fast hard bounces and complaints get suppressed automatically, and whether suppression is global or per-campaign.
• Throttling and retry behavior: how sensibly it paces delivery to each provider, backs off on deferrals, and smooths volume spikes.
• Technical send quality: correct MIME construction, working one-click unsubscribe headers, DKIM signing done right.

The ESP never touches:

• Your list: who is on it, how it was built, how much of it is dead, and whether it gets validated before sends.
• Your domain reputation: the providers' ledger on you, earned by your history and carried in your DNS name.
• Your authentication records: SPF, DKIM keys, and DMARC policy live in your DNS zone and are your responsibility.
• Your content and practices: subject honesty, frequency, expectation-setting, unsubscribe visibility, segmentation.
• Your audience's interest: whether anyone actually wants the mail, which is the engine behind every engagement signal.

Read the two lists again and the pattern is hard to miss: everything in the second list is a top-five cause of deliverability failure, and everything in the first list is either rarely the culprit or fixable without migrating. This is why the switch so rarely works. It replaces the variables that were probably fine and keeps the variables that were probably broken.

The migration honeymoon, and why it always ends

The cruelest part of the switch-the-ESP cycle is that it appears to work at first, which convinces teams the diagnosis was right just in time for the relapse. Three mechanical reasons create the honeymoon.

• New IPs, briefly unjudged. Your mail leaves from addresses with no negative history yet. Provider filters give new sources a short evaluation window, so placement genuinely improves for a few weeks while the filters gather data on the new path.
• The forced re-warm-up. The new ESP makes you ramp volume slowly, which means your worst habits (the big blast to the whole stale list) are temporarily suspended. Lower volume to your most engaged segment looks like better deliverability, because it is, and it would have been on the old platform too.
• The accidental list cleaning. Migrations drop hard-bounced and suppressed addresses in the export, and importing often re-validates in passing. The list arrives slightly cleaner than it left, again producing a real but unearned improvement.

Then the evaluation window closes, volume ramps back to the full list, and the same bounces, complaints, and dead engagement re-accumulate on the new IPs, now attributed to the same old domain. Placement slides back toward exactly where it was, usually within one to three months. The chart of this cycle is so consistent that we can draw it from memory.

If you have lived this curve, the takeaway is not that you were foolish; it is that the temporary lift was evidence about the cause. The improvement came from lower volume, cleaner data, and unjudged infrastructure. All three are achievable on purpose, on any platform, without a migration: send less to better segments, validate the list, and warm new sending domains deliberately.

The five cases where switching is justified

Honesty requires the other side of the argument, because sometimes the platform genuinely is the problem. Switch when one of these is true and confirmed, not suspected.

• 1. Your shared pool is dirty and the ESP will not fix it. If blacklist checks show the shared IPs you send from are chronically listed, and support's answer is a shrug rather than a pool move or a dedicated IP, the platform is taxing you. Confirmed pool problem plus unresponsive vendor is a real reason to leave.
• 2. Missing table-stakes authentication support. Any platform that cannot sign DKIM with your own domain, align SPF properly, or attach one-click unsubscribe headers is below the 2024 bulk-sender bar. This is rare among serious vendors now, but it exists in the long tail.
• 3. Broken bounce and complaint handling. If hard bounces keep getting mailed, or feedback-loop complaints do not suppress automatically, the platform is actively manufacturing reputation damage in your name.
• 4. No throttling or scheduling control. Senders with real volume need pacing per provider and the ability to smooth spikes. A platform that dumps a million messages at Gmail in ten minutes hurts you structurally.
• 5. You cannot measure anything. If the platform gives you no bounce detail, no complaint reporting, and no way to test placement, you are flying blind, and blind senders drift into trouble. Measurement is not a luxury feature; it is the steering wheel.

Notice the shape of all five: they are specific, checkable claims about the platform's behavior, not vibes about deliverability. If your reason to switch cannot be phrased as one of these, the diagnostic below will almost certainly find the real problem somewhere the migration cannot reach.

Diagnose your email deliverability problems in six steps

This is the afternoon of work that saves the quarter of migration. Run the steps in order; each one either clears a suspect or finds your cause.

• Step 1: check authentication. Verify SPF, DKIM, and DMARC all pass and align for your actual sending domain (send yourself a message and read the authentication results in the headers, or use a domain health checker). A DMARC policy of p=none with failing alignment, or a missing DKIM signature, is a finding: fix the records before judging anything else. Full walkthrough in the authentication guide.
• Step 2: check the blacklists. Look up both your domain and your sending IPs against the major blocklists. A domain listing points at your list or content; an IP-only listing on a shared pool points at your neighbors, which is evidence for a pool conversation with your ESP, not necessarily a migration.
• Step 3: audit the bounce ledger. Pull bounce rates for the last ten campaigns. Over 2% on any of them is a list-quality finding, and a rising trend is worse than one bad send. Sudden spikes have their own playbook: see why are my cold emails suddenly bouncing.
• Step 4: audit complaints and unsubscribes. Complaint rate above 0.1% deserves attention and above 0.3% is an emergency. Compare complaint spikes against what you sent: a specific campaign, a new list segment, a frequency change. Complaints almost always trace to a decision you can name.
• Step 5: segment your engagement. Split the last 90 days of recipients into engaged (opened, clicked, or replied) and unengaged. If the unengaged share is over half your volume, you have found the slow poison: you are training providers that your mail gets ignored. This finding alone explains most "gradual decline" stories.
• Step 6: measure real placement with seeds. Send to seed accounts across Gmail, Outlook, and Yahoo and see where mail actually lands: inbox, Promotions, or spam, per provider. This turns the vague feeling of "deliverability is bad" into a number per provider, gives you the baseline every fix gets measured against, and is the ground truth that open rates can no longer provide. It is exactly what seed-based inbox placement testing exists for.

When the diagnostic finishes you will have one of three outcomes. Most commonly, you find list or engagement problems, which no migration fixes. Occasionally you find an authentication or DNS problem, which takes an hour to fix and no migration. Rarely, you find a genuine platform failure from the justified-switch list, in which case switch with our blessing, but fix the list first anyway, because a dirty list will burn the new platform exactly as fast.

The fix that actually holds

The durable fix is boring, which is why the migration is more popular: it is the pipeline, run in order, on whatever platform you use.

• Validate before every send, so bounces stop at the gate. Remove invalid, hold risky, keep verified; the whole discipline in what is email validation.
• Fix and monitor authentication, so identity never subtracts from you again. SPF, DKIM, DMARC aligned and moving toward an enforcing policy.
• Sunset the unengaged, so your volume concentrates on people who actually read you, and providers see a sender whose mail gets wanted. Re-permission or remove anyone dark for 90+ days.
• Warm anything new deliberately: new domains and mailboxes ramp with real engagement before campaign volume touches them.
• Measure placement continuously with seeds, so improvement and regression are numbers you see this week, not open-rate folklore you interpret next quarter. The rest of the scoreboard worth watching is in the deliverability metrics that actually matter.

This pipeline is exactly what SpamCipher is: validation gating every list, an owned warm-up network building real engagement history, an abuse monitor that throttles risk before providers have to, and seed accounts measuring true placement across Gmail, Outlook, and Yahoo on every campaign. We built the whole chain into one platform because the chain, not any single link, is what fixes deliverability, and that is what makes us the cold email platform that can promise unlimited, automated sending with 90%+ inbox placement, measured rather than hoped. The full architecture is in how to own the inbox at 90%+.

So before you sign the migration paperwork, spend the afternoon on the diagnostic. Your email deliverability problems are almost certainly in the list, the domain ledger, or the engagement pattern, and every one of those travels with you. Fix the pipeline once and it holds on any platform. Fix only the platform and you will be reading this article again in a quarter.

Frequently asked questions