p=none, p=quarantine, p=reject: what each one tells a receiver

Every DMARC record carries a p= tag, and it tells a receiving mail server what to do with a message that fails both SPF alignment and DKIM alignment. p=none says deliver it as you would have anyway and send me a report. p=quarantine says treat it as suspicious, which in practice means the spam or junk folder. p=reject says refuse it, so it never reaches a mailbox. Those are the three values, and moving between them is a free edit to one DNS TXT record at _dmarc.yourdomain.

What a receiver does with each value

A receiver reads p=none as an instruction to change nothing. A message that fails DMARC lands wherever it would have landed without your record, and the receiver files a report about it. Reports are the whole output of this mode, so a p=none record with no rua= address gives you nothing you can see.

p=quarantine asks the receiver to treat failing mail as suspicious. Most large receivers map that to the junk folder; a few raise the spam score and let their own filters decide. It’s a working middle step with its own reports, and it’s the one most domains pass through on the way to reject.

p=reject asks the receiver to refuse the message outright. The sending server gets a bounce and nothing reaches the mailbox. This is the value that stops a forged invoice in your name from arriving, and it’s also the value that bounces your own mail if a sender you forgot about isn’t aligned yet, so you get there by the steps below, in order.

Where your record sits against the rest of the internet

The September 2026 census read 78,444,857 DMARC records. Of those, 41,798,631 publish p=none, 19,886,836 publish p=quarantine and 16,716,061 publish p=reject, with 43,329 so malformed that no policy could be read from them. The census counts 36,602,897 of the 78,444,857 records as enforcing, meaning quarantine or reject.

If your record says p=none you’re in the largest group, and that’s the right place to start as long as the reports go somewhere and someone opens them. Those counts are the policy each domain published; the census can’t see what any receiver did with any message, and nor can this page.

Step 1: publish p=none with a report address, then wait

The record you want at _dmarc.yourdomain looks like this:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain

The rua= address is where the reports go. The DMARC page walks through the other tags; for this step you need only p= and rua=, and the mailbox behind rua= has to exist before receivers start sending to it.

Then you wait, for two reasons. Your DNS record carries a TTL, and until that TTL expires a receiver that recently looked up _dmarc.yourdomain keeps its cached answer, including a cached “no such record”. Aggregate reports are then sent on a daily cycle; the ri= tag defaults to 86,400 seconds and the large receivers send daily whatever you put there. So a record published on Monday morning often shows its first report on Tuesday, and a silent first day doesn’t mean the record is wrong.

Sit at p=none long enough for the reports to name each sender that uses your domain. That means at least one full billing cycle if invoices go out monthly, and long enough to catch the payroll run, the newsletter platform, the CRM, the ticketing tool, and the office printer that scans to email.

Each source in the report shows whether SPF aligned, whether DKIM aligned, or neither. A source that only passes SPF will fail once a forwarder or mailing list rewrites the envelope. At p=none that’s harmless; at p=reject the message bounces, so get DKIM signing on it before you move on.

Before leaving this step, lower the TTL on the _dmarc record to 300 seconds. The TTL change is itself cached under the old TTL, so do it a day before you plan to ramp; after that, each policy edit reaches receivers in minutes instead of hours.

Step 2: move to p=quarantine, ramped with pct=

Once the reports show your own senders passing, change the record to:

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@yourdomain

pct= tells the receiver to apply the published policy to that share of failing mail and to treat the remainder under the next policy down. So pct=10 with p=quarantine sends one failing message in ten to junk and delivers the other nine as they would have been at none. pct= only means something on quarantine and reject. A pct=10 on a p=none record changes nothing, since the other nine messages in ten would need a policy softer than none, and there isn’t one.

Hold each pct= value for at least one full daily reporting cycle, and for a week if any of your senders run weekly. Watch the reports for a source you recognise that has started failing. If one appears, fix its SPF or DKIM at this step, where only a tenth of its mail is affected, then continue.

Raise pct= to 25, then 50, then 100, with the same wait at each stop. The TTL you lowered in step 1 is what makes each of these edits land within minutes; if you skipped that, budget a day per step for caches to expire.

Quarantine at pct=100 is a real policy in its own right, and domains sit here for months while the last stubborn sender gets fixed; you can stay as long as you need to.

Step 3: move to p=reject

The final record drops pct= or sets it to 100:

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain

You can ramp reject with pct= as well. The leftover share falls to quarantine rather than to none, so nothing slips back to plain delivery while you climb. The same waits apply: TTL first, then a daily reporting cycle before each increase.

Reject is also where your subdomains start to hurt. With no sp= tag, the policy on your organisational domain covers all of your subdomains, so a forgotten sender on mail.yourdomain or crm.yourdomain starts bouncing the moment reject lands. The sp= tag lets you hold subdomains at a softer policy while you find and fix them.

Keep rua= on the record after you reach reject. The reports keep naming new senders that staff sign up for, and they show you the forged mail that receivers are now refusing.

Reading dis= when a receiver reports back

An Authentication-Results header sometimes reads like this:

dmarc=pass (p=reject dis=none)

Two different things are in those brackets. p= is the policy the receiver found in your DNS record. dis= is the disposition the receiver applied to this particular message. On a pass, dis=none is the expected result: the message authenticated, so no action was taken, and your published p=reject wasn’t invoked.

On a fail the two can disagree. dmarc=fail (p=reject dis=quarantine) means the receiver read your reject policy and chose to quarantine instead, which happens under a receiver’s local policy, or when an ARC chain vouches for a forwarded message, or when your pct= is below 100 and this message fell into the softer share. The disposition is the receiver’s decision; your published p= is the request.

What to check on your own domain

The scan reads _dmarc.yourdomain and shows which p= value you publish, whether rua= is present, whether pct= is set, and whether the record parses at all. A misspelt value such as p=quarentine leaves the record without a readable policy, so receivers treat it as though you had said nothing at all.

Run the free scan, then place the result against the split above: if the p= value is none and there’s a rua= address, you’re at step 1 and the next move is to open the reports; if the p= value is none and there’s no rua=, add one today; if it’s quarantine or reject, you’re one of the 36,602,897 enforcing records and the remaining work is subdomains and any sender the reports flag.

Figures as of 5 September 2026, from the September 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.