Email Spam Tester

HomeBlogMailchimp Emails Going to Spam? How to Test and Fix Deliverability

Mailchimp Emails Going to Spam? How to Test and Fix Deliverability

Why Mailchimp campaigns land in spam, what Mailchimp's own test email can't show you, and the DNS records and settings that fix it, checked on a real send.

On this pageThree domains in every campaign
  1. Three domains in every campaign
  2. Authenticate the domain, don't just verify it
  3. A Gmail or Yahoo address in the From line
  4. The rules Gmail and Yahoo enforce
  5. Unsubscribe lives in the headers
  6. What Mailchimp itself says about content
  7. Why Mailchimp's test email isn't a spam test
  8. Testing the campaign before it goes out
  9. The order I read a Mailchimp report in

Open one of your Mailchimp campaigns in Outlook and look at the sender line. If it reads "on behalf of mcsv.net" or "via mailchimpapp.net", you already know a good part of why the same campaign sits in spam somewhere else. Mailchimp's help center says that label appears when the From address hasn't been authenticated, and an unauthenticated From domain is the first thing I look for when a Mailchimp campaign lands in spam. (Outlook is stubborn about the label, and Mailchimp admits it may keep showing even after you fix the cause.)

Mailchimp handles plenty on its own. It runs the sending servers, processes bounces and adds an unsubscribe footer if you forget one. The one job it can't do for you is prove that your domain sent the message, because that proof lives in your DNS and Mailchimp has no access to it.

Three domains in every campaign

A filter looking at a Mailchimp campaign sees more than one domain, and it compares them.

The From address is the one subscribers see. The envelope sender (the Return-Path, where bounces go) is set by Mailchimp, and its help pages say it "usually contains mcsv.net, mcdlv.net, mailchimpapp.net, or rsgsv.net". You can't change it. The third domain sits in the DKIM signature, in the d= tag, and names whoever signed the message.

DMARC passes when the From domain matches the domain SPF checked (which comes from the Return-Path) or the domain in the DKIM signature. With Mailchimp the Return-Path is always Mailchimp's, so SPF can pass on every message and still never count for your domain. Everything rests on DKIM. And if you haven't set up domain authentication, the DKIM signature is Mailchimp's as well. Its documentation gives the example of a campaign from newsletter@pottedplanter.com, about which it says "we'll authenticate it with our domain." Two passing checks, neither of them for pottedplanter.com, and DMARC fails for that domain. The general mechanics are in SPF, DKIM and DMARC explained.

Authenticate the domain, don't just verify it

Mailchimp has two steps with similar names, and it's easy to stop after the first. Its help page on authentication says "verification alone does not impact your email delivery." Authentication is the separate second step, and it means DNS records.

The current setup guide asks for three records, two CNAMEs for DKIM and one TXT for DMARC. The exact CNAME values are shown inside your Mailchimp account rather than in the docs, and the names are usually k2._domainkey and k3._domainkey. In your domain host's DNS editor the result looks roughly like this:

DNS·example.com
k2._domainkeyCNAMEvalue shown in your Mailchimp accountk3._domainkeyCNAMEvalue shown in your Mailchimp account_dmarcTXTv=DMARC1; p=none; rua=mailto:dmarc@example.com

Two traps are worth knowing before you start. Many DNS panels append your domain to whatever you type in the Name field, so k2._domainkey.example.com quietly becomes k2._domainkey.example.com.example.com. Mailchimp's troubleshooting section describes exactly this case, and the fix is to type only k2._domainkey. The second trap comes later, once the domain shows as authenticated. Leave those CNAMEs alone after that point, because Mailchimp warns that changing them "could interfere with the information we have on file", and a DKIM record that stops resolving is the kind of change nobody notices until the next campaign goes out.type only k2._domainkey, the panel adds the rest

You can confirm the result from outside with the DKIM checker (selector k2 or k3) and the DMARC checker, which also tells you whether the rua address can receive reports.

Mailchimp's current help pages don't ask for an SPF record at all, which fits the mechanics above, since SPF gets checked against Mailchimp's bounce domain. If you do have an SPF record, run it through the SPF checker anyway. Every include: costs DNS lookups, the limit is ten, and a record that goes past it breaks SPF for all your other mail.

A Gmail or Yahoo address in the From line

If the campaign goes out from yourname@gmail.com or a Yahoo address, there is nothing to authenticate. Mailchimp says public email services "cannot be authenticated", since you don't control their DNS. What it does instead is rewrite the From address onto one of its own subdomains, send.mailchimpapp.com or mail.mailchimpapp.com. In the docs' example, thepottedplanter@yahoo.com turns into thepottedplanter.yahoo.com@send.mailchimpapp.com.

Replies still reach the original address, so nothing visibly breaks on your side. Subscribers, though, see an odd sender, and the From domain is a Mailchimp domain shared with everyone else in the same situation. Mailchimp's own page on spam filters notes that free email domains "are often filtered more aggressively than verified email domains", and BIMI is out of reach too.

I'd buy a domain, even a cheap one, and send from it. Then take Mailchimp's other warning seriously, that it "can be risky to send a big email campaign from a brand new domain before your reputation is established", and begin with smaller sends to the people most likely to open.

The rules Gmail and Yahoo enforce

Mailchimp ties its authentication advice to the Gmail and Yahoo sender requirements, and it helps to know which number belongs to whom, because they get blurred.

Google's rules took effect on February 1, 2024, and the full set applies to anyone sending more than 5,000 messages a day to personal Gmail accounts. Those senders need SPF and DKIM, a DMARC record (a policy of p=none is enough), a From domain aligned with SPF or DKIM, one-click unsubscribe on marketing mail, and a spam rate in Postmaster Tools under 0.3%, with 0.10% as the level Google actually recommends. The 5,000 is counted per primary domain, and a sender that crosses it once is treated as bulk permanently. Google's FAQ also says that from November 2025 it began ramping up enforcement, with "temporary and permanent rejections" for mail that doesn't comply.

Yahoo started enforcing in the same month with a similar list. DMARC at least p=none, and it must pass. DKIM keys of at least 1024 bits. Unsubscribes honoured within 2 days, spam rate under 0.3%. What Yahoo doesn't have is a threshold, and its FAQ is explicit: "We will not specify a volume threshold." The 5,000 is Google's number, which Mailchimp applies to both. For a small list that matters, because with Yahoo there is no published count to stay under.

I went through the Gmail side in more depth in how to keep emails out of spam in Gmail.

Unsubscribe lives in the headers

Mailchimp adds a footer with an unsubscribe link if your template lacks one, and that link takes the subscriber through a page. Google wants a visible link like that in the body, and on top of it a second route. Mailchimp's unsubscribe page describes it as "Gmail and Yahoo will require 1-click unsubscribe capability via email headers, not the email body." Those are two headers, List-Unsubscribe with an https link and List-Unsubscribe-Post: List-Unsubscribe=One-Click (what both look like), and Google adds that a mailto link or a link in the body doesn't count as one-click.

Mailchimp's help pages say the header route exists but never print the header names. I'd open the source of one real send and see both lines with my own eyes. It takes a minute.

What Mailchimp itself says about content

Mailchimp's spam-filter page says filters score many factors and add them up, and "generally, your campaign would need to have multiple triggers to get filtered as spam." The triggers it names are the familiar ones: link shorteners, links that don't work, and "sloppy code, extra tags, and code pulled in from Microsoft Word". The same page notes that some filters open messages and click links before a person ever sees them, so a burst of clicks in the first minute after sending may well be a filter at work.

Shared IPs come up there as well. Mailchimp's sending addresses are shared between customers, and the page says that "if one person decides to send spam through Mailchimp, it could affect deliverability for our other users." You can't fix that from your side.

Why Mailchimp's test email isn't a spam test

The "Send a Test Email" button in the email designer (under the Preview menu in the legacy builder) exists to check layout. It has limits, and in a few ways it differs from the send your subscribers get.

  • Free plans get 12 tests per email and 24 in any 24 hours, paid plans 70 and 200. Each recipient counts, so one test to four addresses uses four.
  • Every test counts toward your monthly send limit, the same as a live email.
  • Merge tags and dynamic content aren't filled in. Mailchimp's own suggestion, when you need them, is a live send to a small test segment.
  • A test sent from the template builder isn't tied to an audience, so its From address is your account's primary email address.

Testing the campaign before it goes out

I built Email Spam Tester for this step. You send the campaign's test email from Mailchimp to a one-time address the site hands you, and about a minute later the report answers the Mailchimp questions first: whose domain sits in the DKIM d= tag, whether DMARC passed for your From domain, what the unsubscribe headers really say. Those are three of its 42 checks, and the Mailchimp IP's standing on 21 blocklists is another. Failures come with a fix plan and DNS records ready to paste, each fix carrying a points figure worked out from the scoring table. There is no signup and no charge.

If you'd rather not copy addresses around, connect your Mailchimp account instead. You pick a draft and Mailchimp itself sends the test, from your account with your settings, so the report sees the servers, the signature and the rewritten tracking links as subscribers would. The same send can also go to inboxes at Gmail, Outlook, Yahoo and other providers, and then the report shows which folder the campaign landed in at each one. Because Mailchimp only sends tests with the campaign's own subject, that part works from a temporary copy of the draft with a marker added to its subject; the copy is deleted afterwards and your draft is never edited. Those sends come out of Mailchimp's per-campaign test allowance, so on the free plan the inbox placement test reaches fewer inboxes.

For campaigns after that one, the connection can add a permanent address to an audience. It joins as an ordinary contact tagged "Email Spam Tester", every campaign and automation the audience receives gets checked when it arrives, and it counts toward your contact limit like anyone else on the list.

The order I read a Mailchimp report in

  1. The DKIM line. Does d= show your domain or a Mailchimp one? If it's Mailchimp's, authentication isn't finished, and nothing further down matters much yet.
  2. DMARC. Is there a record at all, and does it pass? A DMARC fail next to a passing DKIM points straight back to step one.
  3. The From address. A gmail.com or yahoo.com sender will show up rewritten onto mailchimpapp.com.
  4. Both unsubscribe headers, present and pointing at https.
  5. Blocklists. A listing on a shared Mailchimp IP isn't yours to fix, but you want to know about it before you start rewriting the copy.
  6. Content last: shorteners, pasted Word markup, a layout that is mostly one big image.

Then the folder results, if you asked for them. A campaign can pass everything and still go to Promotions at Gmail, which is a tab of the inbox, and for a newsletter that's a fairly normal place to be.

Mailchimp's own in-app banner for unauthenticated domains warns that emails "may miss 74% of inboxes". The figure is theirs and I can't check it. The records it's nagging about are the three in the snippet above.