dmarcenforcementp-rejectoperationsdeploy

Deploy DMARC Safely: The Path from p=none to p=reject

DMARC Shield 28 June 2026 Updated 30 July 2026

To deploy DMARC safely: publish p=none with working aggregate reports, fix legitimate senders until they pass, then raise policy through p=quarantine to p=reject. Monitoring forever is not a strategy; enforcement is the goal.

Many organisations enable DMARC at p=none and stop. The record is “done.” Security can tick a box. Marketing still delivers. Spoofers still use the domain freely.

This post is the operations path after the DNS record exists — inventory, stages, communication, rollback, and ongoing hygiene. For the step-by-step DNS how-to (publish _dmarc, tags, first checks), use the setup source of truth: How to set up DMARC. SPF and DKIM guides: SPF setup, DKIM setup. Multi-domain estates should use the enterprise-wide DMARC deployment checklist.

What is p=none? (and the other policies)

Policy	Tag	Receiver behaviour (simplified)	Your job
None	`p=none`	Authenticate and report; usually still deliver failures	Discover senders and fix legit fails
Quarantine	`p=quarantine`	Prefer spam/junk for failing messages	Prove legitimate mail still lands correctly
Reject	`p=reject`	Prefer not to accept failing messages	Maintain sender hygiene forever

What is DMARC none? p=none is monitoring mode. Receivers apply authentication and send aggregate reports (rua), but they are not instructed to junk or refuse failures. It is the correct place to start a deploy — not the place to live forever.

Exact behaviour varies by mailbox provider, but the operational meaning is stable: stronger policy raises the cost of spoofing and the cost of unauthenticated legitimate senders.

DMARC policy setup at a glance

Minimal useful record for a first deploy:

v=DMARC1; p=none; rua=mailto:…; fo=1;

Useful additions once you understand them:

pct=100 (default) — percentage of mail the policy applies to
sp= — policy for subdomains
adkim / aspf — alignment mode (relaxed is the usual start)
ruf= — forensic reports (optional; privacy and volume trade-offs)

Keep the first version boring. Fancy tags without report review do not help. Full tag walkthrough: DMARC setup guide.

Preconditions before you tighten anything

Do not change p= until these are true:

Aggregate reports are flowing and someone reviews them on a schedule.
A sender inventory exists — every high-volume source has an owner.
Primary platforms pass DMARC alignment (usually DKIM on the organisational or From domain, plus SPF where it still matters).
A rollback plan exists — you know who can edit DNS and how fast.

If any of those are missing, stay on monitoring and fix the process first. Public DNS posture while you plan: free tools.

Stage 0: publish monitoring correctly (enable DMARC)

Goal: enable DMARC without delivery risk.

Create _dmarc TXT with p=none and a working rua.
Confirm the record resolves (checker or dig).
Wait for real traffic — Microsoft 365 / Google Workspace, billing, CRM, marketing, support.
Assign an owner for weekly report review.

Exit criteria: reports arrive; you can list intentional senders vs unknowns.

Stage 1: clean the inventory (still `p=none`)

Spend this stage only on legitimacy:

Add missing DKIM for CRMs, billing, support, and marketing platforms
Remove dead SPF includes that burn the 10-lookup budget (SPF permerror guide)
Decide subdomain strategy (shared apex vs dedicated sending hosts)
Document “do not send from brand domain” tools that should use a different From address
Onboard new SaaS with a checklist before go-live (new SaaS sender checklist)

Exit criteria: known intentional senders pass consistently across several report cycles. Residual fails should be mostly unknown or low-value. For reading XML/aggregate views, see how to read DMARC aggregate reports.

Stage 2: quarantine with eyes open

Move to:

v=DMARC1; p=quarantine; rua=mailto:…;

Optional caution for large estates: start with pct=25 or pct=50, watch reports and support tickets, then raise percentage. Not every organisation needs percentage staging; many smaller domains jump to full quarantine successfully after a clean inventory.

Watch for 1–2 weeks (longer if you have complex multi-tenant senders):

Finance and customer-facing mail complaints
New sources appearing in reports after the change
ESP reputation issues that look like authentication problems

If a critical system breaks, fix authentication first. Temporary rollback to p=none is acceptable; silent permanent rollback is not.

Stage 3: reject when quarantine is boring

When quarantine produces no legitimate pain for a stable period, move to:

v=DMARC1; p=reject; rua=mailto:…;

What p=reject does: tells cooperating receivers to refuse messages that fail DMARC for your domain. This is the control that most reduces cheap exact-domain spoofing.

It does not stop:

lookalike domains (yourc0mpany.co.za) — see lookalike domains vs spoofing
compromised real mailboxes
display-name only fraud

Those need process, awareness, and other controls. DMARC reject still removes an entire class of attack: forging your exact domain without authentication.

Rollback plan (write this before you tighten)

Before quarantine or reject, document:

Item	Owner	Detail
Who can edit DNS		Name + backup
How fast can DNS change		Provider TTL / change window
Rollback target		Usually last known-good `p=none` or prior `p=`
Who decides to roll back		Not “whoever gets the first ticket” alone
How you re-advance		Fix root cause → re-quarantine → reject; do not abandon enforcement forever

Safe rollback sequence:

Confirm the symptom is authentication (reports show your legit source failing), not list quality or content.
Edit _dmarc to the previous policy (or p=none) and wait for TTL.
Fix SPF/DKIM/alignment for the broken sender.
Re-enter the stage ladder; do not permanently freeze at monitoring after one scare.

The teams that bounce back to permanent p=none usually lacked inventory and ownership, not “bad luck with DNS.”

Percentage, subdomains, and partial estates

`pct`

Useful when you have many business units and want a controlled blast radius. Some receivers treat percentage differently; partial policy can create confusing report patterns. Prefer a short percentage stage over living at 25% forever.

Subdomains

Decide explicitly:

Marketing on news.example.co.za with its own DMARC
Transactional on mail.example.co.za
Apex reserved for people mail

Unset or weak subdomain policy (sp=) is a common hole. Spoofers like forgotten hosts.

Third parties that will never align

Some legacy systems cannot DKIM-sign as you. Options:

stop using them for brand From addresses
migrate to a vendor that supports domain authentication
accept that those messages will not survive enforcement (then plan decommission)

Do not hold the whole domain at p=none forever for one non-compliant tool.

Communication checklist (before each policy raise)

Notify before quarantine and before reject:

IT / messaging owners
Marketing operations
Finance / billing notifications owner
Support leadership (they hear “mail went to spam” first)
MSP or DNS host that implements the change

Share: change window, expected symptoms, who to call, and the rollback path.

Bulk senders also need Gmail/Yahoo hygiene (Gmail and Yahoo sender rules).

Deploy DMARC checklist (end-to-end)

Setup (DNS) — details in dmarc-setup:

_dmarc TXT published with v=DMARC1
p=none initially
rua= delivers to a mailbox or collector someone will open
SPF and DKIM in place for primary platforms

Operations (this article):

Sender inventory with owners
Reports reviewed for at least one full business cycle
Intentional high-volume sources pass alignment
Stakeholders notified before quarantine
p=quarantine stable (tickets + reports)
Stakeholders notified before reject
p=reject published; residual fails are expected noise or fixed
Rollback owners and DNS access confirmed
New SaaS cannot send as brand without authentication review

After you reach reject

Enforcement is maintenance, not a trophy.

Re-read reports when any SaaS is onboarded
Re-check alignment after ESP migrations
Keep SPF lean
Review subdomain launches the same way you review apex changes

A realistic timeline

Estate complexity	Typical path
Single M365/Google + one ESP	2–6 weeks monitoring → quarantine → reject
Many SaaS senders, agencies, franchises	1–3 months of inventory work first
Chaotic multi-brand DNS	Fix governance before tightening policy

Speed is less important than not stalling permanently at monitoring.

Setup guide vs this operations path

Resource	Use it for
How to set up DMARC	First publish, DNS tags, verify record, safe raise summary
This post	Deploy/enforcement programme: stages, inventory, comms, rollback, timelines
Free tools	Instant public SPF/DKIM/DMARC posture check
Shield Monitor / Managed	Ongoing reports and (Managed+) assisted progression

Summary

Enable DMARC with p=none and working aggregate reporting (setup guide).
Build and clean a sender inventory until intentional mail passes.
Move to p=quarantine and watch people channels, not only dashboards.
Move to p=reject when quarantine is uneventful.
Keep a written rollback; re-advance after fixes — do not abandon enforcement.
Treat every new sender as a controlled change forever after.

If you want help seeing current public authentication posture while you plan the path, use the free checkers on getdmarcshield.com/free-tools. For ongoing report visibility and domain status, monitoring belongs in a product you will open weekly — not a mailbox nobody reads.