DMARC p=none vs quarantine vs reject

The short answer

DMARC p=none, p=quarantine, and p=reject are not deliverability scores. They are DNS policies that tell receivers what you want done with mail that uses your visible From domain but fails DMARC.

p=none means monitor. Receivers can still deliver, spam, or reject based on their own systems, but your DMARC record is not asking for quarantine or rejection. Use it while you find every legitimate sender and read aggregate reports.

p=quarantine asks receivers to treat DMARC-failing mail as suspicious. In practice, that often means spam or junk placement, but RFC 7489 leaves final handling to the receiving mailbox provider.

p=reject asks receivers to reject DMARC-failing mail. It is the strongest DMARC policy request, but it is only safe after legitimate senders consistently pass aligned SPF or DKIM.

The usual path is none, then quarantine, then reject. Do not jump straight to reject unless you have inventoried every platform that sends as the domain, including CRM, billing, support, product, marketing, payroll, and any forwarding or relay paths that can change authentication results.

What DMARC actually checks

DMARC passes when at least one authentication method passes and aligns with the domain in the visible From header. A raw SPF pass or DKIM pass is not enough if it belongs to a different domain.

• SPF is a DNS TXT record that says which hosts can send for the envelope sender domain. Keep one SPF record per domain, watch the 10 DNS-lookup limit in RFC 7208, and understand the ending: ~all is softfail and -all is fail. If SPF evaluation exceeds the DNS lookup limit, the result is a permanent error, not a clean pass.
• DKIM signs mail with a private key and publishes the public key under a selector in DNS, such as selector._domainkey.example.com. RFC 6376 defines the signature and selector model. Each sending platform may use its own selector. DKIM is often more resilient than SPF when mail is forwarded because the signature can survive normal transit.
• DMARC uses SPF and DKIM results, then checks alignment with the From domain. Relaxed alignment is the default in RFC 7489, so a subdomain can align with the organizational domain unless you publish strict alignment with aspf=s or adkim=s.
• The rua=mailto: tag requests aggregate DMARC reports. Those reports are the map for moving from p=none to enforcement without blocking real mail.

Mailbox providers such as Gmail, Outlook.com, and Microsoft 365 also use reputation, complaint rates, content signals, malware checks, blocklists, reverse DNS, and local policy. DMARC helps prove identity. It does not force inbox placement.

When to use each policy

Use the policy that matches how confident you are in your sender inventory and alignment, not how much you want better inbox placement.

Use p=none when you are discovering senders, turning on DKIM, or cleaning up SPF. This is the correct first step for most domains because aggregate reports show who is sending, which sources pass, and which sources fail. A common starter record is v=DMARC1; p=none; rua=mailto:dmarc@example.com.

Use p=quarantine when nearly all legitimate traffic passes DMARC and the remaining failures are either abuse, retired tools, or low-risk edge cases. RFC 7489 defines pct= for applying policy to only part of failing traffic, but you should still watch reports because receivers decide final handling.

Use p=reject when every known sender is authenticated and aligned, important subdomains are covered, and support teams know how to handle authentication failures. Microsoft documentation recommends a gradual rollout from p=none to p=quarantine to p=reject for custom domains after monitoring. Google sender guidelines require DMARC alignment for covered senders and point senders to SPF, DKIM, and DMARC as baseline authentication, not as an inbox guarantee.

A safe rollout checklist

Most DMARC outages come from missing senders, broken SPF, unsigned DKIM, or a third-party tool using its own domain in the wrong place.

• List every source that sends as your domain, including product mail, newsletters, invoices, help desk replies, alerts, and executive mail.
• Check MX records so people can reply to domains that receive mail. Separate sending subdomains when marketing or automation tools should not share the root domain's operational reputation.
• Fix SPF records before enforcement. Remove dead includes, avoid multiple SPF records, stay under the 10-lookup limit, and use -all only when you are sure all legitimate envelope sender paths are covered.
• Turn on DKIM for each sender with that platform's selector. Confirm the DKIM d= domain aligns with the visible From domain, either directly or by relaxed organizational-domain alignment.
• Publish rua reporting at p=none, review sources for a normal sending cycle, then move to quarantine before reject. If you need exact tag behavior, use RFC 7208 for SPF, RFC 6376 for DKIM, RFC 7489 for DMARC, plus the current Google and Microsoft sender guidance.
• Check major blocklists and domain reputation signals if mail still lands in spam after authentication passes. Authentication is table stakes, not a cure for complaints, unwanted mail, or poor sending practices.

You can run a quick SPF, DKIM, DMARC, MX, and drift check with the free InboxRadar domain scorecard at /#check, or compare related deliverability fixes in the InboxRadar guides.