DMARC works by telling receiving mail servers what to do with messages that fail SPF and DKIM authentication. The tag that controls this is p (policy) on the DMARC TXT record. It can take three values:
p=none— observation mode. Tell receivers about failures (via reports) but don't take action.p=quarantine— soft enforcement. Move failing messages to spam.p=reject— hard enforcement. Reject failing messages outright at the SMTP layer.
The policy you publish is also influenced by the pct tag (percentage of failing mail to apply the policy to) and the sp tag (separate policy for subdomains). Used together, these let you roll out enforcement gradually without ever risking legitimate mail.
This guide is the timeline we use for client DMARC rollouts. It's deliberately slow — typically 8–16 weeks from start to p=reject — and that's the point.
Stage 1: Publish p=none
Before doing anything else, publish the simplest possible DMARC record:
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:[email protected]"This tells receivers: "I have DMARC. Don't act on failures yet, but please send me aggregate reports about what's passing and what's failing." Publishing p=none changes nothing about the user-facing behaviour of your email — its purpose is purely to start the flow of reports back to you.
Set up a mailbox or a DMARC reporting service to consume the daily reports. DMARC Dashboard can verify your record and parse the reports for you.
Wait at least 2 weeks at p=none before doing anything else. You need that time to see all the systems sending mail on your domain, including ones nobody remembers about (the old ATS that's still notifying about applicants from 2019, the marketing platform someone signed up for, etc.).
Stage 2: Audit Your Senders
From the reports, you'll get a list of every IP that sent mail claiming to be from your domain. Some will be legitimate (your transactional provider, your CRM, your team's Gmail). Others will be illegitimate (spoofers, phishing, expired test accounts). And some will be legitimate but unauthenticated — systems sending real mail without proper SPF/DKIM setup, which DMARC will eventually reject.
Your job at this stage:
- For each legitimate sender, confirm it's properly authenticated (SPF includes its IP or DKIM is signing with your selector).
- For unauthenticated legitimate senders, get them authenticated. This is the slowest step and the one that determines how long the rollout takes.
- For obviously illegitimate senders, ignore — DMARC will reject them once you turn enforcement on.
Stay at p=none until you can answer: "is every legitimate sender on my domain authenticating successfully?" If yes, move to Stage 3. If no, fix the unauthenticated senders first.
Stage 3: p=quarantine with pct=10
Time to start enforcing — gently. Update the record to:
v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]This says: "for 10% of messages that fail DMARC, move them to spam. The other 90% keep treating as none." The pct tag is your safety valve: even if your audit missed a legitimate sender, only 10% of their mail goes to spam — the rest reaches the inbox.
Run for at least 1–2 weeks. Watch the reports. If complaints surface ("our finance team's invoices are going to spam!"), investigate, fix the auth, then continue. If reports are clean, increase pct in steps:
pct=10 → 25 → 50 → 75 → 100Each step gets a week or two. The goal is to reach p=quarantine; pct=100 with no complaints — that means every failing message is going to spam, but no legitimate sender is being affected.
Stage 4: p=reject
Once p=quarantine; pct=100 has been stable for at least 2 weeks with no complaints and no unexpected fails in the reports, it's safe to upgrade:
v=DMARC1; p=reject; rua=mailto:[email protected]The behaviour change is small — quarantine sent failing messages to spam; reject bounces them at SMTP. From a spammer's perspective, both are useless to them. From a recipient's perspective, reject is preferable because spam folders still get reviewed, while rejected messages disappear entirely.
Most domains never reach p=reject because they're nervous about it. The progressive rollout above is exactly designed to remove that nervousness — by the time you hit p=reject, you've already had every legitimate sender pass DMARC for weeks at p=quarantine. Nothing changes for them at p=reject except a slightly cleaner outcome for spoofed mail.
The sp Tag for Subdomains
By default, your DMARC policy applies to the apex domain only (example.com). Subdomains inherit the policy unless overridden. The sp tag lets you set a different policy for subdomains — typically stricter than the apex.
v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]Why publish a separate sp? Because attackers who can't spoof example.com directly often try lookalike subdomains: support.example.com, billing.example.com. If you don't actually send mail from those subdomains, sp=reject ensures any mail claiming to be from them fails DMARC and is rejected.
If you do send legitimate mail from subdomains (e.g. a transactional sender on mail.example.com), each subdomain needs its own DMARC record with its own policy progression. Don't apply sp=reject until every subdomain's mail flow is fully authenticated.
The fo Tag for Failure Reports
Aggregate reports (RUA) tell you what failed at a domain level — good for trends but bad for diagnosing specific failures. Failure reports (RUF) provide per-message detail, but most providers don't send them by default.
fo controls when failure reports are generated:
fo=0(default) — generate report only if both SPF and DKIM fail.fo=1— generate if either SPF or DKIM fails.fo=d— generate only on DKIM failure.fo=s— generate only on SPF failure.
Add fo=1; ruf=mailto:[email protected] during the early stages of rollout if you want per-message visibility. Most domains don't need this; aggregate reports are usually enough.
Common Pitfalls
Skipping p=none
The biggest mistake. Going straight to p=quarantine or p=reject without first auditing your senders means any unauthenticated legitimate mail starts disappearing immediately. Always start at p=none.
Not setting up reporting
If you don't have rua= configured to a mailbox you're actually monitoring, DMARC is invisible to you. You won't know what's failing or why. Get the reports flowing first, then progress.
Reading reports manually
Aggregate reports are XML, often delivered as base64-encoded zip attachments, multiple times per day from dozens of receivers. Parsing them manually is impossible at any meaningful scale. Use a DMARC reporting tool — DMARC Dashboard for spot checks, or a paid tool like dmarcian or EasyDMARC for ongoing monitoring.
Forgetting subdomains
The first time you see DMARC failures from marketing.example.com after months of clean reports for the apex, it's because a new system started sending and the subdomain doesn't have its own SPF/DKIM. Catching this requires reports that group by subdomain, not just apex.
Going backward in panic
Inevitably, someone hits p=quarantine, gets a complaint, panics, and reverts to p=none. Don't. Fix the underlying auth problem and continue the rollout. Going backward signals a lack of resolve and means the project never finishes.
Realistic Timeline
For a typical small business (one or two sending platforms, no exotic setup):
- Week 0–1: publish
p=none, set up reporting. - Week 2–3: audit senders, get unauthenticated ones fixed.
- Week 4:
p=quarantine; pct=10. - Week 5:
pct=25. - Week 6:
pct=50. - Week 7:
pct=100. - Week 8–9: monitor, then
p=reject. - Week 10+: maintenance — annual sender audits, key rotation, watching reports for new offenders.
For a larger organisation with many sending platforms or complex subdomain setups, double or triple the timeline. The early stages can take months — and that's fine. The protection at p=reject is the goal; you have the rest of your business's lifetime to maintain it once you're there.