Why Are My Mailchimp Emails Going to Spam?

You built the campaign in Mailchimp, sent it to people who signed up for it, and the open rate came back at half of what it usually is. Somebody replies that they found it in spam. Nothing about the campaign looks different from the last one that worked.

Mailchimp runs the sending infrastructure: the IP pools, the feedback loops with the mailbox providers, the unsubscribe headers, the bounce handling. What it cannot do is prove to a receiver that the mail is yours. That proof lives in DNS records on your domain, and it is missing far more often than anyone expects.

Three causes cover almost all of it.

Cause one: the domain was never authenticated

This is the common one, and it hides well, because Mailchimp will happily send a campaign for a domain that has never completed authentication.

Every message carries two sender addresses: the one your reader sees in the From: header, and the invisible envelope sender that bounces return to. Receivers check the second one for SPF, and check the DKIM signature separately. DMARC then asks whether either of those passing checks belongs to the same domain as the visible From:. That last question is called alignment, and it is the whole game.

Here is what that looks like in the headers of a message delivered to Gmail. The domain has a bare p=none DMARC record published, which is why Gmail echoes a policy back, and no Mailchimp authentication behind it:

Return-Path: <bounce-mc.us18_41205839.4913722-a1b2c3d4@mail105.suw11.rsgsv.net>
From: Ana <ana@example.com>
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounce-mc.us18_41205839@mail105.suw11.rsgsv.net
         designates 198.2.128.1 as permitted sender)
       dkim=pass header.i=@mailchimpapp.net
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=example.com

Two checks passed and DMARC still failed. SPF passed for rsgsv.net, DKIM passed for mailchimpapp.net, and neither of those is example.com. As far as the receiver can tell, a bulk platform sent mail claiming to be from a domain that has never vouched for it. That is also what produces the “via mailchimpapp.net” line Gmail puts under the sender name, which Mailchimp documents as the signature of an unauthenticated From address.

Authentication changes the DKIM line, and only the DKIM line. Mailchimp keeps the envelope sender on its own domains, so SPF alignment is not available at all. The records Mailchimp hands you are two CNAMEs and a DMARC TXT:

k2._domainkey.example.com.  CNAME  dkim2.mcsv.net.
k3._domainkey.example.com.  CNAME  dkim3.mcsv.net.
_dmarc.example.com.         TXT    "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

After they resolve, dkim=pass header.i=@example.com replaces the Mailchimp domain, DMARC passes on the DKIM leg alone, and the “via” line goes away. The procedure for getting records into a zone, including the providers that append the domain to the hostname for you, is in the DKIM record setup guide and the DMARC record setup guide.

Do this: send yourself a campaign, paste the raw headers into the free email header analyzer, and read which domain the dkim=pass line names. If it names Mailchimp, that is your bug.

Cause two: the From address is on a mailbox you do not own

Creators and small businesses often run campaigns from the address they answer mail on, which is frequently a Gmail or Yahoo address.

Mailchimp is direct about this: public email services cannot be authenticated. There is no CNAME you can publish under gmail.com, because it is not your domain. The signature will always name Mailchimp, DMARC will never align, and the message carries nothing that ties it to you.

How badly that ends depends on which free service. These are the policies the two largest publish, read on August 10, 2026:

_dmarc.gmail.com.  TXT  "v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com"
_dmarc.yahoo.com.  TXT  "v=DMARC1; p=reject; pct=100; rua=mailto:d@rua.agari.com; ..."

A campaign from a yahoo.com From address is asking receivers to apply p=reject to it, which is a rejection rather than a spam folder. gmail.com sits at p=none today, so the mail is not rejected on policy, and it still arrives with no aligned authentication at a moment when Gmail’s own bulk sender rules ask for exactly that. Neither one is a position to send from.

The same trap catches anyone using a domain they authenticated in one tool and forgot in another. Authentication is per platform. A domain that is authenticated for Mailchimp is not authenticated for the transactional mail going out through a separate service, which is the reason the receipts land in spam while the newsletter arrives fine. The Amazon SES post covers the transactional half of that split.

Do this: move the campaign From address onto a domain you control, and list every other tool sending under that same domain. Each one needs its own signature.

Cause three: the audience, and the numbers that actually move

Once authentication is in place, placement is decided by how recipients react. Two numbers carry most of the weight: how many people mark the mail as spam, and how many addresses bounce.

Mailchimp does not publish a threshold. Its abuse and suspension pages describe “industry thresholds” and warning notices without stating a figure, so there is no line to sit just under. Google does publish one. The Gmail sender guidelines expect the spam rate reported in Postmaster Tools to stay below 0.1 percent and never reach 0.3 percent, and they require both SPF and DKIM, an aligned DMARC record and a one-click unsubscribe from anyone sending more than roughly 5,000 messages a day to personal Gmail accounts. Mailchimp supplies the unsubscribe header. The rest is on your domain, and what Gmail and Yahoo actually enforce is worth reading if the audience is large.

Both numbers come from the same place: how the audience was collected. An imported spreadsheet, a list bought from anyone, or a signup form with no confirmation step will generate complaints from people who do not remember you, and those complaints follow your domain into every future campaign. Reputation recovers slowly, and it recovers on sending behaviour, not on apologies.

Do this: before the next campaign, remove every hard bounce, archive contacts with no opens or clicks in the last six months, and check where the oldest segment of the audience came from.

Verifying the fix

Wait for the DNS TTL to expire, send a campaign to yourself, and read the headers again. The dkim=pass line should name your domain and dmarc=pass should follow. The spf=pass line will still name a Mailchimp domain, and that is expected here rather than a fault.

Then read the records back out of public DNS instead of out of the Mailchimp dashboard. The free email health check resolves your SPF, DKIM, DMARC and MTA-STS records the way a receiver would and checks your domain against blocklists in the same pass, which catches the case where a record was pasted with a trailing typo and the dashboard is reporting a cached success.

That answers for one domain, at the moment you ask it. Which is the real gap.

Nothing in this setup announces when it breaks. A DNS migration drops the two CNAMEs and Mailchimp keeps sending, unsigned, without an error. A DMARC record gets replaced by another tool’s setup wizard. A campaign to a stale segment generates complaints on a Tuesday that quietly cost you the inbox for weeks. Campaign reports keep showing delivery, because “delivered” means the receiver accepted the message, not that anyone saw it.

Closing that gap is what LitInboxes does. Each monitored domain is re-checked every 6 hours across DNS records, 8 high-signal blocklists on every plan and 24 on Pro, DMARC aggregate reports and Google Postmaster reputation, with a dated history so a drop can be traced to the day it started, and an alert when something changes rather than a reminder to go look. Email alerts are on every plan; Slack, Discord and webhook alerts are on Pro. There is a live demo if you want to see the view first.

If Mailchimp turns out not to be the problem, the full spam diagnostic walks the other causes in order of likelihood. Creators and course businesses usually hit this on a domain that is also running a course platform, a scheduler and a payment processor, each signing mail on its own.

The checklist

1. Send yourself a campaign and read the raw headers.
2. Check which domain the dkim=pass line names. Mailchimp means the domain is unauthenticated.
3. Start authentication in Mailchimp and publish the two CNAME records it gives you.
4. Publish a DMARC record at p=none with a rua address and read what arrives.
5. Move the From address onto a domain you control if it is on a free mailbox service.
6. List every other platform sending under that domain and authenticate each one.
7. Remove hard bounces and contacts with no engagement in six months.
8. Re-read the headers after the TTL expires and confirm the signature now names your domain.