DMARC p=none vs quarantine vs reject
p=none requests monitoring, p=quarantine requests suspicious treatment, and p=reject requests rejection for mail that fails DMARC; a staged rollout is safer than copying the strongest policy.
How it works
DMARC builds on aligned SPF or DKIM for the visible From domain. Its policy communicates the domain owner's preference, but individual receivers apply local handling.
p=none is valuable because it lets a domain observe the authentication landscape before asking receivers to enforce. A domain may have payroll, customer support, invoice, marketing, and application mail systems that all use its visible From address. Monitoring helps identify which paths have aligned SPF or DKIM and which need configuration work. It is not a broken or meaningless DMARC record.
A staged rollout can be concrete. After reviewing legitimate sources, an owner might move from p=none to p=quarantine; pct=10, then increase pct as evidence supports it. The percentage applies to failing mail selected for the requested policy; it does not mean ten percent of all mail is ignored. An absent pct defaults to 100, so be explicit about the operational intention.
Subdomain mail needs separate thought. The sp tag can request a policy for subdomains when they do not publish their own DMARC record. A service sending as notices.example.com may need its own aligned configuration even when example.com is ready for enforcement. Do not assume an apex record answers every subdomain operational question.
Quarantine and reject are requests, not a universal promise of identical handling. Receivers combine DMARC with local abuse controls, message content, reputation, and reporting rules. A p=reject policy can reduce direct-domain spoofing but cannot prevent account compromise, lookalike domains, or every kind of phishing.
The DMARC Checker shows the published p, sp, pct, alignment, and reporting tags. It does not send a message, determine whether each provider signs with DKIM, or contact rua and ruf addresses. Use it to verify DNS policy, then rely on approved mail-reporting and provider evidence for a production rollout.
The three policy levels
p=none is useful for monitoring because it asks receivers not to apply DMARC enforcement solely from the policy. p=quarantine asks receivers to treat failing mail as suspicious, often by placing it in spam. p=reject asks them to reject it. Receiver behavior and reporting support vary.
pct can apply quarantine or reject to only a percentage of failing mail during a rollout; an absent pct defaults to 100. sp can set a policy for subdomains. These controls are not substitutes for checking every legitimate sending service.
Move from monitoring to enforcement
Start with p=none and review approved aggregate-report data through your mail workflow. Confirm that each sender has aligned SPF or DKIM, including third-party platforms and subdomains. Then use a measured pct and quarantine policy if the evidence supports it, before considering reject.
A record such as v=DMARC1; p=none; rua=mailto:reports@example.com requests monitoring. A later p=quarantine; pct=25 changes only a portion of failing mail. Our checker reads the published policy and does not contact rua or ruf destinations or perform live DKIM validation.
Practical guidance
- Treat p=none as monitoring, not protection.
- Check alignment for every sender before increasing policy.
- Review subdomain policy and pct deliberately.
Common question
Does p=reject guarantee a rejection? No. It is a request that each receiver combines with its own policy.