DMARC's p=none policy does nothing useful — here's what to do instead

DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM together and tells receiving mail servers what to do when authentication fails. It has three enforcement policies:

• p=none — collect reports, do nothing about failures
• p=quarantine — deliver failing messages to the spam folder
• p=reject — refuse to deliver failing messages at all

The vast majority of organisations that have a DMARC record are running p=none. This is correct when you first set up DMARC — you need the reports before you can safely enforce. But many organisations set it up and never progress. A DMARC record at p=none with no plan to move to enforcement is not a security control. It’s a reporting subscription.

What the reports actually tell you

When you set a rua= address in your DMARC record, receiving providers send aggregate reports to that address. Each report shows, for a given source IP sending as your domain:

• How many messages were sent
• Whether SPF passed or failed
• Whether DKIM passed or failed
• Whether DMARC alignment passed (the authenticated domain must match your From address domain)

Reading these reports shows you where authentication is failing before you enforce anything. Common findings:

• A cloud service sending as your domain without DKIM configured
• Marketing emails with a From address at your domain but signed by the ESP’s domain
• An old server nobody remembered was still sending
• Phishing attempts using your domain’s exact address

When to move to enforcement

Before moving to p=quarantine or p=reject, you need:

1. All legitimate sending sources covered by SPF
2. DKIM configured and aligning on all legitimate sending sources
3. DMARC aggregate reports showing consistent >95% pass rates from all legitimate sources

Once you’re there, move to p=quarantine first and monitor for a week. If legitimate mail is passing and there’s no increase in complaints, move to p=reject.

Common alignment failures

The marketing email problem. Your marketing team sends from newsletter@yourdomain.com through an ESP. The ESP signs with DKIM using their domain, not yours. SPF passes because the ESP is in your SPF record, but DMARC alignment fails because the From domain doesn’t match the signing domain. Fix: configure DKIM for your domain on the ESP platform.

The subdomain problem. DMARC applies to the domain it’s published on. Subdomains need their own DMARC record or inherit via the sp= parameter. If sp= isn’t set, subdomains inherit the root domain policy — which may not be what you want.

The forwarded email problem. Forwarded mail commonly fails DMARC because the forwarding server changes the envelope sender (breaking SPF) and doesn’t re-sign with DKIM. This is expected behaviour — account for it in your analysis but don’t use it as a reason to delay enforcement.

A practical enforcement path

1. Publish v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
2. After two weeks of reports, identify all failing sources and fix authentication for each
3. Move to p=quarantine; pct=10 (applies to 10% of failing mail) — watch for legitimate mail landing in spam
4. Increase pct incrementally to 100
5. Move to p=reject once p=quarantine at 100% runs cleanly for two weeks

Check your current DMARC configuration →