DMARC record guide: p=none, quarantine, reject and reports

A DMARC record tells receiving mail servers what to do when a message claiming to be from your domain fails authentication, and asks them to send you reports about it. It sits on top of SPF and DKIM: those two prove a server was authorised, while DMARC adds the missing piece — checking that the authorised domain actually matches the visible From address, and giving you a policy lever and a feedback loop. Get the DMARC record right and you turn two technical checks into an enforceable anti-spoofing policy. Get it wrong, or jump to enforcement too early, and you junk your own legitimate mail.

What a DMARC record looks like

DMARC lives in a TXT record at a fixed location: _dmarc.<your-domain>. A typical record reads:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=s; aspf=s; pct=100"

The tags worth knowing:

The thing DMARC actually checks is alignment. SPF passing isn't enough; the domain SPF validated must align with the From domain. Likewise the DKIM d= domain must align with From. A message passes DMARC if either SPF or DKIM passes and aligns. This is why DKIM matters for forwarded mail — SPF alignment usually breaks on forwarding, DKIM survives it.

p=none vs quarantine vs reject

The policy tag is the whole game, and it is the one people misjudge:

• p=none — Monitoring only. Receivers take no action on failures but still send you reports. This is where every deployment starts. It is not protection; a domain sitting on p=none forever is unprotected and spoofable, it just has good telemetry.
• p=quarantine — Failing mail is delivered to junk/spam. A reversible, lower-risk enforcement step. Pair it with pct= to ramp gradually.
• p=reject — Failing mail is rejected outright at SMTP time. This is the goal: full protection against direct From-spoofing of your domain. It is also unforgiving, so you only get here once reports show your legitimate sources all pass.

A safe rollout strategy

The point of the staged approach is to reach p=reject without ever bouncing real mail. A sane sequence:

1. Publish p=none with rua=. Change nothing else. Collect reports for two to four weeks until you have a stable picture of every system sending as your domain.
2. Fix what the reports reveal. Bring every legitimate source into SPF and/or DKIM alignment — the forgotten CRM, the invoicing tool, the office printer relay. This step is the actual work; the policy tags are trivial by comparison.
3. Move to p=quarantine; pct=10, then raise pct over a few weeks (25, 50, 100) while watching reports for legitimate mail being caught.
4. Move to p=reject once quarantine at pct=100 is clean.
5. Set sp= deliberately. Unused subdomains should be locked down even while the apex is mid-rollout — sp=reject on a domain whose subdomains never send mail is a cheap win that closes a common spoofing vector.

Resist the urge to skip to p=reject on day one. The mail you break will be your own, and you won't find out until a customer says your invoice never arrived.

Reading aggregate reports

Aggregate (RUA) reports are XML files that receivers send daily, one per reporting source. Each summarises message counts grouped by sending IP, with the SPF and DKIM results and — crucially — the alignment outcome. Raw, they are unreadable; in practice you feed them to a parser or a dashboard. What you're hunting for:

• Legitimate sources that aren't aligned yet. High volume from a known IP that fails DMARC means a real system you haven't fixed. Do not move to enforcement until these are resolved.
• Unknown sources passing authentication. A SaaS tool someone signed up for without telling IT, now sending as your domain. Decide whether to keep it.
• Spoofing. Scattered low-volume sources failing both SPF and DKIM — these are the forgeries your policy is meant to block, and the reason to push on to p=reject.

A subtlety: reports tell you about mail that failed, aggregated after the fact. They do not tell you, in real time, that your own DMARC, SPF or DKIM records have changed or broken. A fat-fingered zone edit or a dropped record won't show up in an aggregate report until tomorrow's batch — by which point your mail may already be bouncing.

Keeping the record honest

DMARC is not set-and-forget. New sending tools appear, SPF includes drift past the lookup limit, DKIM selectors get tidied away during a DNS migration — and any of those can quietly turn p=reject from protection into an outage. Treat the record as monitored infrastructure: confirm _dmarc still resolves, the policy is what you intended, and the underlying SPF and DKIM still align. Our docs on email DNS security walk through how the pieces interact, and the broader security docs cover what DomainOps watches.

DomainOps monitors your DMARC, SPF and DKIM records continuously and alerts you the moment one changes or breaks — it does not send your mail or edit your zone, it watches your posture so a silent failure doesn't become a deliverability incident. For a one-off snapshot, run your domain through the free email auth audit; when you're ready for continuous coverage, start monitoring your domains.