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; np=reject; 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=, np=, and the t= testing flag that replaced 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=, np= and t=

These follow RFC 9989, the DMARC standard published in May 2026 that replaced RFC 7489. The RFC itself anticipates receivers still running RFC 7489 implementations for a while, which matters for the last tag below.

sp= sets a separate policy for subdomains that exist. 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.

np= is new in RFC 9989: the policy for subdomain names that don't exist in DNS at all, such as an invented secure-billing.example.com. Omitted, those names fall back to sp=, then p=. Mail from a name that doesn't exist is almost never legitimate, so np=reject is usually a low-risk early step even while p= stays at none; your reports will show if any system of yours sends from an unpublished name. Receivers built only on RFC 7489 ignore it as an unknown tag.

t= is testing mode, and it replaced the old pct= tag. Under RFC 7489, pct=25 applied the policy to a sampled quarter of failing mail and handled the rest one level softer. RFC 9989 retired pct, noting that receivers rarely applied values other than 0 and 100 accurately, and substituted t=y: receivers apply the next policy level down, so p=quarantine; t=y behaves like none and p=reject; t=y like quarantine, while reports keep flowing either way. During the overlap a record can carry both signals, as in p=quarantine; pct=25; t=y, with legacy receivers reading the percentage and updated receivers honoring the flag. Two cautions survive the change: testing touches only failing mail (your aligned mail is never affected), and a record left in testing mode lets spoofed traffic through at the softer level, so it's a rollout tool, never an endpoint. Remove the flag once reports run clean.

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 after a few weeks rehearsed at p=quarantine; t=y if your mail streams are complex (add a stepped pct= for receivers still on the older rules). 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. RFC 9989 adds a caution of its own for domains whose users post to mailing lists: it advises against p=reject for them, and suggests that such domains spend at least a month at none and an equally long period at quarantine, comparing dispositions, before trying it. 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 9989 (May 2026) and observable receiver practice, with the legacy pct mechanism described per RFC 7489, which RFC 9989 replaced; 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

10 September 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 policy for existing subdomains, np= (added in RFC 9989) covers subdomain names that don't exist in DNS, 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.