DELIVERABILITY GUIDE

DMARC p=none vs quarantine vs reject: what each setting actually does

A DMARC record with p=none is watching for spoofed mail using your domain — not blocking any of it. Here’s what each policy level actually does, and why jumping straight to reject is the single most common way to break your own mail.

By the VanceSentinental team · August 2026

DMARC's policy tag — the p= value in your DMARC TXT record — is the single setting that determines whether DMARC is actually protecting your domain from spoofing, or just quietly watching. A huge share of domains have a DMARC record at all and still have zero enforcement, because nobody moved the policy past its default.

Policy	What happens to mail that fails DMARC
`p=none`	Nothing. It's delivered normally, indistinguishable from legitimate mail. You only find out via aggregate reports (if you're reading them).
`p=quarantine`	Sent to spam/junk instead of the inbox. Recipients can still find it, but it doesn't reach them cleanly.
`p=reject`	Rejected outright at the receiving server. It never reaches the recipient's mailbox in any form.

INTERACTIVE — CLICK A POLICY TO SEE WHERE SPOOFED MAIL ACTUALLY GOES

DMARC policy simulator

Spoofed email
fails SPF + DKIM alignment, claims your domain

→

Inboxdelivered normally

Spam folderquarantined, still exists

Rejectednever delivered

At p=none, this message lands in the recipient's inbox exactly like legitimate mail — DMARC only logged that it happened.

Why so many domains are stuck at p=none

p=none is DMARC's safe default, and for good reason — it's how you're supposed to start. It lets you collect aggregate reports (the rua tag) showing every source currently sending mail claiming to be from your domain, without any risk of blocking something legitimate you didn't know about. The problem is that p=none was only ever meant to be a temporary first stage. In practice, it's where most DMARC setups quietly stay forever, because nobody circled back once the initial setup was "done."

A domain sitting at p=none has a DMARC record that looks correct to anyone glancing at it, publishes properly, and does absolutely nothing to stop someone from sending phishing email that appears to come from your own domain.

Why you can't just jump to p=reject

This is the mistake that actually breaks things. Moving straight to p=reject without first confirming every legitimate sender is properly aligned means you will start rejecting your own real mail — the marketing platform, the transactional sender, the CRM, the helpdesk tool, anything that isn't sending with matching SPF or DKIM alignment to your domain. Unlike an SPF lookup error, this isn't silent to your recipients: their bounce messages will say your own domain rejected the email, which is a confusing, bad experience for both sides.

The safe order of operations

1. Publish DMARC at p=none and collect aggregate reports for at least a few weeks. 2. Identify every source in those reports, confirm which are legitimate, and fix SPF/DKIM alignment for each one. 3. Move to p=quarantine once every legitimate source aligns cleanly — this is your safety net, since misclassified mail still lands in spam, not nowhere. 4. Only move to p=reject once quarantine has run clean for a stretch with no legitimate mail getting caught.

How to read an aggregate report without a dedicated tool

DMARC aggregate reports (rua) arrive as XML attachments, usually daily, from every major receiver that gets mail claiming to be from your domain. At a minimum, look for: the sending IP or source name, whether SPF passed, whether DKIM passed, and whether the overall result aligned with your policy. A source you don't recognize sending mail that fails both SPF and DKIM alignment is either a legitimate sender you haven't fixed yet, or someone spoofing your domain — either way, it's the thing to chase down before tightening enforcement.

What the subdomain policy (sp=) tag adds

DMARC's sp= tag sets a separate policy for subdomains that don't have their own DMARC record. It's easy to miss entirely — a domain locked down at p=reject with no sp= tag set can still leave every unused subdomain wide open to spoofing.

FREE TOOL — RUNS ENTIRELY IN YOUR BROWSER, NOTHING SENT ANYWHERE

DMARC record generator

Fill in the fields below and get the exact TXT record to publish at _dmarc.yourdomain.com — syntax handled for you, including where to send the reports that make policy 3 in the safe order above possible.

Policy

Subdomain policy (sp=) — optional, defaults to same as above

Aggregate report email (rua) — where daily XML reports go

Enforcement percentage (pct) — % of mail the policy applies to

Moving from p=none to enforcement without breaking your own mail

A DMARC Enforcement Rollout handles the staged move for you — reading the aggregate reports, confirming every legitimate sender aligns, and moving your policy up in stages over 4–8 weeks, monitored at each one.

Ask about DMARC rollout — $2.5–4.5k See all one-time engagements