Do I need to add an SPF record or include:servers.mcsv.net for Mailchimp?

No. Mailchimp's domain authentication is CNAME-based DKIM plus a DMARC record — there's no SPF step. And adding include:servers.mcsv.net wouldn't help DMARC pass anyway: Mailchimp sends with its own Return-Path, so SPF resolves against Mailchimp's domain and never aligns with your From domain. Leave your root SPF for senders that actually use your domain in the envelope; DKIM is what carries Mailchimp's DMARC pass.

Why do my Mailchimp emails still say “via mcsv.net” or “mailed-by mcsv.net”?

That “mailed-by” line reflects the Return-Path, which stays on Mailchimp's bounce domain even after you authenticate — Mailchimp processes the bounces. It's expected and doesn't hurt you: after authentication the “signed-by” line shows yourdomain.com and DMARC passes on DKIM alignment. The “on behalf of” wording tied to fully unauthenticated sending is what goes away.

What's the difference between verifying and authenticating a domain?

Verifying proves you own the domain — Mailchimp emails a code to an address at that domain, and clicking/entering it lets you use From addresses on it. Authenticating adds the two DKIM CNAMEs (and DMARC) so your mail is signed as your domain and passes DMARC. You verify first, then authenticate.

Do I add these as CNAME or TXT records?

The two DKIM records (k2._domainkey and k3._domainkey) are CNAMEs pointing to dkim2.mcsv.net and dkim3.mcsv.net. Only the DMARC record is a TXT record, at host _dmarc. There is no SPF TXT record to add for Mailchimp.

Will Mailchimp's records conflict with Google Workspace, Microsoft 365, or another sender I use?

No. Mailchimp uses its own k2/k3 DKIM selectors, so its CNAMEs sit alongside Google's or Microsoft's DKIM without overwriting anything. The only rules: keep a single SPF TXT record and a single _dmarc record on your domain — never publish two of either.

How long does authentication take to verify?

DNS propagation is usually minutes but can take up to 24–48 hours, after which Mailchimp's status flips to “Authenticated.” If it fails, double-check that the records are CNAMEs (not proxied on Cloudflare) and that the host labels weren't doubled, then use Resolve / Restart authentication.

Can I authenticate my bare root domain, or do I need a subdomain?

You can authenticate the root domain directly — Mailchimp doesn't force a sending subdomain. If you'd rather isolate Mailchimp's reputation on something like mail.yourdomain.com, you can, but you then verify and authenticate that subdomain separately with its own CNAMEs.

SPF setup guide

SPF, DKIM & DMARC for Mailchimp.

Mailchimp authenticates your domain with CNAME-based DKIM, not by having you paste a shared SPF line. In Account & billing → Domains you first verify the domain with an emailed code, then run "domain authentication," which hands you two CNAME records — k2._domainkey and k3._domainkey — that delegate rotating DKIM keys back to Mailchimp, plus a DMARC TXT record. Once those resolve, Mailchimp signs mail as your own domain, DMARC passes on DKIM alignment, and the "on behalf of" notice Gmail attaches to unauthenticated Mailchimp mail disappears. There is no shared SPF include to add to your root — and, importantly, adding one wouldn't help DMARC pass.

CNAME domain authentication

Your DNSAdd the CNAME / TXT records

MailchimpSigns & sends as your domain

The inboxSPF · DKIM · DMARC pass

Why authenticate Mailchimp?

Authenticating your domain in Mailchimp isn't housekeeping — it's the difference between the inbox and the spam folder, and Mailchimp now enforces it. Since February 2024, Gmail and Yahoo have required every bulk sender (roughly 5,000+ messages a day) to pass SPF, DKIM, and DMARC with alignment, and Microsoft extended the same 5,000-a-day rules to its consumer inboxes (Outlook, Hotmail, Live) in 2025. In response Mailchimp made domain authentication effectively mandatory and started blocking campaigns sent from free public From addresses (gmail.com, yahoo.com, etc.). Until you authenticate, Mailchimp sends under its own domain: recipients see the mail isn't really from you, your From address doesn't align, DMARC can't pass, and your sending reputation is pooled with every other unauthenticated Mailchimp sender. There's a Mailchimp-specific twist that makes DKIM non-negotiable: Mailchimp keeps its own Return-Path on its bounce domain, so SPF never aligns to your domain — DKIM is the *only* mechanism that carries your DMARC pass. Skip the CNAMEs and you have no aligned authentication at all.

The SPF reality for Mailchimp

Mailchimp is a CNAME-based DKIM provider, so for your root domain there is NO "include:servers.mcsv.net" to add — and this is the part almost every old tutorial gets wrong: adding one wouldn't make DMARC pass anyway. Here's why. Mailchimp sends every campaign with an envelope sender / Return-Path on its own bounce domain (an mcsv.net or mailchimpapp subdomain), because Mailchimp — not you — processes the bounces. SPF is always checked against that envelope domain, so SPF resolves against Mailchimp's servers, never against your From domain. It may raw-"pass," but it does not *align* with your organizational domain, and DMARC only counts SPF when it aligns. That's exactly why Mailchimp's domain-authentication flow asks for two DKIM CNAMEs and a DMARC record and never mentions SPF: DKIM signed as d=yourdomain.com (via the k2/k3 selectors) is the mechanism that aligns and carries your DMARC pass. You'll still find guides telling you to append include:servers.mcsv.net to your root SPF; that only makes the raw SPF check pass against Mailchimp's IPs and does nothing for DMARC alignment. The modern CNAME flow doesn't ask for it, it burns one of your 10 SPF lookups, and you can safely leave it off. Reserve your root SPF record for the senders that actually put your domain in the Return-Path — Google Workspace, Microsoft 365, a transactional relay — and let DKIM do the work for Mailchimp.

Two ways to set it up

Recommended

Automatic connect with Entri (recommended)

Mailchimp logs into your DNS host and adds the CNAMEs and DMARC record for you
Fewest chances to fumble a host label or record type
Best when your DNS is at a supported host (Cloudflare, GoDaddy, Namecheap, and others Entri supports)
Requires signing into your DNS provider through the Entri pop-up

Legacy

Manual DNS entry

Mailchimp shows CNAME 1, CNAME 2, and the DMARC record to copy yourself
Works with any registrar, including hosts Entri doesn't support
You control exactly what's published and can merge the DMARC record with an existing one
Produces the identical records — just added by hand rather than through Entri

Step by step

In Mailchimp

1
Open the Domains page
Click your profile icon (bottom-left) → Account & billing → Domains. This one page handles both verifying and authenticating a domain — they're two separate steps.
2
Verify the domain first
Click Add & Verify Domain, enter an email address at the domain (e.g. you@yourdomain.com), and click Send Verification Email. Open the message from accountservices@mailchimp.com and either click Verify Domain Access or paste the code into Mailchimp and click Verify. This proves ownership so you can use From addresses at the domain — links and codes expire after 7 days, and public domains like gmail.com can't be verified.
3
Start authentication
Next to the now-verified domain, click Start authentication. Choose your DNS host from the dropdown (it only tailors the on-screen instructions) and click Next.
4
Pick automatic (Entri) or manual
Click Continue to let Entri log into a supported DNS host and add the records for you, or click “Or manually authenticate your domain” to copy the records and paste them at your registrar yourself. Both create the exact same DNS records.
5
Copy the records shown
On the manual screen Mailchimp displays CNAME 1 and CNAME 2 (each with a Name/Host and a Value) plus a DMARC TXT record (Host _dmarc and a Value). Copy them exactly — the selectors and targets are shown for your account.

In your DNS

6
Add the two DKIM CNAMEs
Create two CNAME records: Host k2._domainkey → Value dkim2.mcsv.net and Host k3._domainkey → Value dkim3.mcsv.net (use the exact hosts/targets your account shows; some older accounts show a single k1._domainkey → dkim.mcsv.net instead). Keep the type as CNAME — don't switch it to A or TXT.
7
Add the DMARC TXT record
Create one TXT record at host _dmarc with a value like v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Skip this step if you already have a _dmarc record — a domain must have exactly one.
8
Fix host labels and the Cloudflare proxy
If your registrar auto-appends the domain, enter just the label (k2._domainkey, not k2._domainkey.yourdomain.com) to avoid doubling. On Cloudflare, set each CNAME to “DNS only” (grey cloud) — an orange-cloud proxied CNAME won't resolve to mcsv.net and verification fails.

Verify

9
Run Mailchimp's DNS check
Back in Mailchimp, click to verify (older accounts show a Test DNS Settings button). Propagation is usually minutes but can take up to 24–48 hours; the status flips to “Authenticated.” If it stalls, use Resolve / Restart authentication and re-check the record values.
10
Send from the authenticated domain
In each audience's settings and every campaign, set the From address to one on the authenticated domain (e.g. news@yourdomain.com) so the mail is actually DKIM-signed as your domain — verifying DNS alone doesn't change a campaign already set to a different From address.

Records to add

Mailchimp generates the exact values in its setup wizard — these show the shape of what you'll add at your DNS host.

Type	Host	Value
CNAME	k2._domainkey	dkim2.mcsv.netDKIM key 1 — Mailchimp-managed; exact selector/target is shown in your account
CNAME	k3._domainkey	dkim3.mcsv.netDKIM key 2 — pair to k2; older accounts may show a single k1._domainkey → dkim.mcsv.net instead
TXT	_dmarc	v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comYour DMARC policy — keep exactly one _dmarc record per domain

Keep exactly one SPF (v=spf1) TXT record on your root domain — merge every sender into it. Two SPF records is itself an error.

The 10-lookup budget

SPF is capped at a hard 10 DNS lookups — go over and it returns a permerror and stops validating everywhere. Here's what Mailchimp's setup costs against that budget.

SPF 10-lookup budget0 used · 10 free

Mailchimp's recommended setup adds 0 lookups — all 10 stay free for the senders that do need an include.

DKIM

DKIM is the whole game for Mailchimp, and it's handled by the two CNAME records — typically k2._domainkey.yourdomain.com and k3._domainkey.yourdomain.com — pointing at dkim2.mcsv.net and dkim3.mcsv.net. Because these are CNAMEs delegated to Mailchimp rather than TXT keys you paste, Mailchimp holds the private keys and can rotate what's published behind those selectors without you ever touching DNS again; you never create a DKIM TXT record or copy a key yourself. The signature Mailchimp applies is d=yourdomain.com with selector k2 (or k3), so it *aligns* with your From domain — which is what lets DMARC pass. One honest caveat: the targets (dkim2/dkim3.mcsv.net) are shared Mailchimp endpoints, so the underlying key material is managed on Mailchimp's platform rather than by you. That's fine for DMARC alignment because your signature still carries d=yourdomain.com, but it's why you can't independently rotate or export the key. Add both CNAMEs exactly as shown (grey-cloud / DNS-only if on Cloudflare) and let Mailchimp's check confirm them.

DMARC

DMARC is a separate policy record on your root domain — a single TXT at _dmarc.yourdomain.com that begins with v=DMARC1 — and Mailchimp's flow prompts you to add it. Start with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com: p=none is monitor-only, so it won't affect delivery while you confirm Mailchimp mail is passing. There's a Mailchimp-specific reason to be careful before you tighten: since SPF never aligns for Mailchimp, DKIM is the *only* thing carrying your DMARC pass, so don't move to p=quarantine or p=reject until you've seen Mailchimp mail pass DKIM-aligned in real Show-original headers and in your aggregate (rua) reports. Watch the reports for a week or two, then step up to p=quarantine and eventually p=reject. Keep exactly one _dmarc record for the whole domain no matter how many senders you run — never add a second one just for Mailchimp.

Check it actually worked

Don't trust Mailchimp's “Authenticated” badge alone — confirm it on a real message. Send yourself a test campaign (or a preview) from an address on the authenticated domain, open it in Gmail, and choose ⋮ → Show original. You want DKIM: PASS with signed-by: yourdomain.com and DMARC: PASS. Expect a quirk: SPF will show “pass” but “mailed-by” a mcsv.net / mailchimpapp domain and it will NOT be aligned — that's normal for Mailchimp, and DMARC still passes because DKIM aligns. Then run your domain through Qualisend's domain health check to confirm both CNAMEs and the DMARC record resolve, and once aggregate reports start arriving, drop one into the DMARC report analyzer — Mailchimp should appear as a DKIM-aligned, passing source.

Domain health check DMARC report analyzer

Common gotchas

DNS setup
SPF won't align for Mailchimp, and that's by design. Mailchimp keeps its own Return-Path (an mcsv.net bounce domain), so SPF is checked against Mailchimp, not you. Don't chase SPF alignment or add include:servers.mcsv.net expecting DMARC to pass on SPF — DMARC passes on DKIM alignment alone. The modern CNAME flow doesn't ask for an SPF change at all.
DNS setup
Verifying and authenticating are two different steps. Verification is an emailed code that proves you own the domain (and unlocks From addresses on it); authentication is the two DKIM CNAMEs plus DMARC. You must verify first — and codes/links expire after 7 days.
DNS setup
You can no longer send campaigns from a free public From address. Yahoo and AOL publish p=reject, and Gmail's and Yahoo's own bulk-sender rules forbid third parties from sending as their users — so a campaign “from” gmail.com, yahoo.com, or aol.com can't DKIM-align to that domain and fails DMARC. Mailchimp now blocks these From addresses outright; send from your own verified, authenticated domain instead.
DNS setup
Cloudflare proxy breaks it: set both CNAMEs to “DNS only” (grey cloud). An orange-cloud proxied CNAME won't resolve to mcsv.net and Mailchimp's check fails.
DNS setup
Host-field doubling: many registrars auto-append your domain, so entering k2._domainkey.yourdomain.com becomes k2._domainkey.yourdomain.com.yourdomain.com. Enter just the label (k2._domainkey / k3._domainkey) when the panel adds the domain for you.
DNS setup
Old vs new selectors: legacy Mailchimp accounts used a single k1._domainkey → dkim.mcsv.net CNAME; current authentication uses the k2/k3 pair. Add whatever your account screen shows — don't mix a tutorial's values with yours.
Coverage
Subdomains authenticate separately. If you send from mail.yourdomain.com, verify and authenticate that subdomain on its own — the root domain's records don't cover it.
Breaks auth
Keep one SPF and one DMARC record. If you already send via Google Workspace or Microsoft 365, don't publish a second SPF TXT or a second _dmarc record — two of either is itself a failure (SPF PermError / invalid DMARC).

Build your SPF record

Mailchimp doesn't need an SPF include: on your root domain — use the generator to assemble one clean record for your other senders, and keep it to a single line.

Sending sources

Search for each platform you send email through and tick it.

Search for your email platform above, or .

This domain's own servers

Authorize the domain itself, if it sends mail directly (not through a platform above).

a — the domain's own A recordmx — the domain's MX hosts

Other senders & IPs

Anything not in the list — another provider's SPF host, or specific IP addresses.

Additional includes

We add the include: prefix — enter the hostname your provider documents.

IPv4 addresses

IPv6 addresses

Policy for everyone else

What receivers should do with mail from any server not listed above (the all mechanism).

-all (fail)Strict — receivers should reject mail from any server not listed.~all (softfail)Recommended default — unlisted senders are accepted but marked suspicious.?all (neutral)No opinion — provides almost no protection; use only while testing.

Your SPF record0/10 DNS lookups

v=spf1 ~all

No senders yet, so every message would hit the ~all policy. Add the platforms you send through in step 1.

Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.

Authentication published? The next step is sending to a clean, verified list.

Verify a list