DMARC p=none vs quarantine vs reject: which one you actually want

Updated August 2026 · about a 6-minute read

Here's the thing nobody tells you when you first set up DMARC: p=none doesn't protect anything. You publish the record, you feel like you've done the security task, and you've actually just turned on a camera. That's it. The camera watches people spoof your domain and mails you a report about it. If your goal was to stop the spoofing, you're not there yet — and a lot of domains have been sitting at "not there yet" for years.

The policy — that little p= tag in your DMARC record — is the whole game. Let me walk through what each setting actually does, in plain terms, because the RFC language makes it sound more mysterious than it is.

The three policies, honestly

Read that first row again. p=none is a listening post. It's genuinely useful — you cannot safely tighten a policy you can't see — but a domain parked on none is exactly as spoofable as a domain with no DMARC at all. The record's there, the protection isn't.

So why does anyone start at none?

Because jumping straight to reject is how you block your own invoices. Almost every organization sends "as" its domain from more places than it thinks: the CRM, the billing tool, the help desk, the marketing platform, the thing HR uses, that one script on a server nobody remembers setting up. If any of those isn't authenticated properly and you flip to reject on day one, that mail vanishes. Silently. And you find out when a customer says they never got the receipt.

So none is the on-ramp. You publish it, you collect a couple of weeks of reports, and you use those reports to build a list of every legitimate sender and make sure each one passes SPF or DKIM. Then — and only then — you start climbing.

The climb: none → quarantine → reject

Do it in steps, not one leap. The pct tag lets you apply a policy to a fraction of failing mail while you build confidence.

1. Start at none. v=DMARC1; p=none; rua=mailto:you@yourdomain.com. Read the reports. Find every real sender.
2. Fix your senders. Get each legitimate source passing SPF or DKIM with alignment. This is the actual work; the policy tags are the easy part.
3. Move to quarantine, partially. p=quarantine; pct=25, then watch. Nothing legitimate going to spam? Raise to 50, then 100.
4. Move to reject. p=reject. Now a spoof of your domain is refused at the door, which is the entire reason you started.

Rushing this blocks your own mail. Never finishing it leaves you unprotected. The whole discipline is just: keep moving, but look before each step.

The failure mode isn't going too fast. It's going to none once, feeling done, and never coming back. Six months later the record's still there, still doing nothing, and everyone assumes email is "handled."

The part that gets forgotten

Even after you reach p=reject, DMARC isn't a set-and-forget line in a DNS file. Records get edited during unrelated DNS changes. Someone "cleans up" TXT records and drops your policy back to none without realizing what it did. A new sending tool gets added and quietly starts failing. None of that announces itself.

That's the same silent-drift problem that hits TLS certificates and security headers — the config is right until one day it isn't, and nobody's looking. Which is the argument for having something watch it for you instead of relying on remembering to check.