From p=none to p=reject.
The step-by-step DMARC rollout: how to advance your policy to enforcement without breaking a single legitimate email.
The record is easy. The rollout is the work.
Changing a DMARC policy is one line of DNS. Changing it without bouncing your own mail is the part that stalls most domains at p=none for years. This is the field manual for the second thing: why monitoring alone leaves you exposed is a separate question. Here we assume you already want to enforce, and walk the exact path there.
The rollout, stage by stage.
Six stages, each gated by what your reports show. You never advance on a guess.
Publish p=none and turn on reporting
Start with a record that asks receivers to report but take no action. Point rua= at a mailbox you can read. Nothing is blocked yet, but the aggregate reports that make every later step safe start flowing.
v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com; adkim=r; aspf=rReports arriving daily from your major mailbox providers.
Inventory every legitimate sender
The reports show every source sending as your domain: marketing platform, CRM, support desk, invoicing, the newsletter tool nobody remembers. Miss one and enforcement will block its mail. This is the stage that actually takes the time.
Every legitimate sender identified and accounted for.
Get SPF and DKIM aligned
Each sender has to authenticate and align with your domain. Mind the SPF ten-lookup limit; nest too many include: mechanisms and SPF fails for everyone. DMARCbis aligns SPF on the MAIL FROM domain only, so DKIM is the more durable pass to lean on. Sign everything you can.
Every sender passing SPF or DKIM, aligned to your domain, in the reports.
Advance to p=quarantine
Once the reports show legitimate mail aligned, move the policy up. Forged mail now lands in spam instead of the inbox. Want a provisional step first? DMARCbis replaces the old pct= percentage ramp with a binary t=y testing flag. Publish the stronger policy marked as testing, confirm the reports, then drop the flag.
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourcompany.com; adkim=r; aspf=rA week of reports with no aligned, legitimate mail failing.
Advance to p=reject
The destination. Receiving servers now refuse mail that fails authentication outright. Impersonation is stopped at the door, not filtered to spam. Set sp= and np= while you are here, so subdomains and invented names are covered too.
v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@yourcompany.comThe only failures left in the reports are illegitimate mail.
Hold it against drift
Enforcement is a state you maintain, not a finish line. A new vendor, an edited record, an expired DKIM key. Any of them can silently break alignment and start bouncing real mail. Someone has to keep reading the reports. Forever.
Reports still clean after every new sender or DNS change.
The tags that control it.
Six tags do the steering. For the full set of DMARCbis changes, see what RFC 9989 rewrote.
p=
The policy itself
none monitors, quarantine diverts, reject refuses. The entire rollout is moving this one value; everything else exists to make moving it safe.
sp=
Subdomain policy
Without it, subdomains inherit p=. Set sp=reject so a quiet, forgotten subdomain can't be spoofed while your attention is on the apex.
np=
Non-existent subdomains
New in DMARCbis. np=reject refuses mail from invented subdomains, a favourite spoofing trick, with no effect on real mail.
adkim / aspf
Alignment mode
r (relaxed) lets subdomains align to the parent; s (strict) demands an exact match. Start relaxed and tighten only when you know you need to.
rua=
The reporting address
Where aggregate reports are sent. This is the feedback loop that makes every advance safe. Never move a policy up without it.
t=
The testing flag
DMARCbis's replacement for pct=. t=y marks a policy provisional; dropping it makes enforcement live. Percentage ramps are gone.
How long it takes.
Days for a clean domain with a handful of well-behaved senders. Weeks for a typical business with a scattered sender footprint. Months for a sprawling one that has to track down every tool that ever sent on its behalf.
Across the domains we measure, the median sits under six months, and almost all of that is the inventory-and-alignment work, not the policy change. The DNS edit takes seconds. Knowing it is safe to make is the job.
Where rollouts go wrong.
Enforcement breaks mail in a handful of predictable ways. Every one of them is avoidable.
Enforcing before the inventory is done
The fastest way to block real mail is to reach reject with a sender you never accounted for. Finish the inventory first.
Blowing the SPF ten-lookup limit
Every include: costs a DNS lookup. Past ten, SPF returns permerror and fails for everyone. Flatten or consolidate before it bites.
Leaning on SPF alone
With DMARCbis aligning SPF on MAIL FROM only, forwarded mail breaks SPF. DKIM is what carries the pass through a forward, so sign everything.
Jumping straight to reject
Skip quarantine and you discover your misconfigurations by bouncing customer mail. Step through it and watch the reports.
Forgetting subdomains
An unprotected subdomain is a spoofable subdomain. sp= and np= close the doors you're not looking at.
Going live and looking away
A policy at reject with nobody reading the reports is one expired key away from bouncing your own mail. Enforcement has to be watched.
This is the playbook. Authex runs it for you.
Every stage above is work the Agent does on your behalf. It owns your trust records, inventories senders from your real reports, aligns SPF and DKIM, advances the policy through quarantine to reject gated by the evidence, and holds it against drift. Deterministically. No DNS edited by hand.
Questions, answered.
How do I move my DMARC policy from p=none to p=reject?
In stages, gated by your reports. Publish p=none with reporting on, use the aggregate reports to inventory every legitimate sender and get each one aligned on SPF or DKIM, then advance the policy from none to quarantine, then quarantine to reject, confirming at each step that no aligned, legitimate mail is failing. The DNS change is trivial; the report evidence that makes it safe is the work.
What's the difference between p=quarantine and p=reject?
Both act on mail that fails DMARC. p=quarantine tells receivers to divert it, typically to the spam folder, so it is held but still reachable. p=reject tells them to refuse it outright, so the forged message is never delivered at all. Quarantine is the safety step on the way to reject.
Can I go straight to p=reject?
You can, but it is how rollouts break mail. Skipping quarantine means any sender you missed or misconfigured is discovered by bouncing real messages instead of quietly diverting them. Step through quarantine, watch a week of clean reports, then commit to reject.
How do I test an enforcement policy before it goes live?
DMARCbis replaced the old pct= percentage ramp with a binary t= flag. Publish the stronger policy with t=y to mark it as testing, confirm your reports stay clean, then drop the flag to make it live. Partial percentage rollouts are gone under the new standard.
What should I check before advancing my DMARC policy?
One thing: that no legitimate, aligned mail is failing in your aggregate reports. Before every advance, read a few days of reports and confirm the only failures are mail you do not recognise. If any of your own senders are still failing alignment, fix that before you move the policy up.
How do I keep my domain at p=reject once I get there?
By not looking away. Enforcement is a state, not a milestone. A new vendor, an edited SPF record or an expired DKIM key can silently break alignment and start bouncing your own mail. Keep reading the aggregate reports, or hand that job to something that watches continuously.
Know the path. Skip the walk.
Scan your domain free to see which stage you're on, then let the Agent take it to p=reject.
Free · No signup