Inboxpass All guides

Guides

DMARC policy: p=none vs quarantine vs reject

22 October 2026

The DMARC policy tells receivers what to do with mail that fails DMARC on your domain. p=none asks for nothing, so you only get reports. p=quarantine asks them to treat failures as suspicious, which usually means the spam folder. p=reject asks them to refuse failures outright. Start at none, and move up only when your reports show every legitimate sender passing.

What each policy asks for

The policy lives in the p tag of the TXT record at _dmarc.yourdomain.com. DMARC was first published as RFC 7489. In May 2026 it was replaced by RFC 9989, which keeps the same three values.

p=none

RFC 7489 says the domain owner “requests no specific action be taken regarding delivery of messages.” Mail that fails is handled as if you had no DMARC record, and the receiver records the result in its reports. Google’s DMARC setup page puts it simply: deliver the message and log it in the daily report.

That makes none a monitoring mode. It does not stop anyone from sending as you. It does meet the Gmail and Yahoo bulk sender rules, which require a DMARC record but accept p=none.

p=quarantine

Mail that fails should be treated as suspicious. RFC 7489 lists what that can mean, depending on the receiver: place it in the spam folder, scrutinize it more closely, or flag it. Google says quarantine sends failing mail to the recipient’s spam folder. Microsoft’s DMARC configuration article says Microsoft 365 sends inbound failures to the Junk Email folder by default.

The recipient can still find a quarantined message. That is the point of the middle step: a mistake costs you a spam-folder delivery, not a lost message.

p=reject

Mail that fails should be refused. Google says a rejected message usually bounces back to the sender, so it never reaches the recipient at all. Microsoft 365 rejects with 550 5.7.1 and writes action=oreject in the Authentication-Results header.

This is the setting that actually stops spoofing of your exact domain. It is also the one that hurts when a legitimate sender is not set up, because its mail disappears instead of landing in spam.

Receivers still make the final call

The policy is a request. RFC 7489 says receivers may deviate from it, and that final disposition is always a matter of local policy. RFC 9989 goes further: receivers should not reject messages solely because of a published reject policy, and should use other information to avoid harming legitimate mail. So a p=reject domain can still see a failing message delivered, often a forwarded one, and a p=none domain can still see failing mail filtered for other reasons.

Your aggregate reports show what each receiver did. The disposition field and the optional reason field explain it, as covered in how to read a DMARC report.

When to move up

Google, Microsoft, and the RFC agree on the order: monitor first, fix what the reports show, then enforce. RFC 9989 section 5.1 puts it as a list of steps for domain owners. Publish SPF and DKIM on aligned domains. Set up a mailbox for reports. Publish p=none with rua. Collect and read reports. Fix every legitimate stream that fails. It says those problems must be addressed before you publish an enforcement policy.

Stage 1: p=none with reports

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

Google’s recommended rollout says to keep this for at least a week, because a week is usually enough for the daily reports to cover all your mail streams. If you send a monthly newsletter or a quarterly invoice run, wait until those have gone out and shown up in a report.

Move on when every source in the reports is either:

If you see your own newsletter tool failing alignment, that is a fix to make now, not a reason to wait longer. Usually it means turning on DKIM for your domain inside that tool.

Stage 2: quarantine, maybe for a share of mail

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@example.com

The pct tag applies the policy to a percentage of failing mail. Google suggests starting around 10% for a small organization and 1% for a large one, then raising it over time while you keep reading reports. Microsoft suggests steps of 10, 25, 50, 75, and 100. Under RFC 7489, mail that falls outside the percentage gets the next weaker treatment, so quarantine at 10% leaves the other 90% handled normally.

A note on pct: RFC 9989 removed it. The new standard defines a t=y testing flag instead, which asks receivers to apply one step below the published policy (reject acts like quarantine, quarantine acts like none), and says unknown tags must be ignored. Google’s and Microsoft’s rollout pages, both updated in 2026, still document pct, so you will see it in the wild for a while. For a small domain the simple path works fine: skip partial percentages and go straight to p=quarantine once the reports are clean.

Stage 3: reject

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

Neither Google nor Microsoft gives a fixed waiting period. Both say to move when the reports support it. A sensible test: a few weeks at full quarantine with no legitimate source in the failure rows, and no complaints from customers about missing mail.

Who should stop at quarantine

Not every domain needs to reach reject. RFC 9989 section 7.4 warns that p=reject can cause problems for indirect mail flows such as alumni forwarders, role-based aliases, and mailing lists, because those flows can break SPF and DKIM on the way through. If your staff post to mailing lists from the company domain, a reject policy can get their posts bounced at some list members’ providers.

For a store or business that sends from a handful of services and does not post to lists, reject is usually reachable. For a domain with many people using it in many ways, quarantine at 100% protects most of what reject would, with a softer failure mode.

Subdomains and parked domains

Microsoft recommends doing subdomains in order of increasing volume and complexity, and saving the parent domain for last.

Policies and other requirements

Moving back down

If you tighten the policy and something breaks, lower it. Edit the TXT record back to none, fix the sender, and try again. Receivers cache DNS for the record’s TTL, so the change can take time to reach everyone. Google’s SPF and DKIM pages say record changes can take up to 48 hours to take effect. Nothing about DMARC penalizes a domain for stepping back while it fixes a sender.

Sources