DMARC: p=none, quarantine and reject explained
Publishing a DMARC record is not the same as protecting your domain - most sites stop at p=none and stay there indefinitely. Here is what each policy actually does and the ladder to get from monitoring to real enforcement.
What DMARC adds that SPF and DKIM cannot do alone
SPF checks the envelope-from and DKIM checks a cryptographic signature, but neither one, by itself, checks whether either of those matches the visible From address a person actually reads - and neither tells a receiving server what to do when a check fails. DMARC adds alignment (SPF or DKIM must pass AND match the visible From domain), a disposition policy (what to do with mail that fails alignment), and reporting (aggregate data on who is sending mail as your domain). It is the piece that turns two independent checks into an actual anti-spoofing policy.
p=none: monitoring mode, and the most common failure
p=none tells receivers to apply no special treatment to failing mail - it just asks for reporting. This is the correct starting point for every domain, because publishing quarantine or reject before you know what legitimate mail might fail can silently break real email. The failure mode is not starting at p=none - it is staying there forever. A domain sitting on p=none for years is publishing a DMARC record that provides visibility but zero actual protection against spoofing, while giving a false sense that "we have DMARC" checked off.
The rollout ladder: none, then quarantine with pct=, then reject
Start at p=none with rua reporting turned on and monitor for several weeks to identify every legitimate sending source - your main mail platform, marketing tools, helpdesk, invoicing software, anything sending as your domain. Once those are all authenticated and aligned, move to p=quarantine, and use pct= to ramp gradually (pct=10, then 25, then 100) rather than flipping the whole domain’s mail into spam folders at once. Only after quarantine has run cleanly should you move to p=reject, which tells receivers to refuse failing mail outright. Rushing this ladder is how legitimate invoices and newsletters end up in spam or bounced entirely.
Aggregate (rua) vs forensic (ruf) reports
rua reports are aggregate XML summaries, usually daily, showing which IPs sent mail as your domain, whether they passed SPF/DKIM/alignment, and what the receiver did with it - this is the data you actually use to build your list of legitimate senders and to monitor for abuse. ruf reports were designed to send full copies of individual failing messages for forensic analysis, but most major mailbox providers (Google and Microsoft included) no longer send them at all, citing privacy concerns, so a ruf= tag on most domains today collects nothing. Use aggregate reports plus a DMARC report analysis tool as the practical path - do not build a rollout plan around forensic reports arriving.
Subdomain policy with sp=
By default, DMARC policy applies to subdomains unless a separate sp= tag overrides it. This matters because attackers often spoof from a plausible-looking subdomain of a legitimate domain rather than the domain itself. If you have subdomains that never send mail, an explicit sp=reject (even while the main domain is still on p=quarantine or p=none) closes an easy spoofing path at effectively no risk to real mail flow.
How to read your own DMARC record and where to go from here
Run dig TXT _dmarc.yourdomain.com +short and look for v=DMARC1, the p= tag, and the rua= reporting address. If there is no record at all, you have zero DMARC protection regardless of how good your SPF and DKIM look. AuditHQ’s security suite checks DMARC presence, policy strength, and reporting configuration via live DNS lookups as part of its email authentication checks, and explains in plain English where you sit on the rollout ladder. The free scan samples this in about 60 seconds.
Frequently asked questions
Is p=none bad?
Not as a starting point - it is the correct first step for every domain, because it gives you visibility into your real mail flow before anything gets blocked. It only becomes a problem when a domain never moves past it, because p=none provides reporting but no actual enforcement against spoofing.
How long should I monitor before enforcing?
A few weeks of aggregate reports is usually enough to surface your regular senders, but watch for anything sent less frequently - annual invoicing runs or seasonal marketing campaigns - which can take longer to appear. Move to quarantine once you have identified and authenticated every legitimate source you can find, then ramp with pct= rather than jumping straight to full enforcement.
Do I need ruf?
Generally no in practice. Most major mailbox providers have stopped sending forensic reports, so a ruf= tag on most domains sits unused. Aggregate (rua) reports plus a report-analysis tool give you the data you actually need to run the rollout safely.
What happens if I skip straight to p=reject?
Any legitimate sending source you have not yet identified and authenticated - a helpdesk, an invoicing tool, a marketing platform - will have its mail rejected outright rather than merely flagged. This is why the ladder exists: quarantine with a gradual pct= ramp lets you catch these before they become hard bounces.