Email Authentication for Mailchimp: SPF, DKIM, DMARC Guide

6 May 2026 · 12 min read

Mailchimp sends your marketing email from its own servers, not yours. That single fact is why so many Mailchimp campaigns either land in spam or quietly fail authentication: the mail leaves Mailchimp's IP addresses, carries Mailchimp's bounce address, and signs with Mailchimp's keys, yet your subscribers expect it to come from your brand. To make that work cleanly, and to keep working once you move DMARC to p=reject, you need to line up three things in your own DNS: an SPF record that authorises Mailchimp, a published DKIM key pair that Mailchimp generates for you, and a sending configuration that produces DMARC alignment on your real domain.

This guide is specific to Mailchimp. It uses Mailchimp's actual includes, selectors and CNAME targets, explains where alignment quietly breaks, and walks the path from p=none to p=reject without losing a single campaign.

How Mailchimp actually sends your email

Before touching DNS, it helps to know what Mailchimp puts on the wire, because each header drives a different authentication check.

When a campaign goes out, a typical message envelope and header set looks like this:

MAIL FROM (Return-Path): bounce-mc.us1_12345678.901234-you=yourdomain.com@mail123.atl11.mcsv.net
From: Your Brand <hello@yourdomain.com>
DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=dkim; ...
DKIM-Signature: v=1; a=rsa-sha256; d=mailchimpapp.net; s=k3; ...

Three separate identities are in play, and they map onto the three checks:

SPF validates the Return-Path (the MAIL FROM envelope sender), not the visible From. By default Mailchimp uses its own mcsv.net bounce domain, so SPF passes for mcsv.net, which is not your domain. That is fine for delivery but useless for DMARC alignment.
DKIM can sign with two domains at once. Mailchimp always adds its own signature on mailchimpapp.net. If you complete domain authentication, it also adds a second signature on your domain (d=yourdomain.com), and that one is what DMARC cares about.
DMARC passes if either SPF or DKIM passes and aligns with the domain in the visible From header. Alignment means the passing domain matches your From domain.

The practical upshot: the default Mailchimp setup gives you DKIM alignment once you authenticate your domain, and that single aligned DKIM signature is enough to satisfy DMARC, even at p=reject. SPF alignment is optional and only achievable with extra steps. Get DKIM right first.

Step 1: Authenticate your domain in Mailchimp (DKIM)

Mailchimp's "domain authentication" wizard is really a DKIM and Return-Path setup. In current Mailchimp it lives under your profile or account settings, under Domains (sometimes labelled Verified domains or Authenticated domains). The flow is:

Add and verify your sending domain (Mailchimp emails a verification code to an address at that domain, or asks you to add a TXT record).
Mailchimp then shows you a set of DNS records to publish. These are the authentication records.

For DKIM, Mailchimp uses CNAME records rather than handing you a raw public key. The classic Mandrill-style records Mailchimp publishes look like this:

Type   Host (Name)              Value (Target)
CNAME  k1._domainkey            dkim.mcsv.net
CNAME  k2._domainkey            dkim2.mcsv.net
CNAME  k3._domainkey            dkim3.mcsv.net

Newer Mailchimp accounts using the rebuilt sending stack may instead give you records on mailchimpapp.net style selectors, for example:

Type   Host (Name)                          Value (Target)
CNAME  abc123._domainkey                    abc123.dkim.mailchimpapp.net
CNAME  def456._domainkey                    def456.dkim.mailchimpapp.net

The exact selector strings and targets are generated per account, so copy them from your own Mailchimp screen rather than from any guide, including this one. The pattern, though, is always the same: a host of the form <selector>._domainkey.yourdomain.com pointing via CNAME at a Mailchimp-controlled DKIM host.

A few things people get wrong here:

Do not append your domain to the Host field if your DNS host adds it automatically. Many panels (Cloudflare, most registrars) treat k1._domainkey as relative and append the zone. If you type k1._domainkey.yourdomain.com you can end up with k1._domainkey.yourdomain.com.yourdomain.com. Check the resulting full name after saving.
CNAMEs cannot coexist with other records on the same name. That is almost never a problem for _domainkey selectors, but it does mean you cannot add a TXT comment on the same host.
If you already run your own DKIM (for Google Workspace or Microsoft 365 on the same domain), that is fine. DKIM selectors are namespaced, so Mailchimp's k1, k2, k3 live happily alongside Google's google._domainkey and Microsoft's selector1/selector2. Each provider signs with its own selector.

Once published and verified, every campaign carries DKIM-Signature: d=yourdomain.com. Confirm it resolves before relying on it:

Run your selector through the DKIM checker (enter the selector Mailchimp gave you, such as k1, and yourdomain.com).
After your first send, view the raw headers of a received message and check that a signature with d=yourdomain.com is present and shows dkim=pass.

Step 2: Decide what to do about SPF

Here is where Mailchimp differs from a provider like Google Workspace, and where a lot of confusing advice lives.

By default, Mailchimp's bounce address is on mcsv.net, so SPF authentication and SPF alignment both happen on Mailchimp's domain, not yours. You do not need to add Mailchimp to your SPF record for delivery to work, because the SPF check runs against the mcsv.net Return-Path, which Mailchimp already authorises.

So when is include:servers.mcsv.net relevant? Two situations:

You use a custom Return-Path / custom bounce domain. Mailchimp lets some plans set the envelope sender to a subdomain of yours (for example bounce.yourdomain.com). If you do that, SPF is then evaluated against your subdomain, and you must authorise Mailchimp's sending infrastructure there.
You want belt-and-braces SPF alignment in addition to DKIM, so that DMARC passes on both mechanisms.

If either applies, the include Mailchimp uses is:

v=spf1 include:servers.mcsv.net ~all

When you already send from other services, you merge it into one record. SPF only permits one v=spf1 record per domain, and there is a hard limit of 10 DNS lookups when evaluating it. A realistic combined record for a domain on Google Workspace plus Mailchimp custom bounce looks like:

v=spf1 include:_spf.google.com include:servers.mcsv.net ~all

Two warnings that bite Mailchimp users specifically:

Do not publish a second SPF record. If your DNS already has v=spf1 ..., edit it. Two SPF TXT records produce a permerror, and SPF then fails for everyone, including Mailchimp.
servers.mcsv.net costs lookups. Combined with Google, Microsoft, a CRM and a help desk you can blow past 10 lookups, which silently turns SPF into a permerror. If you are near the limit, flatten the record. Our SPF checker counts the lookups for you and flags permerror before mailbox providers do.

For most Mailchimp setups using the default bounce domain, skip SPF entirely and rely on DKIM alignment. It is one fewer thing to maintain and one fewer way to exceed the lookup limit.

Step 3: Understand alignment, the part DMARC actually checks

DMARC does not care that SPF or DKIM passed in the abstract. It cares whether a passing mechanism aligns with the domain in your visible From address. This is the crux of making Mailchimp DMARC-compliant.

With Mailchimp's defaults:

From: hello@yourdomain.com
SPF pass domain: mcsv.net (Mailchimp's bounce) -> does not align with yourdomain.com
DKIM pass domain: yourdomain.com (your authenticated signature) -> aligns

Because DMARC passes if either mechanism aligns, the aligned DKIM signature carries you. SPF being unaligned is harmless. This is why DKIM authentication in Step 1 is non-negotiable and SPF in Step 2 is optional.

Two alignment subtleties for Mailchimp:

DMARC uses relaxed alignment by default, so mail.yourdomain.com in a DKIM d= aligns with a From of yourdomain.com. You only hit strict-alignment problems if you deliberately set aspf=s or adkim=s in your DMARC record. Do not, unless you have a specific reason.
Sending from a subdomain. If your campaigns go From news.yourdomain.com, then DMARC for that mail is governed by the policy on news.yourdomain.com (or, if absent, the organisational policy via the sp= tag on yourdomain.com). Make sure the DKIM signature is on the same subdomain or its parent. Authenticate the exact domain in Mailchimp that you send From.

To see exactly which domain is passing and whether it aligns, paste a received Mailchimp message's headers, or just check your live policy with the DMARC checker.

Step 4: Publish a DMARC record in monitoring mode

Do not jump to enforcement. Publish a p=none record first so reports start flowing while nothing is rejected. The record is a single TXT record at _dmarc.yourdomain.com:

Type   Host                     Value
TXT    _dmarc                   v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; fo=1; adkim=r; aspf=r

What each tag is doing here:

p=none -> observe only; nobody rejects or quarantines yet.
rua= -> where aggregate (daily summary) reports go. This is the data you need.
ruf= -> where forensic/failure samples go, when senders provide them (many do not).
fo=1 -> ask for a failure report if any mechanism fails alignment, which surfaces Mailchimp misconfigurations early.
adkim=r; aspf=r -> relaxed alignment, matching the defaults above.

If you do not have an inbox to point rua at, or you do not fancy reading XML, point it at a monitoring address. Our monitoring service ingests the aggregate reports and turns them into a readable picture of who is sending as you, including whether Mailchimp is passing. You can also generate a correct record with the DMARC generator.

Step 5: Read the reports and confirm Mailchimp passes

Leave p=none running for one to four weeks, long enough to capture a real campaign cycle. Aggregate reports are XML; each one lists source IPs, the From domain, and pass/fail for SPF and DKIM with alignment.

You are looking for the Mailchimp source IPs (they resolve to mcsv.net / mcdlv.net / mandrillapp.com hostnames) showing:

DKIM: pass, aligned on yourdomain.com.
SPF may show pass on mcsv.net, unaligned. That is expected and fine.
DMARC result: pass, because aligned DKIM is present.

Paste a report into the DMARC report analyzer to decode the XML without reading it by hand. Two failure patterns are common and worth naming:

Mailchimp sending but DKIM not aligned. Usually means domain authentication was never completed, or you authenticated a different domain from the one you send From. Revisit Step 1.
An unexpected source failing DMARC. Reports often reveal a forgotten sender (an old form tool, a billing system) sending as your domain. Fix or authorise those before you enforce, or you will block your own legitimate mail.

This watching period is the whole point of p=none: it is your safety net against turning on enforcement while a legitimate sender is still unaligned.

Step 6: Move to quarantine, then reject

Once your reports show Mailchimp (and every other legitimate source) passing DMARC with alignment, tighten the policy in two steps. Never jump straight from none to reject.

First, quarantine a slice of mail to test the water using the pct tag:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourdomain.com; fo=1

This sends 25% of failing mail to spam while 75% is still treated as none. Watch reports for a week. If nothing legitimate is affected, raise to pct=100, then after another clean week, go to full enforcement:

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; fo=1

At p=reject, any mail claiming to be from yourdomain.com that fails alignment is bounced outright. Because your Mailchimp campaigns carry an aligned DKIM signature, they sail through. Spoofed mail does not. Confirm the live policy with the DMARC checker after each change, since DNS typos at this stage are unforgiving.

A subdomain note: if you send marketing from news.yourdomain.com, set the parent policy and an explicit subdomain policy so nothing leaks through an unprotected subdomain:

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@yourdomain.com; fo=1

Mailchimp specifics that trip people up

A grab-bag of issues unique to, or amplified by, Mailchimp:

The "via mailchimpapp.net" or "via mcsv.net" annotation in Gmail. Gmail shows a "via" line when the visible From domain does not match the signing or bounce domain it sees. Completing DKIM authentication on your domain removes it, because Gmail then sees an aligned signature on yourdomain.com. If you still see "via", your domain authentication is incomplete or not yet propagated.
Mailchimp Transactional (Mandrill). This is a separate product with its own domain and DKIM setup. Authenticating your domain for Mailchimp marketing campaigns does not authenticate Mandrill. If you use both, set up DKIM in each, using the records each shows you. They share the mcsv.net heritage but are configured independently.
Using a free or shared From address. If you try to send From yourname@gmail.com or @yahoo.com, you cannot authenticate it (you do not control that DNS), and since 2024 Gmail and Yahoo enforce DMARC on bulk senders. Mailchimp will warn you. Send From a domain you own and can authenticate.
CNAME flattening and proxying. On Cloudflare DNS, ensure the _domainkey CNAMEs are DNS-only (grey cloud), never proxied (orange cloud). Proxying a DKIM CNAME breaks the lookup. The same applies to any Return-Path CNAME if you use a custom bounce domain.
Propagation lag. After publishing, give DNS time. Mailchimp's "Authenticate" button can report failure simply because the CNAME has not propagated yet. Re-check in 30 to 60 minutes rather than re-entering everything.
List-Unsubscribe. Not strictly authentication, but the same 2024 bulk-sender rules require a one-click List-Unsubscribe-Post header. Mailchimp adds this automatically for campaigns, so you get it for free, but it is part of being a compliant bulk sender alongside DMARC.

Optional: SPF alignment with a custom bounce domain

If you want SPF to align as well as DKIM (true belt-and-braces, useful if you ever forward mail in ways that break DKIM), and your plan supports a custom Return-Path, the steps are:

In Mailchimp, set the custom bounce / Return-Path to a subdomain such as bounce.yourdomain.com.
Publish the CNAME Mailchimp gives you for that subdomain (it points the bounce host at Mailchimp's infrastructure).
Add include:servers.mcsv.net to the SPF record on that subdomain, since SPF is evaluated against the bounce subdomain, not your root.

Now SPF passes on bounce.yourdomain.com, which under relaxed alignment aligns with a From of yourdomain.com. You then have both mechanisms aligned. For most senders this is unnecessary; aligned DKIM alone satisfies DMARC at p=reject. But it is a genuine resilience improvement for high-volume programmes.

Going further: MTA-STS and BIMI

Once DMARC is at enforcement and Mailchimp passes cleanly, two add-ons are worth considering:

MTA-STS enforces TLS on inbound mail to your domain. It is independent of Mailchimp (it protects mail coming to you), but completing it rounds out your posture. Check yours with the MTA-STS checker.
BIMI can display your logo next to authenticated mail in supporting inboxes, and it requires DMARC at p=quarantine or p=reject first. Because Mailchimp campaigns are exactly the brand-heavy mail where a logo helps, reaching DMARC enforcement unlocks real visual payoff. Validate your record with the BIMI checker, and see /products/bimi for what is involved.

The short version

For a standard Mailchimp setup, the entire job is:

Authenticate your domain in Mailchimp so it signs with d=yourdomain.com. Publish the k1/k2/k3._domainkey (or mailchimpapp.net-style) CNAMEs it gives you. This alone produces DKIM alignment.
Leave SPF alone unless you use a custom bounce domain; the default mcsv.net bounce means SPF need not, and cannot, align, and aligned DKIM is sufficient.
Publish _dmarc at p=none with a rua address and watch the reports.
Confirm Mailchimp shows DKIM pass + aligned, then ramp p=quarantine pct=25 -> pct=100 -> p=reject.

Done in that order, you reach p=reject with your Mailchimp campaigns fully authenticated and no delivery scare. Start by checking what is live today with the DMARC checker and the DKIM checker. If you would rather not babysit the XML reports and the ramp, our done-for-you service takes the domain from p=none to p=reject for you, with Mailchimp and every other sender verified along the way, and our monitoring tells you the moment a source stops aligning.

Email authentication for Mailchimp: SPF, DKIM and DMARC