Moving your DMARC policy from p=none to p=reject is how you turn a passive monitoring record into real protection against spoofing. The safe way to do it is one gated step at a time: stay at monitoring until your reports show every legitimate sending stream is authenticated and aligned, then ramp to quarantine, then to reject. Never advance because a calendar date arrived. Advance because your DMARC data says the next step will not block real mail.
Reads public DNS only. Nothing is stored unless you save the domain to an account.
The risk is not the reject policy itself. The risk is enforcing before you can see all of your traffic. A single forgotten stream (a billing system, a helpdesk, a marketing platform, a payroll vendor) will start failing the moment you enforce, and those messages get quarantined or rejected. This guide gives you exit criteria for each phase so you know exactly when it is safe to move.
The four phases and why gates matter
Enforcement is not a switch. It is four states, and each one has a job.
- Monitor (
p=none): you collect aggregate reports and discover every source sending as your domain. No mail is affected. - Quarantine ramp (
p=quarantinewith a risingpct): failing mail goes to spam for a growing slice of traffic. This is your controlled blast radius. - Full quarantine (
p=quarantine; pct=100): all failing mail is quarantined. Nothing legitimate should be failing by now. - Reject (
p=reject): failing mail is refused at the SMTP layer and never reaches the inbox or the spam folder.
The gate between each phase is the same principle stated two ways: 100 percent of your sending traffic is accounted for in reports, and every legitimate stream passes DMARC alignment. If you cannot prove both, you are not ready. Skipping the gate is how teams end up disabling DMARC in a panic after a board member's email bounces.
If the difference between the three policy values is still fuzzy, read DMARC policy: none vs quarantine vs reject first, then come back to the roadmap.
Phase 1: Monitor and inventory every stream
Publish a monitoring record and point the aggregate reports somewhere you can read them.
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1
Leave this running for at least two to four weeks. You need a full billing cycle and a full marketing cycle so that low-frequency senders (monthly invoices, quarterly newsletters) show up in the data. If you have never opened an aggregate report, our guide on how to read a DMARC aggregate report walks through the XML field by field.
Your job in this phase is to build a list of every IP and provider that sends as your domain, and to mark each one as legitimate or not. For each legitimate source, confirm whether it passes SPF alignment, DKIM alignment, or both.
Exit criteria for Phase 1:
- Every high-volume source in your reports is identified and labeled legitimate or unauthorized.
- Every legitimate stream passes DMARC on at least one mechanism (SPF-aligned or DKIM-aligned). DKIM is the one that matters most because it survives forwarding, so fix DKIM first. See fix DKIM alignment if a stream authenticates but does not align.
- The share of your total message volume that is both legitimate and passing is at or very near 100 percent.
Do not move on while a real stream is still failing. That failure will become a delivery outage the moment you enforce.
Phase 2: Quarantine with a pct ramp
Now you enforce on a small slice. The pct tag tells receivers what percentage of failing mail to apply the policy to. The rest gets the next-weaker treatment, so at quarantine the un-sampled portion is still delivered normally.
Start low and climb as the data stays clean:
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourdomain.com; fo=1
A sensible ramp is 25, then 50, then 100, holding several days to a week at each step. After every increase, pull your reports and confirm the failing volume is only unauthorized or spoofed sources, never your own systems. If a legitimate stream appears in the failing column, stop, drop back, fix the alignment, and only then continue. The full mechanics of the tag are covered in the DMARC pct tag explained.
Exit criteria for Phase 2:
pct=100underp=quarantinehas run clean for at least a week.- Reports show zero legitimate mail in the failing bucket across a full sending cycle.
- Any new source that appeared during the ramp has been investigated and resolved.
Phase 3: Handle subdomains with the sp tag
Before you reach reject, decide what happens to subdomains. The sp tag sets policy for subdomains independently of the organizational domain. If you omit sp, subdomains inherit the p value.
Attackers love unguarded subdomains because a domain with p=reject but no subdomain coverage still lets p=none behavior leak through on mail.yourdomain.com or invented names like no-reply.yourdomain.com. The cleanest posture is to enforce on subdomains too:
v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc@yourdomain.com
If a specific subdomain sends mail through a stream you have not fully validated, set sp=quarantine temporarily while the parent domain sits at reject, then tighten it once that subdomain's reports are clean. Do not hold the whole organizational domain back because one subdomain is behind.
Phase 4: Move to reject and hold the line
When full quarantine has been clean for a week and subdomains are covered, publish the reject policy:
v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@yourdomain.com; fo=1
At this point spoofed mail claiming to be your domain is refused before it lands anywhere. This is also the policy that satisfies the strictest reading of the Google and Yahoo sender requirements for bulk senders, and it is what actually stops direct-domain spoofing of your brand.
Enforcement is not the finish line. Keep reading aggregate reports, because new SaaS tools get added, vendors change sending IPs, and a stream that was aligned last quarter can silently break after a platform migration. If a legitimate source starts failing at reject, its mail is gone, not spam-foldered, so the feedback loop still matters.
A realistic timeline and the pre-advance checklist
A typical rollout for an organization with a handful of sending platforms:
- Weeks 1 to 4:
p=none, inventory every stream, fix SPF and DKIM alignment on each. - Weeks 5 to 7:
p=quarantinerampingpct25, 50, 100. - Week 8: full quarantine holds clean; add
spcoverage. - Week 9 onward:
p=reject, then ongoing report review.
Complex environments with many vendors take longer, and that is fine. The timeline serves the gates, not the other way around.
Run this checklist against your own reports before advancing any phase:
- Have I seen a full billing and marketing cycle of data at the current policy?
- Is 100 percent of my legitimate volume passing DMARC on SPF or DKIM alignment?
- Is every source in the failing bucket confirmed unauthorized, not one of my own systems?
- Have I accounted for low-frequency senders (monthly, quarterly)?
- Are subdomains covered by an
spvalue I have chosen deliberately? - Do I have a rollback plan if a legitimate stream appears after I advance?
If every answer is yes, take the next step. If any answer is no, hold, fix, and re-read the reports.
Frequently asked questions
How long should I stay at p=none before enforcing?
Long enough to see every sending stream at least once, which usually means two to four weeks so that monthly and quarterly senders appear in your aggregate reports. Time is not the real gate. The gate is that your reports show 100 percent of legitimate traffic passing DMARC alignment. If you reach that in three weeks, move. If a stream is still failing at six weeks, stay.
Can I skip quarantine and go straight from none to reject?
You can, but you should not unless your traffic is very simple and fully aligned in the report data. Quarantine with a pct ramp is your safety valve: it limits how much mail is affected while you confirm nothing legitimate breaks. Reject has no soft landing, so a missed stream becomes lost mail rather than spam-foldered mail.
What does the pct tag actually do during the ramp?
pct sets the percentage of failing messages a receiver applies your policy to. At p=quarantine; pct=25, roughly a quarter of failing mail is quarantined and the rest is delivered as if the policy were weaker. It lets you enforce on a small, growing slice so you can watch your reports for collateral damage before committing to the full population.
Do I need the sp tag if I already set p=reject?
If you omit sp, subdomains inherit your p policy, so p=reject alone does cover them. The reason to set sp explicitly is control: you may want the organizational domain at reject while a subdomain that sends through a not-yet-validated platform sits at sp=quarantine. Setting it deliberately also closes the gap attackers exploit by spoofing invented subdomains.