You followed Mailchimp's own documentation. Your domain is still exposed.

Mailchimp's official setup guide states that v=DMARC1; p=none satisfies the minimum DMARC requirement.[1] Thousands of businesses added that record, saw the green checkmark in their DNS tool, and moved on — believing the job was done.

They completed Mailchimp's requirement. They didn't complete DMARC.

What Is DMARC?

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS policy that tells inbox providers what to do with email that fails SPF or DKIM authentication. It has three enforcement modes: p=none (deliver and report), p=quarantine (route to spam), and p=reject (block delivery). DMARC also adds an alignment check — verifying that the domain authenticated by SPF or DKIM matches the domain visible to the recipient in the From: header. Google and Yahoo made DMARC mandatory for bulk senders in February 2024. Microsoft followed in May 2025, issuing hard rejections for non-compliant mail.

What p=none Actually Does

p=none is not a protection policy. It's an observation mode.

The three DMARC policy values instruct inbox providers differently. p=none says: deliver the mail regardless of whether authentication passes or fails, and send a report. p=quarantine says: route failing mail to the spam folder. p=reject says: refuse delivery entirely.[6]

At p=none, someone can send email spoofing your domain today. Gmail, Outlook, and Yahoo will accept those emails without restriction. The spoofed mail lands in your customers' inboxes. You receive a report. Nothing is blocked.

Policy What inbox providers do with failing mail Spoofing protection Status
p=none Deliver normally, send aggregate report None Observation only
p=quarantine Route to spam / junk folder Partial Enforcement — graduated
p=reject Block delivery entirely (550 error) Full Enforcement — complete

The Problem Mailchimp's Docs Don't Address

Mailchimp requires a DMARC record to reduce the chance that mail sent through their servers gets rejected by recipient providers. Their requirement protects their infrastructure and sending reputation.

It doesn't protect your domain from spoofing. It doesn't protect your customers from phishing campaigns using your brand name. These are two different goals, and Mailchimp's minimum only addresses one of them.

p=none is the correct starting point. Every serious DMARC implementation begins there — to observe what's sending from your domain before enforcing anything. The mistake is treating it as a destination.

The Alignment Failure Most Setups Miss

DMARC doesn't just check that SPF and DKIM pass. It checks that they align — that the domain authenticated by SPF or DKIM matches the domain in the visible From: header the recipient sees.[2]

With Mailchimp, you add two CNAME records pointing to Mailchimp's DKIM infrastructure. When correctly configured, Mailchimp signs outgoing email with a d= value referencing your domain. DKIM passes and alignment passes.

If those CNAMEs aren't propagated or are misconfigured, a different failure pattern appears: DKIM passes cryptographically but DMARC alignment fails because the signing domain doesn't match your From: domain.[3] At p=none, this failure is completely silent. The email still delivers. You won't catch it unless you're reading aggregate reports — which you can't, because the minimum record has no reporting address.

The Subdomain Gap

A DMARC record at _dmarc.yourdomain.com applies to your root domain. It does not automatically protect subdomains.[4]

If you send Mailchimp campaigns from news.yourdomain.com or mail.yourdomain.com, those subdomains need either their own DMARC record or an sp= tag on the root record that explicitly extends policy to subdomains.

Most setups skip this entirely. A domain with p=reject on the root but no subdomain policy can still be spoofed from invoice.yourdomain.com without any restriction.

The rua Tag: You're Flying Blind Without It

The bare minimum Mailchimp requires — v=DMARC1; p=none — has no rua= tag.

rua is the aggregate report address. Without it, inbox providers process your DMARC record but send pass/fail data nowhere. You receive no reports. You can't identify which legitimate senders are failing authentication. You can't find sources spoofing your domain. You can't build the data you need to safely move to a stricter policy.

The correct starting record is:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
# Replace dmarc-reports@yourdomain.com with a dedicated inbox
# or your DMARC report parser address (Postmark DMARC, Dmarcian, etc.)

Read those reports for two to four weeks before changing the policy. Every legitimate sending source needs to show as passing before enforcement begins.

The Upgrade Path

The sequence that works, and the timeline that's realistic for a Mailchimp-primary setup:

Weeks 1–4: Publish p=none; rua=mailto:.... Identify every source sending from your domain in the reports. Verify Mailchimp's CNAME-based DKIM is aligned. Check for any subdomains sending email.

Week 5: Move to p=quarantine; pct=25. This applies the quarantine policy to 25% of failing mail only — a controlled test. Monitor for any legitimate mail suddenly going to spam.

Week 6–7: Increase pct to 50, then 100. As reports confirm legitimate mail passes consistently, tighten the percentage.

Week 8+: Move to p=reject once p=quarantine; pct=100 is stable and reports show only unauthorized senders failing.

Domains with multiple sending sources — CRM, transactional email, helpdesk — take longer because each source needs authentication verified and aligned before tightening. Rushing to p=reject before all sources are confirmed will cause legitimate mail to bounce.

Why This Matters More Now

Google and Yahoo required SPF, DKIM, and DMARC for bulk senders from February 2024. Microsoft followed in May 2025, issuing hard rejections for non-compliant email with error code 550 5.7.515.[2] These are delivery failures, not spam folder placements.

p=none satisfies the presence requirement. It doesn't satisfy the enforcement expectation these providers are building toward. The direction of travel in inbox provider policy is consistently toward stricter authentication. Domains sitting at p=none indefinitely are behind that curve.

The record existing is not the same as the protection working.

Key Takeaways

  • Mailchimp's minimum DMARC requirement is p=none — observation mode, not enforcement.
  • p=none does not block spoofing or phishing using your domain.
  • The bare minimum record has no rua= tag — you receive zero aggregate data.
  • DMARC alignment failure with Mailchimp's CNAMEs is silent at p=none.
  • Subdomains are unprotected unless you add an sp= tag or separate DMARC records.
  • Microsoft began hard-rejecting non-compliant mail in May 2025 (550 5.7.515).
  • The upgrade from p=none to p=reject takes 6–8 weeks done correctly.

Frequently Asked Questions

p=none is a monitoring-only DMARC policy. It instructs inbox providers to deliver all email regardless of whether authentication passes or fails, and to send aggregate reports to the address in the rua= tag. It provides no enforcement — spoofed or unauthenticated mail still reaches recipients. It is the correct starting point for observing your email environment, but not a protection policy.
Yes. Mailchimp requires a DMARC record with at minimum p=none on your sending domain. However, their requirement protects their sending infrastructure, not your domain from spoofing. Satisfying Mailchimp's minimum does not prevent phishing or impersonation using your brand. A complete DMARC implementation requires progressing from p=none to p=quarantine or p=reject after confirming all legitimate sending sources pass authentication.
DMARC alignment checks whether the domain authenticated by SPF or DKIM matches the domain in the visible From: header. With Mailchimp, DKIM alignment requires that the CNAME records Mailchimp provides are correctly configured so outgoing mail is signed with your domain. If the CNAMEs are misconfigured or not yet propagated, DKIM passes cryptographically but DMARC alignment fails. At p=none, this failure is silent — mail still delivers and no errors appear anywhere.
The rua tag specifies an email address where inbox providers send aggregate DMARC reports. Without it, providers process your DMARC record but send pass/fail data nowhere. You receive no reports, cannot identify authentication failures or spoofing attempts, and cannot build the data needed to move to a stricter policy. The minimum useful record is v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com.
Most domains with a clean Mailchimp-only setup can complete the upgrade in six to eight weeks. The process involves monitoring at p=none with rua= reporting for two to four weeks, verifying all legitimate senders pass DMARC alignment, then moving to p=quarantine; pct=25 and incrementally increasing enforcement. Domains with multiple sending sources — CRM, transactional email, helpdesk — take longer because each source needs authentication verified before tightening policy.

Sources

  1. Mailchimp Developer — Authentication and Delivery Documentation — "We only require that you have a DMARC policy; it can be set with p=none"
  2. Red Sift OnDMARC — 6 Most Common DKIM and DMARC Failures (2026) — Microsoft 550 5.7.515 rejection, alignment failure patterns
  3. DMARC Report — Why DMARC Fails: Complete Troubleshooting Guide (2026) — alignment vs authentication distinction
  4. Valimail — DMARC Fail: Why It Happens and How to Fix It — subdomain misalignment gap
  5. Prospeo — DMARC Alignment Explained: 2026 Guide — SPF and DKIM pass but DMARC fails
  6. EmailWarmup — DMARC Fail — p=none policy behavior and consequences explained