DMARC p=none vs Quarantine vs Reject: Which Policy?
A DMARC policy tells participating receivers the domain owner’s handling preference when a message fails DMARC validation. Choosing a stronger policy can reduce domain spoofing, but it can also disrupt legitimate mail if sending sources have not been audited.
Simplified comparison of domain-owner policy requests. Receivers retain discretion; enforcement does not establish inbox delivery or block every impersonation attempt (RFC 9989).
In brief
A DMARC policy tells participating receivers the domain owner’s handling preference when a message fails DMARC validation. Choosing a stronger policy can reduce domain spoofing, but it can also disrupt legitimate mail if sending sources have not been audited.
The worked examples on this page are explanatory, not results from your domain or a mailbox-provider test.
What each policy requests
p=none is monitoring mode: it does not request a rejection or quarantine action from the domain owner. p=quarantine expresses a preference that failing mail be treated as suspicious. p=reject requests stronger rejection handling for failed validation. Receiver policy and local handling decisions still matter.
Under RFC 9989, DMARC can pass when at least one qualifying SPF or DKIM authentication result aligns with the visible From domain. The presence of three DNS records does not establish that every actual message passes.
Google and Yahoo permit a DMARC policy of at least p=none for their stated bulk-sender requirements, alongside other requirements. This is a sender-category requirement, not proof that publishing p=none makes all messages compliant or delivers them to the inbox.
p=none policy does not request enforcement, but still supports DMARC reporting when properly configured. Verify every legitimate sender and study reports before requesting quarantine or rejection.Subdomain settings and policy inheritance
A parent-domain DMARC policy can apply to subdomains according to DMARC policy discovery. The optional sp tag addresses existing subdomains, and np addresses non-existent subdomains of the organizational domain under RFC 9989. Stronger subdomain policy settings may carry enforcement risk even when the main p setting remains none.
Do not assume a DNS lookup at a subdomain lacking its own DMARC TXT record means that no effective policy applies. Effective policy discovery can involve the organization’s relevant published policy.
How did the pct tag change in 2026?
RFC 9989 removed the legacy pct tag. Its former percentage-based rollout behavior was not implemented consistently. The newer optional t flag indicates testing preferences; it is not equivalent to reliably enforcing on an arbitrary percentage of messages.
Do not add a made-up pct percentage to a new record. The safest rollout approach is to monitor aggregate reports, verify all legitimate streams, then make an explicit informed policy change and assess actual outcomes.
DMARC policy comparison
This reference separates evidence from interpretation. It is general guidance, not the result of a live check of your domain.
| Policy | What the owner requests | Consider before changing |
|---|---|---|
p=none | Monitoring; no special enforcement requested | Configure reporting and map legitimate senders |
p=quarantine | Treat failed messages as suspicious | Verify alignment across services and monitor effects |
p=reject | Reject messages that fail DMARC | Confirm coverage, forwarding cases and recovery options |
Receiver handling can differ from the requested policy. Interpret published policies alongside aggregate reports, local policies and the actual accepted or rejected messages. Never assume changing the record is a guaranteed spam-placement fix.
A cautious deployment checklist
Identify staff mail, website forms, billing alerts, marketing services, forwarding and third-party platforms. Verify their DKIM signing domains and relevant envelope domains using messages received at controlled mailboxes.
Set up a reporting destination you can manage and use the DMARC Report Analyzer for aggregate XML evidence. A reporting destination at another domain may require external destination authorization; do not assume sending reports there will automatically work.
Use the DMARC Record Generator to draft a record. It does not publish DNS. Before replacing an existing record, compare every tag and confirm that legitimate sending services will not be disrupted. For domain discovery use the Email Domain Checker.
pct tag. Do not treat a percentage in old guides as a supported gradual-rollout mechanism in a newly drafted policy.Common questions
Is p=none a guarantee messages pass DMARC?
No. A monitoring policy and an actual message’s authentication and alignment result are different things.
Should I move straight to p=reject?
Not without reviewing legitimate sending sources and alignment evidence; an aggressive change can break authorized messages.
Primary sources and fact-check
Reviewed October 20, 2026 against the specifications and provider documentation below. Provider products, interfaces, and requirements can change; check the official source before making a production DNS or mailing decision.