DMARC Policy: p=none vs quarantine vs reject (and Getting to Enforcement)

A DMARC policy tells receiving mail servers what you'd like done with mail that fails DMARC for your domain. p=none asks for nothing beyond reports, p=quarantine asks receivers to treat failing mail as suspicious (usually the spam folder), and p=reject asks them to refuse it outright. The right path is to start at none, fix every legitimate sender until it passes, then move to quarantine and finally reject.

The policy is the p= tag in your DMARC record at _dmarc.example.com. If you need the basics first, start with What is DMARC?, and for the full list of tags see DMARC record syntax and tags explained.

The three policies side by side

The DMARC specification (RFC 9989, published in May 2026) describes these as statements of how you see failures, not commands. Under none you "offer no expression of preference." Under quarantine you consider failing mail suspicious. Under reject you consider a failure "a clear indication that the use of the domain name is not valid."

p=none: monitoring

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

Receivers deliver mail exactly as they would have without DMARC, and the ones that support reporting send you aggregate reports about every source using your domain. That's the whole value: visibility. A p=none record without a rua address gets you almost nothing.

p=none is enough to meet Gmail's and Yahoo's bulk sender requirements. Google's guidelines say plainly that "your DMARC enforcement policy can be set to none," and Yahoo asks for "at least p=none." Note that both still require your mail to actually pass DMARC with aligned SPF or DKIM. The policy level and the pass requirement are separate things.

p=quarantine: the middle step

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

Failing mail is treated as suspicious. In practice that usually means the spam folder. Microsoft 365, for example, documents that with its "honor DMARC policy" setting on, quarantine-policy failures go to the Junk Email folder (or to quarantine, if the admin configures it that way).

Quarantine is where you find out whether you missed anything. A missed sender's mail lands in spam instead of bouncing, which hurts, but it's recoverable and the mail still exists.

p=reject: full enforcement

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

Failing mail is refused. Microsoft 365 rejects it during the SMTP conversation with a 550 5.7.1, and Gmail returns its 550 5.7.26 (see 550 5.7.26: unauthenticated email is not accepted). This is the policy that actually makes spoofing your domain useless at receivers that honor it.

It's also the policy that will bounce your own invoices if your billing system isn't aligned.

"Asks," not "commands"

Receivers apply your policy at their discretion. RFC 9989 goes further than the old spec here: it says mail receivers "MUST NOT reject incoming messages solely on the basis of a 'p=reject' policy," and that without additional analysis they should treat such mail as if the policy were quarantine. Large receivers weigh DMARC alongside their own reputation and content signals.

Two practical consequences:

• Don't expect p=reject to produce identical behavior everywhere. Some failing mail will be junked rather than bounced, and some receivers override policy for mail they recognize as legitimately forwarded.
• Don't treat the absence of bounces as proof that everything passes. Read the reports.

Subdomains: sp and np

Your policy covers more than the domain itself:

• sp sets the policy for existing subdomains. If it's absent, subdomains get p.
• np (new in RFC 9989) sets the policy for subdomains that don't exist in DNS. If it's absent, receivers use sp, then p.

A common pattern while you're still fixing things: p=reject on the organizational domain once it's clean, with sp held at a lower level for a subdomain you're still sorting out. Better still, give a messy subdomain its own DMARC record. np=reject is worth adding once you're at enforcement, since spoofers like to invent plausible subdomains like billing-alerts.example.com.

pct is retired; t is its replacement

The old pct tag let you apply the policy to a percentage of failing mail (pct=25). RFC 9989 retired it. The new t tag is a simple test switch: with t=y, receivers apply your policy one level lower, so p=reject; t=y is treated as quarantine and p=quarantine; t=y as none. It has no effect on reporting.

Google's and Microsoft's own setup guides still describe ramping with pct, and receivers that implemented it may keep honoring it for a while. If your record has pct, it isn't broken. When you next edit the record, use t=y for a trial step instead of a percentage.

How to get to p=reject without breaking your mail

1. Publish p=none with a rua address and let reports accumulate. Give it long enough to catch monthly and quarterly sends: invoices, statements, renewal notices. The spec says getting authentication right can take "many months of consuming DMARC aggregate reports" for complex organizations.
2. Inventory every source in the reports. How to read DMARC aggregate reports covers what to look for.
3. Fix each legitimate source until it passes with aligned DKIM, and ideally aligned SPF as a backup. The usual problem is a service signing with its own domain instead of yours; DMARC fail: why it fails and how to fix it walks through it, and DKIM fail covers signatures that break in transit.
4. Move to p=quarantine (or p=reject; t=y, which receivers treat as quarantine). Watch the reports for legitimate mail that's now failing, and watch the helpdesk for "I never got your email."
5. Move to p=reject once quarantine has run clean through at least one full billing cycle.
6. Add np=reject and decide what sp should be.
7. Keep reading reports. Enforcement isn't a finish line. A new tool added next quarter without custom DKIM will fail on day one.

If you want a correctly formed record for each stage, the DMARC record generator builds one, and the SPF, DKIM and DMARC checker confirms what you've published.

Domains with people on mailing lists

If your domain is used by people who post to mailing lists (common for universities, nonprofits and anyone on technical lists), p=reject has a real cost: lists that modify messages break DKIM, and some of your users' posts will bounce or be dropped at other subscribers. RFC 9989 says such domains "SHOULD NOT" publish p=reject, and if they do, should spend at least a month at none and a similar period at quarantine first.

Many organizations handle this by keeping marketing and transactional mail on subdomains at p=reject while the main user domain sits at quarantine. Whether that trade-off is worth it depends on how much spoofing you're seeing.

Is p=none "bad"?

No. No mailbox provider penalizes you for publishing p=none, and it meets the bulk sender requirements. The problem is staying there when your reports show someone spoofing you, or when you've fixed everything and simply never got around to tightening. Monitoring forever means watching abuse of your domain without doing anything about it.

When to get help

If your reports show legitimate sources you can't identify, or you're about to flip a large or messy domain to reject and want someone to check the reports first, it's worth getting a second set of eyes.

FAQ

Which DMARC policy should I use?

Start with p=none and a rua address. Move to p=quarantine once every legitimate source passes, then to p=reject. Most domains that send mail should end up at reject.

Does p=reject improve deliverability?

Not directly. It protects your domain from spoofing, which protects your reputation, but providers don't hand out inbox placement for a stricter policy. Passing DMARC matters more than the policy level.

How long should I stay at p=none?

Long enough to see every legitimate sender in your reports, including the ones that only send monthly or quarterly. For a simple domain that can be a few weeks; for a large organization with many tools it can be months.

What's the difference between quarantine and reject for the recipient?

With quarantine, failing mail usually still arrives, in the spam folder. With reject, it never arrives at all, and the sender gets a bounce.