If you only remember one thing: the policy tag (p=) is the last thing you change, not the first. Enforcement is trivial to publish — it’s a one-word edit. The real work happens at p=none, where you spend a few weeks reading reports and aligning senders so that when you do turn on enforcement, everything legitimate already passes. This guide walks the four stages in order, with the exact record to publish at each one.
Why staged, and why never jump straight to reject
DMARC tells receiving servers what to do with mail claiming to be from your domain that fails both SPF and DKIM alignment. At p=reject that mail is bounced outright. The danger is that most organisations send from more services than they realise — a CRM, a helpdesk, an invoicing tool, a recruiting platform, a marketing suite — and several of those are almost certainly not aligned yet. Publish p=reject before fixing them and their mail simply stops arriving, silently, with no easy way to tell which sender broke. Staging removes that risk by making every legitimate sender visible and passing before anything gets blocked.
Stage 1 — p=none: turn on reporting, change nothing
Your first record enforces nothing. It only asks receivers to send you daily aggregate (rua) reports so you can see who is sending as your domain. Publish this and leave delivery completely untouched:
_dmarc.example.com TXT
"v=DMARC1; p=none; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; fo=1; adkim=r; aspf=r"The tags doing the work here:
p=none— monitor only. No mail is quarantined or rejected; you are purely collecting data.rua=— where the daily aggregate XML reports go. This is the single most important tag in the whole rollout; without it you are blind.adkim=r/aspf=r— relaxed alignment, the sane default. It lets subdomains align with the organisational domain.fo=1/ruf=— optional forensic/failure reporting; helpful early on, though many receivers don’t sendruf.
Leave this running for two to four weeks. You need enough time to capture the full monthly cycle of sending — the invoice run, the newsletter, the quarterly campaign — not just a quiet Tuesday.
Stage 2 — read the aggregate reports and inventory every sender
The aggregate reports are XML, one file per receiver per day, and they are unreadable by hand at any volume. Each report lists the source IPs sending as your domain and whether SPF and DKIM aligned. Your job is to build a complete inventory: every legitimate service, plus any spoofing you spot. Feed the reports into DMARC monitoring so they’re parsed and grouped by sender rather than left as raw XML, and see how to read DMARC aggregate reports for a field-by-field walkthrough.
For each source in the reports, decide: is this a legitimate sender I need to keep, or is it spoofing I can ignore? By the end of this stage you should have a list of every real service sending as you, and for each one a clear yes/no on whether it currently passes DMARC alignment.
Stage 3 — fix alignment for every legitimate sender
This is the actual work of the rollout, and where most of the calendar time goes. A sender passes DMARC when at least one of SPF or DKIM both passes and aligns with your visible From: domain. For each legitimate service still failing:
- Align DKIM — configure the platform to DKIM-sign as your domain (the signature’s
d=must match your From). This is the more robust fix because aligned DKIM also survives forwarding. The provider gives you a DNS record to publish. - Align SPF — set a custom Return-Path (bounce domain) on your domain so the envelope-from aligns with From, usually a CNAME the provider supplies.
You only need one of the two to align, but aligning both is more resilient. Keep watching the reports until every legitimate sender shows DMARC passing. Do not advance until that’s true — this stage is the whole safety mechanism. Validate individual records as you go with the DMARC Checker.
Stage 4 — ramp to quarantine, then reject
Once the reports are clean, start enforcing — but gradually, using the pct tag to apply the policy to only a fraction of failing mail at first. Move to quarantine at 25%:
_dmarc.example.com TXT
"v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com; adkim=r; aspf=r"With pct=25, a quarter of mail that fails DMARC is sent to spam; the rest is still delivered. Watch the reports for a week or so for anything unexpectedly failing. If it stays quiet, raise the percentage — a common ramp is 25% → 50% → 100% — until you reach full quarantine:
_dmarc.example.com TXT
"v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@example.com; adkim=r; aspf=r"Let full quarantine settle for another week or two. If nothing legitimate is landing in spam, graduate to enforcement:
_dmarc.example.com TXT
"v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=r; aspf=r"At p=reject, mail failing DMARC is bounced at the SMTP level. This is the policy Gmail, Yahoo and Microsoft reward, and the prerequisite for a BIMI logo. Note that pct has no meaning once you’re at reject with full coverage — it’s a ramp tool for the transition, not a permanent setting.
Don’t forget subdomains: the sp= tag
DMARC’s p= applies to the organisational domain; subdomains inherit it unless you set an explicit subdomain policy with sp=. If you send from subdomains (news.example.com, mail.example.com) that aren’t fully aligned yet, you can hold them at a softer policy while the top-level domain enforces:
_dmarc.example.com TXT
"v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@example.com"Here the parent domain rejects, but subdomains only quarantine — useful as a transitional safety net. Once every subdomain sender is aligned, drop sp= so subdomains inherit the full reject policy. Be aware that an aggressive parent policy with no sp= applies reject to all subdomains, including ones you may have forgotten send mail.
How long the whole thing takes
A realistic timeline: two to four weeks at p=none to gather a full sending cycle, one to several weeks fixing alignment (this varies most, depending on how many services you send from), then two to four weeks ramping through quarantine to reject. For a simple setup you might reach enforcement in a month; for a large organisation with many senders, two to three months is normal. Rushing the alignment stage is the only way this goes wrong.
Verify and keep monitoring
Confirm your published policy at each stage with the DMARC Checker, and build clean records with the DMARC Generator. Crucially, don’t stop reading reports once you reach reject — keep DMARC monitoring running so that when a new service is added, or an existing one breaks, it surfaces in a report instead of as a wave of missing mail. The authoritative reference is RFC 7489, and each mailbox provider’s guidance — Google’s DMARC documentation and Yahoo’s best practices.