DMARC only protects your domain at p=quarantine or p=reject. But flipping straight to reject is how organisations discover, loudly, that their invoicing system sends through a platform nobody documented. The safe path is staged: publish p=none to see everything, build a complete inventory of legitimate senders from the aggregate reports, fix each one until it authenticates and aligns, and only then ramp enforcement. Done properly it takes weeks — mostly spent waiting for data, not working.
You need a DMARC record with a working rua= address before any of this is possible. If reports are not arriving yet, set that up first with How to Set Up DMARC Aggregate Reporting — the entire rollout is driven by that data.
The Shape of the Rollout
| Stage | Record | Typical duration | Gate to advance |
|---|---|---|---|
| 1. Monitor | p=none | 2–4 weeks | Every source identified |
| 2. Fix alignment | p=none | 2–6 weeks | All legitimate mail aligned |
| 3. Partial quarantine | p=quarantine; pct=25 | 1–2 weeks | No new failures |
| 4. Full quarantine | p=quarantine | 2–4 weeks | Aligned-pass rate steady |
| 5. Partial reject | p=reject; pct=25 | 1–2 weeks | No complaints, no new sources |
| 6. Full reject | p=reject | Ongoing | — |
Two to three months end to end is normal for an organisation of any size. Rushing is the only way to get this badly wrong.
Stage 1: Monitor with p=none
Publish the most permissive possible policy alongside reporting. This changes nothing about delivery and gives you complete visibility.
v=DMARC1; p=none; rua=mailto:dmarc@example.comThen wait. Collect at least two weeks — four is better, because monthly processes exist. The billing run that fires on the 28th will not appear in a seven-day sample, and finding it after you have enforced is an unpleasant way to learn it existed.
p=none indefinitely is publishing a DMARC record that stops precisely zero spoofed mail. Plenty of domains stall here and believe they are protected.Stage 2: Build the Sender Inventory
This is the real work of a DMARC rollout, and it is mostly organisational rather than technical. Every source that appears in reports needs a name and an owner.
# Rank sources by volume across a batch of reports
grep -ohP '(?<=<source_ip>)[^<]+' *.xml | sort | uniq -c | sort -rn | head -30
# Identify an unfamiliar IP
dig +short -x 203.0.113.9
whois 203.0.113.9 | grep -iE 'orgname|netname|descr'Expect to find more than you think. A typical inventory turns up:
- Your primary mail platform — Google Workspace, Microsoft 365, or your own servers.
- Marketing tools that someone in another department signed up for.
- Transactional senders — invoicing, ticketing, CI notifications, monitoring alerts.
- CRM and support desks sending as your domain.
- Forwarded mail, which looks like unknown IPs failing SPF but is legitimate.
- Actual spoofing, usually low-volume and scattered across many IPs.
Record each one: what it is, who owns it, and whether it currently produces an aligned pass. The DMARC Report Analyzer does the grouping and alignment columns for you; a spreadsheet is enough to track ownership.
Stage 3: Fix Alignment, Source by Source
For each legitimate sender, at least one of SPF or DKIM must produce an aligned pass. Not merely a pass — an aligned one. This distinction is the source of most rollout confusion, and it is worth reading DMARC Alignment Explained before starting.
Prefer fixing DKIM
Aligned DKIM survives forwarding; aligned SPF does not. For most platforms this means publishing their selector as CNAMEs under your own domain and enabling "sign as your domain" in their dashboard:
# Typical vendor DKIM delegation
s1._domainkey.example.com. IN CNAME s1.domainkey.uXXXX.vendor.example.
s2._domainkey.example.com. IN CNAME s2.domainkey.uXXXX.vendor.example.
# Verify the key resolves
dig +short TXT s1._domainkey.example.comThen fix SPF alignment
Enable a custom return path (variously called a custom bounce domain or dedicated sending domain) so the envelope sender moves onto a subdomain you own:
# Before — SPF passes for the vendor, does not align
Return-Path: <bounce-8842@mail.vendor.example>
# After — SPF passes for your subdomain, aligns under relaxed mode
Return-Path: <bounce-8842@em.example.com>Watch the SPF lookup limit
Every include: costs a DNS lookup, and exceeding ten produces PermError — which fails SPF entirely, taking aligned SPF with it.
dig +short TXT example.com | grep spf1
"v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net -all"Use the SPF Validator to count lookups, and remove senders you no longer use — the inventory from Stage 2 usually reveals several.
Stage 4: Ramp to Quarantine
When reports show every legitimate source producing an aligned pass, start enforcing — but on a fraction of traffic first.
# A quarter of failing mail goes to spam, the rest is untouched
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.comHold for a week or two and watch for new failures and user complaints. If it is quiet, ramp: pct=50, then pct=100, then remove the tag.
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.comQuarantine is a genuinely useful safety net: failing mail is recoverable from the spam folder, so a mistake at this stage is embarrassing rather than destructive. Spend real time here.
Handling subdomains
If subdomains have senders you have not yet inventoried, hold them at a looser policy while the main domain enforces:
# Enforce on the main domain, keep monitoring subdomains
v=DMARC1; p=quarantine; sp=none; rua=mailto:dmarc@example.com
# Non-existent subdomains cannot send legitimately — safe to reject immediately
v=DMARC1; p=quarantine; sp=none; np=reject; rua=mailto:dmarc@example.comsp=none is a transitional state, not a destination — attackers spoof subdomains precisely because they are often left unprotected.
Stage 5: Ramp to Reject
Same pattern, higher stakes. Rejected mail is gone — there is no spam folder to recover it from.
v=DMARC1; p=reject; pct=25; rua=mailto:dmarc@example.comNote that p=reject; pct=25 does not leave the other 75% untouched: the remainder falls back to quarantine, the next policy down. That is the desired behaviour here, but it surprises people who expect the sample to be the only enforced portion.
Ramp through pct=50 and pct=100 over a couple of weeks, then land on the target record:
v=DMARC1; p=reject; rua=mailto:dmarc@example.comStage 6: Stay There
Enforcement is not a finished state. Things that will eventually break a working p=reject domain:
- A team adopts a new SaaS tool that sends as your domain.
- A vendor rotates sending infrastructure without notice.
- A DKIM key is rolled and the DNS record is not updated.
- An SPF record drifts past the ten-lookup limit as includes are added.
- A domain or certificate expires and someone reconfigures things in a hurry.
Keep reading reports monthly. Each of these shows up as a new failing source days before anyone reports missing mail.
If Something Breaks
Roll back the policy, not the reporting. Dropping to p=none restores delivery within a TTL while you diagnose:
# Emergency rollback — keep reporting, stop enforcing
v=DMARC1; p=none; rua=mailto:dmarc@example.comKeeping DMARC TTLs low (300–3600 seconds) during a rollout makes rollback fast. Raise them once you are stable. Never fix a bounce by weakening alignment or adding a broad include: to SPF — that trades a delivery problem for a security hole.
Frequently Asked Questions
How long should a DMARC rollout take?
Two to three months for most organisations. The elapsed time is dominated by waiting for representative report data — you need to see monthly processes at least once — rather than by the configuration work itself.
Can I go straight to p=reject?
Only if you are certain your domain sends no mail at all, such as a parked domain. For any sending domain, jumping to reject without a sender inventory means silently deleting legitimate mail, and you will find out from an angry customer rather than from a report.
Do I have to use the pct tag?
It is not required, but it is a cheap way to limit blast radius at each step. Note that pct is deprecated in the draft revision of the DMARC specification, so use it as a rollout aid and remove it once you reach full enforcement rather than leaving it in permanently.
What if I cannot fix a legitimate sender?
Options, in order of preference: switch to a vendor that supports proper DKIM delegation; move that mail to a dedicated subdomain with its own looser DMARC record; or change the From: address to a domain that sender can authenticate for. Weakening the main domain's policy to accommodate one system defeats the purpose.
Will DMARC enforcement hurt my deliverability?
Properly rolled out, it improves it. Aligned authentication is a positive reputation signal, and both Google and Yahoo now require DMARC for bulk senders. Badly rolled out, it destroys deliverability for whichever senders you missed — which is why the inventory stage matters.
Should subdomains get their own policy?
They inherit p by default, which is usually what you want. Use sp= only as a transitional loosening while you inventory subdomain senders, and add np=reject to close off non-existent subdomains, which can never send legitimately.