Do I need to add Mailchimp to my SPF record?

No — not for Mailchimp marketing campaigns under the current setup. Mailchimp's own documentation notes the campaign envelope sender is a Mailchimp domain (mcsv.net and siblings), so SPF for a campaign can never align with your From domain, and Mailchimp's current authentication flow contains no SPF step at all. Its record set is two DKIM CNAMEs plus a DMARC TXT, and DMARC passes on the aligned DKIM signature alone. The widely-taught include:servers.mcsv.net step belongs to a retired flow; adding it today costs you one of your ten SPF lookups for nothing.

Where is domain authentication in Mailchimp now?

Under your profile icon: Account & billing, then the Domains tab, then Start authentication for your domain. Mailchimp offers an automatic method (Entri) that signs into your DNS provider and creates the records, or a manual method showing your account's two CNAME records and one DMARC TXT to add yourself. Older guides pointing at Settings, Website, or 'verified domains' screens describe retired navigation.

My Mailchimp domain says Authenticated but campaigns still land in spam. Now what?

Authentication is the identity layer, not the reputation layer — Mailchimp itself separates the two. Once headers on a real campaign show dkim=pass with your domain and dmarc=pass, remaining spam placement is driven by the things receivers actually grade next: who is on the list and how it was gathered, engagement history, complaint behaviour, and sending patterns. Work them in that order rather than re-editing DNS records that already pass.

Mailchimp · Cloudflare · Authentication

Mailchimp emails going to spam? Authenticate your domain — the current way

First published 20 October 2026 · The flow below is Mailchimp's current documented setup, read from Mailchimp's own help pages for this guide. Where older instructions (including the internet's favourite SPF step) disagree, the disagreement is named.

THE TELL Campaign headers: dkim=pass — header.d = a Mailchimp domain, not yours

Until your domain is authenticated, Mailchimp signs your campaigns as itself. Receivers grade that signature against your From domain and find no match — the exact definition of unauthenticated marketing mail in 2026.

Fix = 2 CNAMEs + 1 TXTNo SPF step exists in the current flow

The fast answer

Branch zero: your From address must be on your own domain. Campaigns sent from a free webmail domain (gmail.com, yahoo.com) cannot be authenticated, full stop — change the From domain first.
In Mailchimp: profile icon → Account & billing → Domains tab → Start authentication. (Domain verification — the email-click step — is separate and, in Mailchimp's own words, does not impact delivery.)
Choose Entri (automatic, Mailchimp's recommendation) or manual. Manual shows your account's exact records: two CNAMEs + one TXT at _dmarc.
On Cloudflare, both CNAMEs go in DNS only, relative names, TTL Auto. Then run the 2-minute readback below before waiting on anything.
Success = the Authenticated label in Mailchimp and a real campaign whose headers show dkim=pass with your domain, dmarc=pass.

Why there is no SPF step (and why the old guides are wrong)

Mailchimp states plainly that a campaign's envelope sender “usually contains mcsv.net, mcdlv.net, mailchimpapp.net, or rsgsv.net.” SPF grades the envelope domain — so for campaigns, SPF structurally cannot align with your From domain, no matter what you add to your record. The current flow therefore rests DMARC on the leg that can align: DKIM signed with your domain, delivered via the two CNAMEs. The famous include:servers.mcsv.net instruction belongs to Mailchimp's retired process; today it spends one of your ten SPF lookups (a real budget — see our PermError guide) on a check that cannot affect the grade. If an older record of yours already contains it, leaving it is harmless; adding it now is waste. (One nuance: Google's own SPF help still prints that include inside a merged-record example. Google's example is generic; Mailchimp's current flow is specific. Specific wins.)

The records — Cloudflare fields, exactly

Cloudflare field	CNAME 1 & 2	TXT (DMARC)
Name	The name Mailchimp shows for each record — enter it relative (e.g. the `…._domainkey` portion as displayed; Cloudflare appends your domain). Mailchimp's own troubleshooting uses the doubled-name failure as its example: typing the full `name.yourdomain` creates `name.yourdomain.yourdomain`.	`_dmarc`
Target / Value	Exactly what your account displays. Names and targets are per-account in the current flow — any guide printing filled-in values (you'll see k-selector templates from older eras, and mandrillapp.com targets that belong to Mailchimp Transactional, a different product) is showing you someone else's records.
Proxy status	CNAMEs: DNS only. A proxied CNAME answers verifiers with Cloudflare's anycast IPs instead of the target — Cloudflare's own documented verification failure.
TTL	Auto

The 2-minute readback (do this before “waiting for propagation”)

Look up each CNAME name with any DNS checker. Three possible answers, three different meanings:
- A CNAME naming the target Mailchimp showed → correct. Now, and only now, is waiting legitimate (Mailchimp: most records update within minutes; up to 48 hours at the outside, with a completion email).
- IP addresses (A/AAAA answers) → the record is proxied or flattened. Fix the toggle/setting; no amount of waiting validates this.
- Empty / not found → wrong name (check for doubling) or the record never saved.
If you used Entri: perform this same readback. Neither Mailchimp's nor Cloudflare's documentation states which proxy state the automatic method leaves behind — so verify it like a manual setup. Two minutes, once.
After success, freeze the records: Mailchimp warns that changing these CNAMEs later “could interfere” with authentication — its documented route for changes is disable authentication → change → re-authenticate. Treat them as load-bearing.

Authenticated — and still in spam? The honest ladder

Mailchimp itself separates identity from reputation. With headers passing on your domain, work these in order — none of them is a DNS record:

The list: purchased, rented, or scraped addresses are the single largest spam-folder cause and a Mailchimp terms violation besides. Mail only people who opted in to you.
The unengaged: contacts who haven't opened in months drag placement down domain-wide. Re-engage once, then suppress. Yahoo's 0.3% complaint ceiling (of inbox-delivered mail — our Yahoo guide) is graded on the same behaviour.
The sending pattern: sudden volume spikes from a quiet account read as compromise to receivers. Ramp, don't blast.
Dedicated IP? Almost certainly not your answer: Mailchimp's own FAQ says most senders do better on shared IPs, and dedicated “makes sense” only around 100k+ emails a week — below that, a cold IP has no reputation at all, which is worse than a shared warm one.

FAQ

Mailchimp says “Authentication in progress” for a day. Broken?

Only if the readback is wrong. Correct CNAME answers + in-progress status = inside Mailchimp's documented window (minutes typically, 48 hours worst case). Wrong readback + in-progress = it will never complete; fix the record, then use Mailchimp's Resolve / Restart authentication.

I already have a DMARC record. Does Mailchimp's TXT replace it?

Never stack two DMARC records — receivers then apply none (our rollout guide covers the one-record rule). If a _dmarc TXT already exists, your existing record is the one that governs; Mailchimp needs DMARC present and passing via its aligned DKIM, not ownership of the record.

Does this fix my Mailchimp Transactional (Mandrill) mail too?

Different product, different records (its own selectors and mandrillapp.com targets, from Mailchimp's developer docs). Authenticating one product does nothing for the other.

Sources

Mailchimp Help — domain authentication (current flow, Entri and manual methods, status states, timing), domain verification vs authentication, dedicated-IP FAQ, envelope-sender domains statement · Cloudflare Developers — proxy status and CNAME verification behaviour (via this site's earlier verified Cloudflare research) · Google SPF help (the conflicting merged example, noted as found).

Verification note: the record structure, navigation, status names and timing above were confirmed on Mailchimp's live help pages on 20 October 2026. The exact DMARC value Mailchimp displays in-account varies by account and is shown only inside it; this guide therefore prints no “Mailchimp DMARC value,” and any site that does is guessing.

Did this fix work for you?

Your reaction tells us whether this guide solved the problem it promised to solve.