Delivery vs deliverability — why the difference matters

Mailchimp advertises a delivery rate of over 99%. That number is accurate. It means 99%+ of emails you send reach the recipient's mail server. The server accepted them. They didn't bounce at the door.

But deliverability is a different measurement entirely. Deliverability is whether your email reaches the recipient's inbox — not their spam folder, not their promotions tab, not a silent void where the email lands and is never seen. Mailchimp's 99%+ delivery rate says nothing about inbox placement.

This distinction matters because the entire goal of email marketing is for someone to read your email. An email that reaches a spam folder with 99% reliability is still a failure. When clients tell me "my Mailchimp deliverability is broken," they nearly always mean inbox placement — and that's a different problem with a different fix.

The practical difference: You can have perfect delivery and terrible deliverability at the same time. Fixing the wrong one wastes time. Every diagnosis starts by confirming which one is actually broken.


The four layers where Mailchimp deliverability breaks

After working with Mailchimp campaigns for 18+ years, I've found that nearly every deliverability problem traces back to one of four layers. The mistake most people make is treating them as equally likely or equally urgent. They aren't. Some layers cause others to fail. The sequence matters.

Layer What it covers Impact if broken
01 Infrastructure Fix first SPF, DKIM, DMARC, domain age, IP reputation Emails rejected or bulk-foldered by receiving servers regardless of content quality
02 List health Bounce rates, invalid addresses, low-engagement segments Damages sender reputation over time; shared IP issues amplify this
03 Content structure Image-to-text ratio, HTML quality, spam trigger patterns Triggers content filters; compounds infrastructure problems
04 Sending behaviour Most ignored Volume consistency, cadence, engagement-tier segmentation Erodes reputation gradually; hard to reverse once damaged

Most deliverability guides address layer 3 (content) first — because it's the most visible. The advice sounds reasonable: avoid spam words, fix your image ratio, don't use red text. But if your infrastructure is broken, cleaner content won't move the needle. If your list is dirty, a beautiful template still signals poor sender behaviour to ISPs.

Fix infrastructure first. List second. Content third. Sending behaviour runs parallel to all of them.


The shared IP problem nobody explains properly

By default, Mailchimp sends your emails from a shared IP pool — meaning your campaigns go out from the same IP addresses as thousands of other Mailchimp users. This is normal, and for most senders it works fine. But it comes with a specific risk that most articles fail to explain clearly.

Your inbox placement is partly determined by the reputation of the IP sending your email. On shared IPs, that reputation is collective. If other senders in your pool have high bounce rates, spam complaints, or bad list hygiene — their behaviour affects your placement. You don't control the IP. You don't know who else is using it.

Mailchimp manages this by aggressively monitoring the pool and removing bad senders, but the system isn't perfect. In practice, the way to protect yourself on shared IPs is to be a better-than-average sender. That means:

When does a dedicated IP make sense? Mailchimp recommends a dedicated IP at 100,000+ emails per month. Below that, a dedicated IP often hurts more than it helps — the IP lacks sending history and ISPs treat it with higher suspicion. A proper warmup schedule takes 4–8 weeks. If you go dedicated, don't rush it.


SPF alignment failure — the most common hidden issue

This is the issue I find most often when auditing Mailchimp accounts that are "set up correctly." The client has an SPF record. They have DKIM enabled. They have a DMARC policy. Everything looks right. And yet emails are still being filtered. The problem is alignment — not the presence of the records, but whether they're working together.

Here's what's happening under the hood. Mailchimp uses its own domain (mcsv.net) for the return-path of your emails by default. The return-path is the address used in SPF checks. So even if your SPF record authorises your own domain perfectly, the SPF check happens against Mailchimp's domain — not yours. SPF fails alignment.

DMARC requires either SPF or DKIM to be in alignment with your From domain to pass. If SPF isn't aligned and DKIM isn't set up or configured correctly, DMARC fails. A strict DMARC policy (p=reject) means those emails get rejected outright. A quarantine policy means they go to spam.

The fix is custom domain authentication in Mailchimp — publishing the CNAME records Mailchimp provides to your DNS, which aligns DKIM with your sending domain. Once DKIM is aligned, DMARC passes even if SPF isn't. This is a one-time setup. The mistake is assuming it's done just because the fields exist in your Mailchimp account. Verify passing — don't just verify presence.

How to verify: Use MXToolbox's Email Header Analyzer on a sent campaign. Check that DKIM shows "PASS" and alignment shows "yes" — not just that DKIM exists. A common mistake is seeing "DKIM: PASS" and assuming alignment is fine. Check alignment separately.


How a dirty list kills a clean infrastructure

Even if your authentication is perfect, a neglected list will degrade your sender reputation over time. This happens gradually, which is why it's easy to miss until something breaks. ISPs track engagement signals — opens, clicks, replies, and spam complaints — and use them to make inbox placement decisions for future sends.

A list that includes a significant proportion of invalid addresses, disengaged contacts, or contacts who never opted in creates a pattern that looks like spam behaviour from the ISP's perspective. High bounce rates signal poor list management. Low engagement signals low relevance. Spam complaints signal that recipients didn't want the email. Each of these erodes reputation.

Mailchimp handles hard bounces automatically — addresses that produce a permanent delivery failure are suppressed after one occurrence. But it doesn't proactively clean low-engagement contacts from your active list. That responsibility sits with you.

What list hygiene actually involves

Real list hygiene isn't just removing bounces. It's a structured process:

One thing most articles miss: List cleaning before a large send is not the same as ongoing list hygiene. Cleaning once and then sending to an ungated list for another year defeats the purpose. Hygiene is a system, not a one-off task.


HTML structure and content spam triggers

Content filtering happens at two distinct levels — the platform level (Mailchimp's own Omnivore system) and the ISP level (Gmail, Outlook, Yahoo's filters). These use different signals, and passing one doesn't guarantee passing the other.

The most common HTML issues I see in Mailchimp campaigns:

The standard I use is Litmus for rendering across 90+ clients before any significant send. Not because "looks fine" in the preview window is insufficient — it is — but because real rendering testing catches the broken Outlook layouts and heavy-image templates that drag down engagement data over time.


Sending behaviour — the layer most people ignore

Infrastructure and list get most of the attention. Sending behaviour is the layer that quietly determines long-term reputation, and the one that takes longest to repair once damaged.

ISPs look at patterns over time. A sender who blasts the full list once a month, then disappears for six weeks, then sends again to a slightly different segment looks different to a filter than a sender with a consistent, cadenced programme. Volume spikes — sending ten times more than usual in one go — trigger additional scrutiny regardless of authentication status.

For large lists, staggered sending is not optional. Sending 70,000 emails in a single batch from a shared IP at the same time as hundreds of other senders produces queuing delays, delivery variation, and reputation pressure. Distributing sends across time windows — by engagement tier, geography, or domain — produces more consistent placement and protects reputation under volume.

What consistent sending behaviour looks like


How to diagnose your Mailchimp deliverability problem

The diagnostic process matters as much as the fix. Changing multiple things at once makes it impossible to know what worked. The process I follow with every client is the same regardless of the presenting symptom.

  1. Check infrastructure first. Verify SPF, DKIM, and DMARC records exist, are syntactically valid, and are actually passing — not just present. Use MXToolbox for DNS verification and check email headers from a live send to confirm alignment
  2. Assess list composition. Pull a report on bounce rates, unsubscribe rates, and spam complaint rates from recent campaigns. Check when the list was last validated against an external tool. Identify the percentage of contacts that haven't engaged in 90+ days
  3. Review campaign HTML. Check image-to-text ratio, link count, file size, and rendering across major clients. Run a spam score test (Mail Tester or GlockApps) before the next send
  4. Examine sending history. Look at volume patterns over the last 6 months. Identify any spikes, long gaps, or changes in audience composition that correlate with placement changes
  5. Check Google Postmaster Tools if Gmail is your primary concern. Domain reputation and IP reputation data there is more reliable than any third-party tool for diagnosing Gmail-specific placement issues

One rule: Fix one thing at a time and measure the result before the next change. Deliverability diagnosis requires controlled conditions. If you fix authentication, rebuild your list, and redesign your templates simultaneously, you won't know which change moved the needle — and you'll be guessing if the problem returns.


Real cases — what the problems actually looked like

Case study · Mailchimp · Scale

One million unique barcodes without breaking deliverability

A client needed a unique, scannable barcode embedded in every single email sent to one million recipients. No native Mailchimp feature supports this — the platform doesn't generate unique merge values at this scale. The challenge wasn't just generating the barcodes; it was embedding them correctly in every recipient's email without increasing file size to the point where spam filters flagged the campaigns, and without breaking rendering across clients.

The solution required building a generation and merge system outside Mailchimp, then feeding the output back in a way the platform could process at scale. The entire infrastructure was architected around maintaining deliverability — file size, image hosting, authentication — throughout. The result: zero rendering failures and a delivery rate above 99%.

1,000,000
Unique barcodes generated
0
Rendering failures
99%+
Delivery rate maintained
Case study · Deliverability · Large list management

70,000+ contacts — staggered sending and reputation protection

A client with 70,000+ contacts was sending full-list campaigns in a single batch. Open rates had been declining for three months and spam complaint rates were creeping up. The infrastructure was fine — authentication was correct, list was reasonably clean. The problem was sending behaviour.

Sending the full list at once created volume pressure on the shared IP pool and produced a spike pattern that ISPs flagged as atypical. The fix was a segmented sending architecture: contacts divided into engagement tiers, sent in sequence across a defined time window. Tier 1 (highest engagement) first, then tier 2, then re-engagement candidates. Each tier's performance was monitored before the next batch went out. Sender reputation stabilised within two campaign cycles.

70k+
Contacts under management
Stable
Sender reputation after fix
2
Campaign cycles to recover

What Mailchimp gets right — and where you still need to do the work

Mailchimp is a well-built platform for the volume it's used at. The infrastructure is solid. The sending reputation of the shared pool is actively managed. The authentication tooling, once configured correctly, works as expected. For senders who approach it as a system — not just a campaign tool — it performs reliably.

The problems I see consistently aren't Mailchimp's fault. They're the result of treating email as a broadcast medium rather than a system with inputs and outputs. That's what I call Vibe Mailing — operating on dashboard metrics and intuition rather than infrastructure thinking. List growth without list management. Authentication setup without authentication verification. Volume increases without warmup. Campaign launches without pre-send testing.

Deliverability isn't a feature you turn on. It's an outcome of building the system correctly and maintaining it over time. Mailchimp gives you the tools. Using them in the right order — and knowing what "working" actually looks like in practice — is what determines whether your campaigns reach inboxes.

If you're working through a deliverability problem and the standard advice isn't moving it, the answer is usually in the layer you haven't looked at yet.

About the Author

Syed Raiyan is an email deliverability expert and Mailchimp Pro Partner with 18+ years of experience in email infrastructure, network engineering, and system architecture. He specialises in diagnosing and fixing Mailchimp deliverability problems for businesses of all sizes.

Full profile →

Something isn't working. Let's find out why.

If your Mailchimp campaigns are landing in spam, your open rates are declining, or your authentication looks right but isn't passing — that's where I start. Not with guesswork. With diagnosis.

Work with me on Fiverr ↗