DMARC Policy
A DMARC policy (the p tag) tells receivers what to do with mail that fails DMARC: monitor only (none), treat as suspicious (quarantine), or refuse delivery (reject).
The three domain policies
Choose policy based on visibility and alignment health—not calendar deadlines alone.
| Field | Value |
|---|---|
| p=none | Monitor and report; do not alter delivery for failures |
| p=quarantine | Prefer spam/junk for failing messages |
| p=reject | Refuse failing messages at the SMTP edge when possible |
Recommended rollout
Publish p=none with rua, inventory senders from aggregate reports, fix SPF/DKIM alignment, then raise policy. Use pct to stage quarantine/reject if needed.
- Week 0: p=none + rua
- Identify unknown and failing sources
- Authorize or stop unauthorized senders
- Move to quarantine, then reject
v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]Subdomain policy (sp)
If sp is omitted, subdomains inherit p. Set sp explicitly when marketing subdomains need a different stance than the apex.
v=DMARC1; p=reject; sp=quarantine; rua=mailto:[email protected]Failures that block policy upgrades
Marketing platforms sending From your apex without aligned DKIM/SPF, forwarded mail that breaks SPF (rely on DKIM), and nested SPF PermError are common blockers.
How QuickDMARC helps
QuickDMARC surfaces failing sources, tracks policy readiness, and supports Managed DMARC so policy changes do not require constant DNS edits.
Frequently asked questions
Should I start with p=reject?
No. Start with p=none and rua so you can see real traffic before enforcement.
What does pct do?
pct applies the policy to only a percentage of failing messages, useful for staged rollout.
Is quarantine safer than reject?
Quarantine is a middle step. Reject provides stronger spoofing protection once legitimate mail is aligned.