12 July 2026

Mailchimp emails going to spam? Check these two CNAME records first

Most Mailchimp spam problems come down to k1._domainkey, a DNS dashboard that mangles it, or a DMARC record nobody added. The fixes, in plain English.

J

Jason

Founder, Inbox Decay — watching the layer of email that can be measured.

The short answer: if your Mailchimp campaigns are landing in spam, check whether k1._domainkey.yourdomain.com resolves to dkim.mcsv.net. That single CNAME is the heart of Mailchimp's domain authentication, and when it's missing or mangled, your campaigns go out without your domain's signature and inherit whatever reputation Mailchimp's shared pool has that week. You can check your domain right now, free, no signup, and get a plain answer in about a minute.

If the record checks out, there are two other usual suspects, and one piece of outdated advice that actively makes things worse. All below.

"But I authenticated this domain years ago"

I hear this one a lot, and it's usually true. The domain was authenticated in 2019, campaigns went fine for years, and now opens are sliding. Two things changed since then.

First, Gmail and Yahoo rewrote the rules in February 2024. Bulk senders now need a DMARC record on their domain, and authentication stopped being a nice-to-have and became an entry requirement. Plenty of Mailchimp accounts authenticated long ago and never added DMARC, because back then nobody asked for it.

Second, records rot. A website migration, a DNS cleanup, a registrar switch, an agency handover: TXT and CNAME records that look unused get deleted by people doing sensible-looking housekeeping. Nothing warns you. Mailchimp keeps sending, just unsigned, and the only symptom is engagement drifting down over weeks.

So "I set this up already" is exactly why it's worth checking again. Setups don't stay set up.

What Mailchimp actually needs (less than you think)

Modern Mailchimp authentication is two or three CNAME records, all pointing at the same place:

  • k1._domainkeydkim.mcsv.net
  • k2._domainkey and k3._domainkey → same target, on many accounts

That's the whole list. Mailchimp manages the actual signing keys behind those names and rotates them without bothering you; your only job is making the names answer. You'll find your account's exact records in Mailchimp under Website, then Domains, then Authenticate.

Now the outdated advice: a decade of old tutorials says to add include:servers.mcsv.net to your SPF record. Don't. Modern Mailchimp sends with its own envelope domain, which means SPF passes on Mailchimp's side and your domain authenticates through the DKIM CNAMEs above. Pasting an old include into your SPF record does nothing for your Mailchimp mail, costs you one of SPF's ten allowed DNS lookups, and if the edit goes wrong it can break SPF for everything else your domain sends. The number of setups I've seen where the "fix" was the injury is not small.

The trap your DNS dashboard sets

Mailchimp's own documentation warns about this, and our checker catches it constantly: many DNS providers silently append your domain to whatever you type in the host field.

You carefully enter k1._domainkey.yourdomain.com. The dashboard creates k1._domainkey.yourdomain.com.yourdomain.com. Your control panel looks correct, Mailchimp says verification failed, and you're left staring at two screens that disagree.

The fix is knowing what your provider's host field expects. If it appends automatically (most do), enter only k1._domainkey. The same appending happens on the value side with some providers, where the cure is a trailing period: dkim.mcsv.net.

A checker that queries the exact names receivers use, rather than reading your dashboard, sees this instantly, which is precisely what ours does.

Then add DMARC, because nobody else will

Mailchimp cannot create your DMARC record. Neither can any other email tool, because DMARC lives on your domain and covers every sender you use at once. It is always your record.

If you don't have one, publish a TXT record at _dmarc.yourdomain.com with:

v=DMARC1; p=none; rua=mailto:you@yourdomain.com

p=none satisfies the bulk-sender requirement today and sends you reports about who's sending as your domain. Tighten to p=quarantine later, once your reports show everything aligned, and not before: a strict policy published while your Mailchimp DKIM is broken instructs every mailbox provider to junk your own campaigns. Order matters. Authenticate first, observe, then tighten.

The five-minute version

  1. In Mailchimp: Website → Domains → Authenticate, copy your CNAME records.
  2. In your DNS provider: add them, watching for the appended-domain trap above.
  3. Run the free Mailchimp checker to confirm the names answer with dkim.mcsv.net from the outside world.
  4. Add DMARC at p=none if you don't have it.
  5. Give DNS up to a couple of hours before re-verifying in Mailchimp; it's nearly always propagation, not error.

The checker also runs your SPF, MX and 24-plus blocklist checks in the same pass, because a perfect Mailchimp setup on a blocklisted domain still goes to spam, and you'd want to know which problem you actually have.

And the honest caveat, because it's the part everyone skips: passing today is a snapshot. The 2024 rule change moved thousands of working setups into spam without touching them, and routine DNS housekeeping does the same thing retail. That's what Inbox Decay exists for: we keep re-checking your setup and email you the moment something breaks, starting free. Fix it once, then let something else do the remembering.

Check your own domain — free, 60 seconds

Everything this article describes is checkable right now. No signup, no email required.

Run the Mailchimp spam checker