Mailchimp DMARC Setup: Getting a Third-Party Sender Into Alignment

Why a third-party sender is the thing that breaks DMARC

Your DMARC record does not know what Mailchimp is. It tells receiving servers to distrust any message carrying your domain in the From line without a matching, authenticated signature. Mailchimp sends exactly that kind of message on your behalf. Raise the policy to p=quarantine or p=reject while Mailchimp is unauthenticated and you have asked the internet to junk your own newsletter.

Under p=quarantine the failure is quiet. Mailchimp records the message as sent, nothing bounces, and the cause does not surface in the interface. Under p=reject, Gmail returns a 5.7.26 rejection whose text names your DMARC policy. Your aggregate reports show it, and so do the raw headers of a delivered message.

The fix is not to weaken your policy. It is to make Mailchimp sign as you.

The envelope sender is not the From address

Every message carries two sender identities. Your recipient sees the From header. Servers exchange a second at the SMTP level: the envelope sender, also called the Return-Path or bounce address. SPF only checks that second one.

Mailchimp documents its envelope sender openly. It comes from Mailchimp's own sending servers and contains mcsv.net, mcdlv.net, mailchimpapp.net, or rsgsv.net. Mailchimp publishes correct SPF for that infrastructure, so SPF passes.

That pass is not yours. DMARC does not reward an SPF pass on its own. It checks whether the domain that passed matches the domain in the visible From, and that match is called alignment. Mailchimp's envelope domain is a Mailchimp domain, so SPF cannot align on a standard Mailchimp campaign. DKIM is the only alignment path you have.

What changed under the Google and Yahoo rules

Google began enforcing sender requirements on February 1, 2024. Yahoo began enforcement in February 2024 and rolled it out gradually. Senders above 5,000 messages a day to Gmail need SPF, DKIM and a published DMARC record, and both state that the From domain must align with either the SPF domain or the DKIM domain. For Mailchimp that has one answer: SPF cannot align, so the alignment has to come from DKIM.

Mailchimp Transactional, formerly Mandrill, went further. From March 15, 2024 it stopped sending from domains without valid DKIM records and a DMARC policy. Where a domain falls short, it substitutes a mandrillapp.com subdomain as the sending domain, and replies still route to your address.

The marketing side nags rather than blocks. The Home screen can show a banner warning that emails from your domain may miss 74% of inboxes.

Where domain authentication lives in Mailchimp

Verification and authentication sit in the same panel and are not the same thing. Verification proves you can read mail at the address, and Mailchimp requires it before you can send. It does nothing for delivery. Authentication is the DNS work that does.

Mailchimp now leads with Entri, which connects to your DNS provider and writes the records for you. To see what is being published instead, click Or manually authenticate your domain.

• Click your profile icon and choose Account & billing. Managers see Account instead.
• Click the Domains tab.
• If the domain is not verified, use Add & Verify Domain in the Email Domains section first.
• Click Start authentication next to the verified domain.
• Pick your provider from the Select your DNS provider dropdown, then click Next.

The exact records Mailchimp asks you to publish

Two CNAME records and one TXT record. The CNAMEs carry DKIM. The TXT record is DMARC. No SPF record appears in the flow, and there is no key for you to paste.

The CNAMEs are pointers, not keys. Mailchimp holds the key pair, which is how it rotates keys without you touching DNS. Copy the Name and Value your account shows for CNAME 1 and CNAME 2.

Older setups used one record, k1._domainkey pointing at dkim.mcsv.net. That legacy key is 1024 bits. The k2 and k3 keys are 2048 bits. Google requires at least 1024 bits for personal Gmail and recommends 2048, so a zone carrying only k1 belongs in the current flow.

Mailchimp Transactional authenticates separately: mte1._domainkey pointing at dkim1.mandrillapp.com, and mte2._domainkey pointing at dkim2.mandrillapp.com.

• CNAME, name k2._domainkey.yourdomain.com, value dkim2.mcsv.net
• CNAME, name k3._domainkey.yourdomain.com, value dkim3.mcsv.net
• TXT, host _dmarc, value as Mailchimp shows it

Does Mailchimp need an SPF include?

No. The current flow does not ask for one. Mailchimp's older article covering DKIM and SPF now redirects to the domain authentication article, which lists two CNAMEs and one TXT record and no SPF at all.

The old include still resolves: servers.mcsv.net publishes a valid SPF record built from three IPv4 ranges. Adding it will not break your mail, and will not help either, because your SPF record is not the one being evaluated on a Mailchimp send. Mailchimp's envelope domain is.

It does cost you. RFC 7208 caps SPF evaluation at ten DNS-querying terms, counting include, a, mx, ptr, exists and redirect. Exceed ten and the checking server must return permerror, which fails SPF for every message from your domain, including mail from your mailbox provider. Do not spend a lookup on a sender that cannot align through SPF anyway.

Custom return path, and which Mailchimp product offers one

A custom return-path or bounce domain is the setting that fixes SPF alignment. It moves the envelope sender onto a subdomain of your own domain, which is what relaxed alignment needs. Mailchimp offers it on one product only.

Mailchimp Transactional supports one. Create a CNAME for a subdomain, mail.example.com for instance, pointing at mandrillapp.com. It has to be a subdomain, not the root domain. Then go to Settings, then Tracking & Return Path Domains, enter the subdomain, click Add, and click Test DNS Settings. Apply it globally from Sending Defaults, or per message with the return_path_domain parameter or the X-MC-ReturnPathDomain header.

Mailchimp calls this often cosmetic. For DMARC it is not, because it is the one setting that puts the SPF identity under your name. Mailchimp still processes the bounces, so use webhooks if you need the data.

Standard Mailchimp campaigns have no equivalent. No return-path field, no bounce domain, no sending subdomain. For marketing sends, DKIM alignment is the whole game.

What Mailchimp does to your visible From address

Without authentication, some clients display on behalf of mcsv.net or via mailchimpapp.net beside your sender name. Mailchimp says DKIM authentication removes that in most email clients, and that Outlook may still display it afterwards, which is outside Mailchimp's control.

If your From address sits on a free domain such as gmail.com or yahoo.com, Mailchimp rewrites it outright. It sends from a send.mailchimpapp.com or mail.mailchimpapp.com subdomain, so thepottedplanter@yahoo.com goes out as thepottedplanter.yahoo.com@send.mailchimpapp.com. The From domain then matches the sending domain and passes DMARC, and replies still reach you.

Read that trade honestly. Your brand leaves the From line, and free domains cannot be verified, authenticated, or carry BIMI, so no logo and no checkmark in Gmail. The rewrite is a patch. A domain you own is the fix.

Verify with Authentication-Results, not the green tick

Mailchimp shows Authentication in progress, then an Authenticated label, and says validation can take up to 48 hours. That label means Mailchimp found its records. It says nothing about what a receiving server concluded about a real message.

Check DNS from outside first. Run dig +short CNAME k2._domainkey.yourdomain.com and expect dkim2.mcsv.net, then repeat for k3. On Windows, use nslookup -type=CNAME. An empty answer points at the Name field, where your domain has probably been doubled.

Then send a real campaign to a Gmail address. Open it, click the three dot menu, choose Show original, and read the Authentication-Results header.

• header.from should be your own domain
• spf will report pass against an smtp.mailfrom value on a Mailchimp domain. That is expected, and it is not alignment.
• dkim must report pass with d= set to your domain. Check the DKIM-Signature header and confirm s= is k2 or k3.
• dmarc must report pass
• If more than one dkim result appears, only the one whose d= is your own domain counts. A signature on a Mailchimp domain is Mailchimp vouching for Mailchimp.

One DMARC record, and the senders you have not counted

Publish exactly one DMARC record. RFC 9989, the current DMARC standard, says that when multiple policy records are returned for a single target, they are all discarded. A second record added by the Mailchimp flow on top of yours does not double your protection. It switches DMARC off. If a _dmarc record already exists, skip Mailchimp's TXT step.

Mailchimp is one sender among several, and DMARC applies to all of them at once. Before you move past p=none, write down every system that puts your domain in a From line and confirm each signs with DKIM on your domain.

Read the reports arriving at your rua address until nothing legitimate is failing, then move to p=quarantine, then p=reject. A policy is a request. RFC 9989 leaves the final handling decision with the receiving server, so p=reject is a strong signal rather than a guarantee.

• Mailchimp campaigns and automations
• Mailchimp Transactional, authenticated separately with mte1 and mte2 records
• Your mailbox provider, such as Google Workspace or Microsoft 365
• Store notifications, helpdesk, invoicing and form tools

If you would rather not do it yourself

This is an afternoon of work for someone comfortable editing DNS. If that is you, take the guide and go. We would rather you succeed than hire us.

If you would rather hand it over, that is what Verified Everywhere does. We publish the records, build the sender inventory, read the reports, and tell you when the data supports enforcement. We never ask for passwords, government ID documents or card numbers.