Mailchimp Deliverability: What Most Guides Don't Tell You

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 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.

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:

• Sending only to engaged contacts who explicitly opted in
• Keeping hard bounce rates well below 2%
• Suppressing contacts who haven't engaged in 90+ days before large sends
• Never importing purchased or scraped lists
• Sending at a consistent cadence rather than sporadic volume spikes

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 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:

• Validation pass: Run the full list through an external tool (NeverBounce, ZeroBounce) to catch invalid addresses Mailchimp hasn't bounced yet — including role addresses (info@, support@) and disposable domains
• Engagement segmentation: Identify contacts by last open or click date — 30 days, 60 days, 90 days, 6 months, 12 months. Treat each segment differently
• Re-engagement sequence: Before suppressing disengaged contacts, run a 2–3 email sequence to give them a final chance to re-engage. Those who don't respond get suppressed
• Sunset policy: Anyone who hasn't engaged in 12 months and didn't respond to re-engagement gets removed. This isn't optional if you want to maintain placement at scale
• Acquisition audit: Where did your contacts come from? Contacts from unclear sources or third-party lists introduce spam traps — addresses specifically designed to identify senders with poor list hygiene

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:

• Image-heavy templates with thin text: A high image-to-text ratio is a classic spam signal. The email looks fine to a human but reads as low-information to a filter. A template that's 80% image and 20% text will underperform consistently
• Drag-and-drop builder bloat: Mailchimp's native drag-and-drop editor produces significant markup bloat — nested tables, redundant inline styles, unnecessary spacing elements. This inflates file size and introduces patterns that filters associate with mass email tools. Hand-coded templates are cleaner and more predictable across clients
• Missing or malformed preheader text: The preheader (preview text) isn't just a UX feature — it affects how filters interpret the email's intent. A missing preheader or a preheader that reads as system-generated text reduces apparent legitimacy
• Unbalanced link ratios: A campaign with many links relative to text volume looks promotional to filters. Every link is also a signal — domain reputation of linked URLs contributes to email scoring
• Rendering failures in Outlook: Outlook uses a Word-based rendering engine that ignores many modern CSS properties. Emails that break in Outlook aren't a deliverability issue in the strict sense, but broken rendering leads to low engagement — which is a deliverability issue in the longer term

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

• Regular cadence — whether weekly, fortnightly, or monthly, it should be predictable
• Volume that doesn't spike more than 2–3x your normal send without warmup
• Segmentation by engagement tier, so your most engaged contacts receive email more frequently than re-engagement candidates
• Stagger scheduling for lists above 10,000 contacts
• Monitoring send time data to identify when your specific audience is most likely to engage

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

Real cases — what the problems actually looked like

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. 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.