DMARC for Mailchimp users: a deliverability checklist

5 June 2026 · 15 min read

If you send marketing email through Mailchimp, you sit in an awkward spot. You do not run your own mail servers, you do not control the IP addresses your campaigns go out on, and yet your From: address still says @yourbrand.com. The recipient's mailbox provider judges that mail against your domain's reputation and your domain's authentication, not Mailchimp's. So when Gmail and Yahoo tightened their bulk-sender rules and started demanding DMARC, the burden landed on you, the domain owner, even though Mailchimp does the actual sending. This checklist is the practical version of what you need to do: get authentication aligned so Mailchimp mail passes DMARC, satisfy the bulk-sender requirements, keep your list clean enough to stay out of the spam folder, and then move your domain to a real enforcement policy without your newsletters quietly disappearing.

It is written for the common case: you have a domain, you send campaigns and automations through Mailchimp, and you may also send normal business mail through Google Workspace or Microsoft 365 from the same domain. Everything here is specific to that setup. None of it requires you to leave Mailchimp or change how you build campaigns.

Why Mailchimp users have a DMARC problem at all

DMARC works by checking that a message is authenticated and that the authenticated identity lines up with the domain in the visible From: header. There are two underlying checks, SPF and DKIM, and DMARC passes when at least one of them both verifies and aligns with your From: domain. The full mechanics are in what is DMARC and DMARC alignment explained, but the short version is that "passing SPF" or "passing DKIM" is not enough on its own. The pass has to be for your domain.

This is exactly where third-party senders like Mailchimp trip people up. By default, Mailchimp sends your campaign from its own infrastructure. The envelope sender (the Return-Path, what SPF actually checks) belongs to a Mailchimp domain, not yours. So SPF passes, but it passes for Mailchimp, and that does nothing for your DMARC alignment because the SPF-authenticated domain is not the one in your From:. The whole question of which "From" each check looks at is covered in header-from versus envelope-from, and it is the single most misunderstood thing about authenticating a service like Mailchimp.

DKIM is where you actually win. If you authenticate your domain inside Mailchimp, Mailchimp signs your outgoing campaigns with a DKIM key published under your domain. That signature verifies against a public key in your DNS, and because the signing domain matches your From: domain, DKIM aligns, and DMARC passes on DKIM alone. SPF can keep failing alignment forever and your DMARC will still be fine, because DMARC only needs one aligned pass. So for Mailchimp, the entire game is DKIM alignment. Get that right and almost everything else follows.

You can confirm the current state of any of this with the free tools before you change a thing: the DMARC checker shows your published policy, the DKIM checker inspects a selector, and the SPF checker shows what your SPF record authorises.

The authentication checklist

This is the part that has to be correct before anything else matters. Work through it in order.

1. Authenticate your domain inside Mailchimp

In Mailchimp this is the "Verified Domains" / domain authentication step under your account's domain settings. When you authenticate, Mailchimp gives you DNS records to publish, historically a set of CNAME records that point your domain's DKIM selectors and tracking back at Mailchimp's infrastructure. Publishing them does two things:

• It lets Mailchimp sign your campaigns with a DKIM key that lives under your domain, so DKIM aligns with your From: and DMARC passes.
• It sets up a custom Return-Path (a CNAME for the bounce domain) so Mailchimp's SPF can be evaluated under a subdomain of yours, which also brings SPF into alignment in many configurations.

Do not skip this and do not rely on Mailchimp's default unauthenticated sending. Without domain authentication you are sending under a shared Mailchimp identity, your DMARC will fail, and at any enforcing policy your campaigns get quarantined or rejected. After you publish the records, send a test campaign to an inbox you control and inspect the headers. You want to see a DKIM-Signature whose d= value is your own domain (or a subdomain of it), and an Authentication-Results line reading dkim=pass with that domain. The email header analyzer will lay this out for you if reading raw headers is not your idea of fun.

2. Confirm DKIM is aligned, not just passing

"Aligned" and "passing" are different. A campaign can show dkim=pass for a Mailchimp-owned domain and still fail DMARC because that domain is not yours. After authenticating, the d= in the DKIM signature must be your domain or a subdomain of it. By default DMARC uses relaxed alignment, which means a signature from a subdomain such as mail.yourbrand.com aligns with a From: of yourbrand.com. That is fine and very common with Mailchimp. The difference between relaxed and strict is explained in relaxed versus strict DMARC alignment; for almost everyone, leave alignment relaxed.

If you see DKIM passing but DMARC still failing, the cause is almost always alignment, and the diagnosis path is in DMARC fails but SPF and DKIM pass.

3. Do not try to fix this by stuffing Mailchimp into your SPF record

A very common mistake is to read "SPF is failing for my Mailchimp mail" and react by adding Mailchimp's include to your SPF record, or by listing a pile of IP ranges. Two problems with this. First, you usually do not need it: DKIM alignment already carries your DMARC, so SPF alignment is a bonus, not a requirement. Second, SPF has a hard limit of ten DNS lookups, and every include you bolt on eats into it. Blow past ten and your SPF record returns permerror, which can break SPF for all your senders at once, including your normal business mail. The limit and how to recover from it are covered in SPF too many DNS lookups and fix SPF permerror.

If you genuinely have a sprawling SPF record across Mailchimp, your mailbox host, and other tools, the fix is flattening rather than piling on more includes. See how SPF flattening works and the DNS record splitter for the mechanics, and run your current record through the SPF checker to see your lookup count. Keep one SPF record per domain; multiple SPF records is itself an error, as explained in fix multiple SPF records.

4. Make sure all your other senders are authenticated too

Your DMARC policy applies to every message that uses your domain in the From:, not just Mailchimp. If you publish p=reject and your invoicing tool, your helpdesk, your CRM, or your own Google Workspace mail is not aligned, those messages get rejected as well. So before you enforce, inventory every service that sends as your domain. Mailchimp is one source; you will usually find five to fifteen. The way you discover them all is through DMARC aggregate reports, which is the next section. The general approach to taking a domain to enforcement without collateral damage is in reach p=reject without breaking email.

5. Publish a DMARC record in monitoring mode first

Start at p=none with a reporting address so you collect data without affecting delivery. A minimal starting record looks like this:

v=DMARC1; p=none; rua=mailto:reports@yourbrand.com; fo=1

p=none tells receivers to take no action but to send you reports. rua is where the daily aggregate reports go. The meaning of every tag is in the DMARC record explained, and you can build a correct record with the DMARC generator. Crucially, do not stay at p=none. It protects nobody; it is a measurement phase. The false comfort of parking there permanently is the subject of p=none and its false sense of security.

The bulk-sender rules you actually have to meet

Since February 2024, Gmail, Yahoo, and Microsoft have enforced requirements on anyone sending bulk email, which for these purposes means roughly 5,000 or more messages a day to their users, though the bar for good behaviour applies to everyone. Mailchimp customers are squarely in scope. The detail is in Gmail, Yahoo and Microsoft now require DMARC; here is what it means in checklist form.

Authenticate with both SPF and DKIM

The rules want your mail authenticated. For Mailchimp, completing domain authentication (step 1 above) gives you DKIM alignment and, via the custom Return-Path, SPF too. Verify both with the DMARC checker and a header inspection of a real campaign.

Publish a DMARC policy

You must have a DMARC record published for your domain. The bulk-sender rules accept p=none as the minimum to clear the gate, which is why so many senders published p=none in early 2024 and stopped. That clears the requirement but leaves your domain spoofable. Treat p=none as the floor you start on, not the destination.

Keep your spam-complaint rate low

Gmail in particular wants your spam-complaint rate (as seen in Postmaster Tools) kept below 0.3%, and ideally under 0.1%. This is a list-hygiene number, not an authentication number, and it is where Mailchimp senders most often get burned. More on this below.

Honour one-click unsubscribe

Bulk marketing mail must include a working List-Unsubscribe header that supports one-click unsubscribe (RFC 8058), and the unsubscribe must be actioned within a couple of days. Mailchimp adds the required List-Unsubscribe headers to campaigns automatically, so for standard campaigns this is handled for you. The thing you must not do is suppress or strip those headers with custom footers or odd templates, and you must actually process unsubscribes promptly rather than treating them as suggestions.

Send aligned, relevant mail from a consistent domain

Reputation accrues to a domain over time. Sending your marketing from a stable, authenticated domain (or a dedicated marketing subdomain) and not constantly switching From: addresses helps the mailbox providers build a stable picture of you. Which brings us to a decision worth making deliberately.

Should you send Mailchimp from a subdomain?

A lot of experienced senders put their marketing mail on a dedicated subdomain, for example news.yourbrand.com or email.yourbrand.com, rather than the bare yourbrand.com. There are real reasons to consider it for Mailchimp:

• Reputation isolation. A marketing list, by nature, draws more spam complaints and hits more dead addresses than your one-to-one business mail. Putting campaigns on a subdomain keeps that volatility off the reputation of the domain you use for invoices, password resets, and replies to customers.
• Policy independence. You can run a different DMARC posture on the subdomain while you stabilise it, using either a dedicated DMARC record on the subdomain or the parent's sp (subdomain policy) tag. The mechanics are in subdomain DMARC records and the subdomain policy sp tag, and the broader strategy is in subdomain sending strategy.
• Cleaner authentication. Authenticating Mailchimp under a subdomain keeps its DKIM selectors and Return-Path neatly scoped, and relaxed alignment still lets news.yourbrand.com align with a From: on the subdomain.

The trade-off is that a brand-new subdomain has no sending reputation and has to warm up. If you choose this route, set your From: to the subdomain in Mailchimp, authenticate the subdomain, and remember that your organisational DMARC policy still governs it. If your parent domain publishes p=reject with no sp tag, that reject applies to the subdomain too unless you publish a separate, more lenient subdomain record while warming up. Do not let a subdomain warm-up fail silently against an inherited p=reject.

The list-hygiene checklist

Authentication gets your mail accepted as genuinely from you. List hygiene is what keeps it landing in the inbox rather than the spam folder, and it is what keeps your spam-complaint rate under the bulk-sender thresholds. Authentication and hygiene are two separate jobs and you need both.

Use confirmed opt-in and stop importing cold lists

The fastest way to wreck a domain's reputation is to upload a purchased or scraped list and blast it. Those addresses generate hard bounces (dead mailboxes), spam complaints, and hits on spam-trap addresses, all of which the mailbox providers count against you. Use confirmed (double) opt-in where you can, and never import a list you did not collect with consent. A single bad import can poison a domain's reputation for weeks.

Clean bounces and unengaged contacts regularly

• Remove hard bounces immediately. Mailchimp does this automatically for confirmed hard bounces, but watch it. Repeatedly mailing dead addresses is a strong negative signal.
• Suppress chronically unengaged contacts. People who have not opened or clicked in, say, six months are dragging your engagement metrics down and raising your complaint risk. Segment them out, run a single re-engagement campaign, and then archive the ones who still do not respond. Inbox placement is heavily driven by engagement; a smaller engaged list outperforms a larger dead one.
• Watch role addresses and typos. info@, sales@, and obvious typo domains inflate complaints and bounces.

Make unsubscribing trivially easy

Counterintuitively, a prominent unsubscribe link lowers your spam-complaint rate, because people who want out click unsubscribe instead of hitting the "report spam" button. A spam complaint hurts you far more than an unsubscribe. Keep Mailchimp's footer and one-click unsubscribe intact and visible. Do not hide it, do not require a login to unsubscribe, and do not make people email you to be removed.

Warm up new domains and volume gradually

If you have just moved to a new sending domain or subdomain, do not jump from zero to a 200,000-recipient send. Ramp volume over a couple of weeks, sending to your most engaged contacts first, so the providers build a positive reputation before you hit full scale. You can sanity-check that your sending domain and IPs are not already on a blocklist with the blacklist checker, and get a rough inbox-readiness read from the deliverability score tool.

Keep content and identity consistent

Sudden changes in volume, a From: address nobody recognises, or content that looks nothing like your past sends all suppress placement. Consistency is a feature. Send from the same authenticated domain, with recognisable branding, on a predictable cadence.

Reading your DMARC reports to find every Mailchimp (and non-Mailchimp) source

Once you are at p=none with rua reporting, the daily aggregate reports are how you find every service sending as your domain and confirm Mailchimp is aligned before you enforce. These reports are XML and unpleasant to read by hand, so paste them into the DMARC report analyzer, and read reading your first DMARC report for orientation.

What you are looking for:

• Mailchimp showing as an aligned, passing source. You should see Mailchimp's sending IPs with DKIM passing and aligned to your domain. If Mailchimp appears but DKIM is failing or unaligned, your domain authentication is incomplete; go back to step 1.
• Every other legitimate source accounted for. Your mailbox provider, your CRM, your support desk, your billing system. Each must be authenticated and aligned before you raise the policy, or its mail will be caught when you enforce. Sources you cannot immediately place are addressed in DMARC reports show unknown sources.
• Spoofing and shadow IT. Failing mail from IPs you do not recognise is often either a forgotten tool or an actual spoofing attempt. Either way you want to know before you flip to reject.

Give this a few weeks so the reports cover your full sending pattern, including monthly or seasonal campaigns, before you move the policy.

Moving to enforcement without breaking your campaigns

Enforcement means p=quarantine and ultimately p=reject. This is the point of the whole exercise: at p=reject, a forger cannot put your domain in the From: of a phishing mail and have it land, because receivers will reject anything from your domain that is not authenticated and aligned. The staged approach, explained in DMARC from none to reject safely, goes like this.

1. Confirm everything legitimate passes

Do not advance until your reports show Mailchimp and every other real sender passing aligned DMARC. If anything legitimate is still failing, fix it first. Enforcement does not forgive misconfiguration; it acts on it.

2. Move to quarantine, optionally with sampling

Raise the policy to p=quarantine. Failing mail now goes to spam rather than the inbox, which is recoverable and a useful safety margin. If you are cautious, use the pct tag to apply the policy to a sample of mail first, for example:

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

This quarantines 25% of failing mail and leaves the rest at none, so a missed sender shows up as a manageable trickle of spam-foldered mail rather than your whole campaign vanishing. The behaviour and caveats of sampling are in the DMARC pct sampling tag. Ramp pct up to 100 as your reports stay clean.

3. Move to reject

When quarantine has run clean at pct=100, move to p=reject. Your domain is now protected: spoofed mail using your domain is refused outright, and your authenticated Mailchimp campaigns continue to flow because they pass aligned DMARC.

v=DMARC1; p=reject; rua=mailto:reports@yourbrand.com; fo=1

Keep reporting on. Reaching reject is not the end; you keep watching the reports because new tools get added, DNS records get edited, and a key rotation or a provider change can quietly break alignment. Whether enforcement is genuinely safe for a sender like you is addressed head-on in will enforcing DMARC break my email.

A few Mailchimp-specific gotchas

• Re-check after Mailchimp changes its records. Occasionally a provider updates its authentication setup or rotates keys. If campaigns suddenly start failing DMARC in your reports, re-run domain authentication in Mailchimp and confirm the published DNS records still match. Key rotation as a general failure mode is covered in DKIM key rotation.
• Beware the forwarding artefacts in your reports. Some DMARC failures in your reports are not Mailchimp's fault and not spoofing; they are subscribers whose mail is auto-forwarded, which breaks SPF and sometimes DKIM in transit. Do not mistake these for a Mailchimp problem. The mechanism is in the DMARC forwarding problem.
• Do not authenticate Mailchimp and then forget your transactional mail. If you also send order confirmations or password resets from a different platform on the same domain, those count under the same DMARC policy. Authenticate them too, or they break at enforcement.
• One DMARC record, one SPF record. Publishing two of either is an error that breaks the whole mechanism. If you already had a DMARC or SPF record before adding Mailchimp, edit the existing one rather than adding a second.

The short version

For Mailchimp, DMARC compliance comes down to a handful of moves done in the right order. Authenticate your domain inside Mailchimp so your campaigns are DKIM-signed under your own domain and align, which is what carries your DMARC. Do not try to brute-force SPF by piling on includes; DKIM alignment is enough and SPF has a ten-lookup ceiling you can easily breach. Publish DMARC at p=none with reporting, use the aggregate reports to confirm Mailchimp and every other sender is aligned, then stage the policy through quarantine (optionally sampled with pct) to reject. Run that in parallel with real list hygiene, confirmed opt-in, prompt bounce and unsubscribe handling, suppression of dead contacts, so your spam-complaint rate stays under the bulk-sender thresholds and your mail keeps reaching the inbox. Do all of that and you satisfy the Gmail, Yahoo, and Microsoft rules, you protect your domain from being spoofed, and your newsletters keep landing where they should.

If assembling this by hand, reading the XML reports, and timing each policy step is more than you want to take on, that is precisely what a done-for-you hosted DMARC service handles: the staged rollout from none to reject, the source classification that tells Mailchimp from spoofing, and the monitoring that catches a broken alignment before it costs you a campaign. Either way, start by running your domain through the free DMARC checker to see exactly where you stand right now, and read the bulk-sender requirements to confirm what the mailbox providers expect of you.