DMARC policy explained: none vs quarantine vs reject, and how to move up safely

One tag in one DNS record decides what the world's mail servers do with messages that fail authentication for your domain. Everything else in a DMARC record is instrumentation; p= is the policy — the part with consequences:

v=DMARC1; p=quarantine; sp=reject; pct=100; rua=mailto:reports@example.com

This article is about that policy layer: what none, quarantine and reject each mean at the receiving end, what the supporting tags (sp=, pct=) change, and the staged rollout that takes a domain to enforcement without quarantining its own invoices. It deliberately stops there — the click-by-click setup lives in a separate walkthrough, diagnosing failures in another, and reading the XML reports in a third.

What a DMARC policy actually controls

When a message fails DMARC — no aligned SPF or DKIM pass for the From: domain — the receiver looks at your published policy to decide the message's fate. That's the deal DMARC offers: you, the domain owner, state the consequence; receivers apply it.

Two boundaries keep expectations honest. First, the policy applies only to failing mail. Moving from p=none to p=reject changes nothing for messages that authenticate correctly. Second, the policy is a request, not a command — receivers overwhelmingly honor it, but they retain discretion, and some (notably certain enterprise gateways) apply local overrides. Aggregate reports even have a field for this: disposition records what the receiver actually did, which sometimes differs from what you asked.

p=none: monitoring mode

v=DMARC1; p=none; rua=mailto:reports@example.com

p=none asks receivers to deliver failing mail normally and tell you about it in reports. It provides zero spoofing protection — a forged message failing every check still lands wherever it would have anyway.

That sounds useless and isn't. p=none exists because turning enforcement on blind is dangerous: almost every organization discovers, in its first weeks of reports, legitimate senders it forgot — the billing system, the CRM, the survey tool marketing connected years ago, none of them aligned. At p=none those discoveries cost nothing. At p=reject each one is lost mail.

p=none also satisfies the letter of Google's and Yahoo's bulk sender requirements, which demand a published DMARC policy but not a specific level. That has made it the internet's most popular parking spot — and the canonical DMARC failure is the domain that parks there forever, reports unread, protection never engaged. Treat none as a phase with an exit date, not a destination.

p=quarantine: failures go to spam

v=DMARC1; p=quarantine; rua=mailto:reports@example.com

p=quarantine asks receivers to treat failing mail with suspicion — in practice, almost always the spam folder. Spoofed messages stop reaching inboxes; misconfigured legitimate mail stops reaching them too, which is why you only move here after the reports run clean.

Quarantine is genuine protection with a safety net: a wrongly-failing message is recoverable from spam by an alert recipient, and the damage of a mistake is bounded. For many organizations it's also a comfortable long-term operating level while the last stubborn mail flows (an ancient regional mail relay, a partner sending as your domain) get fixed or retired.

p=reject: failures bounce

v=DMARC1; p=reject; rua=mailto:reports@example.com

p=reject asks receivers to refuse failing mail outright during the SMTP conversation. The spoofed message is never delivered anywhere; the sender gets a bounce. This is full enforcement — the level at which your domain stops being usable for impersonation at any honoring receiver, and the level BIMI logo display requires (quarantine at full coverage also qualifies with most providers).

Reject's cost profile is the mirror of its benefit: a legitimate mail flow you missed doesn't land in spam, it vanishes from the recipient's world entirely. Which is why reject is earned through the ladder, not declared on day one.

The supporting tags: sp= and pct=

sp= sets a separate policy for subdomains. Omitted, subdomains inherit p=. The tag matters in both directions: a root at p=none with sp=reject protects unused subdomains while you sort out the root, and a root at p=reject still doesn't cover a delegated subdomain that publishes its own weaker record. Spoofers probe subdomains precisely because they're the forgotten flank.

pct= applies the policy to a sampled percentage of failing mail: p=quarantine; pct=25 quarantines roughly a quarter of failures and delivers the rest. It exists to soften transitions — a dial between levels rather than a cliff. Three cautions: it samples failing mail only (your aligned mail is never touched); receivers honor it unevenly; and pct below 100 means most spoofed traffic still gets through, so it's a rollout tool, never an endpoint. Ratchet it up and remove it.

The staged rollout

The ladder, with the gate for each rung:

1. Publish p=none with a rua address. The DMARC generator builds a correct record; the DMARC checker confirms what's live. Gate to proceed: none — do this today.
2. Read reports for several weeks. Inventory every source sending as your domain; decide which are yours. Gate: every legitimate source identified.
3. Fix alignment source by source. Custom DKIM signing at your ESP, SPF includes for your own systems, retirement of flows nobody owns. Gate: reports show your legitimate mail passing aligned, consistently.
4. Move to p=quarantine — directly, or via pct=25 → 50 → 100 over a few weeks if your mail streams are complex. Gate: a full reporting cycle at quarantine with no legitimate mail caught.
5. Move to p=reject. Keep reading reports; new systems and new vendors will keep appearing for as long as your organization exists.

Timeline honestly stated: small senders with one ESP can walk this in a few weeks; organizations with many mail-generating systems routinely take months. The pace is set by step 3, and step 3 is set by how many things send as your domain — most people's answer is "more than we thought."

Choosing your operating level

The decision is about failure costs, not ambition. If a spoofed message in a customer's inbox is a serious harm (finance, B2B with invoice flows, anyone phished before), push to reject and accept the operational care it demands. If your mail ecosystem is sprawling and partially inherited, a clean quarantine beats a rushed reject — visible-but-spam beats silently-gone while you chase stragglers. The only wrong steady state is p=none with unread reports: all of DMARC's cost, none of its protection.

Related guides

• DMARC checker — validate your live record and policy right now
• DMARC generator — build a correct record for your rollout stage
• What is DMARC? — alignment and the full tag reference
• SPF record — one of the two mechanisms DMARC aligns
• DKIM — the alignment path that survives forwarding
• BIMI — the logo standard that requires enforcement
• How to set up DMARC — the step-by-step deployment walkthrough

About this guide

Written by InboxRatio Editorial. Policy behavior described here follows RFC 7489 and observable receiver practice; provider requirements are attributed to Google's and Yahoo's published sender documentation. We configure DMARC on our own test domains for every benchmark cycle, and the rollout advice above matches what we practice.

Methodology

InboxRatio measures inbox placement by sending identical campaigns through each reviewed platform to a controlled seed list — with SPF, DKIM and DMARC configured on our own domains before any measured send, because unauthenticated tests would measure the wrong thing. The full protocol is at how we test.

Last updated

21 August 2026. Reviewed quarterly against provider documentation and RFC guidance.

Frequently asked questions

What is the best DMARC policy? The strongest your mail flows can survive. p=reject is the security end-state, but the best policy today is the one your DMARC reports justify: none while inventorying senders, quarantine once legitimate mail aligns, reject when quarantine runs clean.

Is p=none good enough for Google and Yahoo's requirements? It satisfies the published requirement to have a DMARC policy, yes. It provides no spoofing protection, so treat it as compliance plus monitoring, not as a finished deployment.

What's the difference between quarantine and reject? Quarantine asks receivers to deliver failing mail to spam — recoverable by the recipient. Reject asks them to refuse it during delivery — gone, with a bounce to the sender. Quarantine bounds the cost of your mistakes; reject eliminates the spoofed message entirely.

How long should I stay at p=none? Until several consecutive weeks of aggregate reports show every legitimate source passing with alignment. For a simple setup that can be under a month; for a complex organization, several. The gate is report contents, not elapsed time.

Does p=reject affect my deliverability? Your aligned mail is untouched — policy applies only to failures. Indirectly, enforcement helps domain reputation by cutting spoofed traffic that would otherwise pollute your domain's track record.

Can I set different policies for subdomains? Yes — sp= sets the subdomain policy, and any subdomain can publish its own _dmarc record that overrides inheritance. Audit what actually resolves for your subdomains; inherited assumptions and DNS reality drift apart.

Do this much today: publish p=none with a reporting address, put a recurring slot on the calendar to read what comes back, and let the reports — not the calendar — promote you to quarantine and reject. The first step takes two minutes with the DMARC generator.