Skip to content
DMARC Done
Fix my DMARC
Free checkHow it worksPricingGuidesBlogLog in

dmarc

DMARC quarantine vs reject: which to use and in what order

What p=quarantine and p=reject do, the safe order from none to reject, how reports decide each step, and what the new DMARC standard changed about pct.

DMARC Done team · 5 October 2026 · 6 min read

Once your domain has a DMARC record, the next question is which policy to use. p=quarantine and p=reject both enforce DMARC, but they fail differently, and the order you use them in decides whether you lose real email along the way.

The three policies in one table

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a TXT record at _dmarc.yourdomain.com. Its p= tag tells receivers what you want done with mail that claims to be from your domain but fails authentication.

Policy What you are asking for What Microsoft 365 does with failing mail
p=none No action. Monitoring only. No DMARC-specific action
p=quarantine Treat failing mail as suspicious Delivers it to the Junk Email folder (admins can choose quarantine)
p=reject Refuse failing mail Rejects it during delivery with error 550 5.7.1

The middle column paraphrases the definitions in the DMARC standard. The right column is Microsoft’s documented behavior when the receiving organization keeps its recommended “Honor DMARC record policy” setting on. Other receivers behave similarly, but each makes its own final decision.

Quarantine: a safety net with a hole in it

With p=quarantine, mail that fails DMARC usually ends up in the recipient’s spam or junk folder.

The good part: if you missed a legitimate sender, its mail is not lost. Someone can still find your invoice in the spam folder, and your DMARC reports will show the failure so you can fix it.

The hole: spoofed mail also lands in the spam folder, where a recipient can still find it, open it and act on it. Quarantine makes impersonation much less effective, but it does not stop it.

Reject: the finish line

With p=reject, the receiving server refuses the message during delivery. It never reaches any folder. The sending server gets a bounce.

That bounce matters for legitimate mail too. If a forgotten service of yours sends mail that fails DMARC, its messages are refused, and nobody on the receiving side ever sees them. That is why you only move to reject once your reports show your own mail passing.

Microsoft’s guidance is clear about the destination: “The goal is to get to a p=reject DMARC policy for all of your custom domains and subdomains.”

Plain-English takeaway: Quarantine sends fake mail to spam, where it can still be found. Reject stops it at the door. Use quarantine as a stepping stone and reject as the goal, and let your reports tell you when to step.

The safe order: none, quarantine, reject

Microsoft, Google and Zoho all describe the same rollout: start at p=none, move to p=quarantine, then move to p=reject, checking reports at each stage. Here is what each stage is for.

Stage 1: p=none with reports

Publish a record like this:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1

The rua address receives aggregate reports, usually once a day from each large receiver. According to Microsoft, each report lists the IP addresses of servers sending mail as your domain, whether they passed or failed DMARC, and what the receiver did with the mail.

Use this stage to build a list of every service that sends as you, and fix each one so it passes SPF or DKIM with your domain. If you have not published a record yet, start with no DMARC record found.

Stage 2: p=quarantine

Move here when your legitimate mail passes consistently. Then keep reading reports. New failures from your own services still land in spam rather than bouncing, which gives you time to fix them.

Stage 3: p=reject

Move here when quarantine has run cleanly and nothing legitimate is being quarantined. Keep the rua address in the record. Next year someone will sign up for a new tool without telling you, and the reports are how you find out.

How long at each stage?

No standard sets a duration. Readiness depends on your data, not the calendar. M3AAWG, an industry anti-abuse group, recommends treating p=none and partial enforcement “only … as transitional states, with the goal of removing them as quickly as possible.”

For reference, this is the rule we use in our own service. We recommend quarantine only after at least 14 days of reports, received on at least 5 different days, with every service you marked as yours passing DMARC on at least 98% of its mail over the last 7 days. We recommend reject after at least 7 more days at quarantine, with less than 1% of your own mail quarantined. Very low-volume domains wait longer, because a few messages a week prove little.

Reports have gaps

Not every receiver sends aggregate reports. Microsoft says to “Set realistic expectations” and estimates that coverage “is typically 70-90% of total mail volume.” Microsoft 365 also never sends failure reports (ruf), even if you ask for them.

In practice, a service you use rarely, such as a yearly renewal email, may not show up in two weeks of reports. Before moving to reject, ask the people who run billing, sales and support which tools send email for them.

pct, and what the new DMARC standard changed

For years, the pct tag let you apply a policy to only part of your failing mail, for example p=quarantine; pct=25. Under the original DMARC specification, RFC 7489, mail outside that percentage got the next-lower treatment: normal filtering instead of quarantine, or quarantine instead of reject. Microsoft’s and Google’s guides still suggest stepping pct up from a low value to 100.

That has changed. The DMARC revision known as DMARCbis was published in May 2026 as RFC 9989, a Proposed Standard that replaces RFC 7489. In the IANA registry of DMARC tags, pct is now marked “historic”, along with the rarely used rf and ri tags.

In place of pct, RFC 9989 adds a test-mode tag, t:

  • t=y asks receivers to apply the next-lower policy. With p=quarantine; t=y, failing mail is treated as none. With p=reject; t=y, it is treated as quarantine.
  • RFC 9989 states that this tag “does not affect the generation of DMARC reports”, so your reports keep flowing.
  • The default is t=n, meaning the policy applies in full.

RFC 9989 also adds np, a policy for subdomains that do not exist, and psd, a flag for public suffix domains, which most businesses never need.

What this means for you:

  1. Do not build a rollout around partial pct values like 25 or 50. The tag is no longer part of the standard.
  2. If you want a cautious step before full enforcement, t=y is the standard way to say “test this policy”. RFC 9989 is new and receivers update their software at their own pace. A receiver that still follows RFC 7489 ignores tags it does not know, so for that receiver t=y does nothing and the policy applies in full. Do not publish a policy you are not ready for and rely on t=y alone.
  3. Keep using rua reports as the deciding evidence. That has not changed.

Subdomains

Your DMARC record also covers subdomains that do not have their own record. The sp tag sets a different policy for subdomains if you need one. If you send marketing mail from a subdomain such as news.yourdomain.com, it needs its own SPF and DKIM, and it falls under your main DMARC policy unless it has its own _dmarc record. Check it in the reports before you enforce.

Where to start

Run the free checker at /check?d=yourdomain.com to see your current policy, whether reports are set up, and whether SPF and DKIM are ready for enforcement. If SPF shows too many lookups, fix that first: see SPF too many DNS lookups.

If you want someone to read the reports, chase down every sender and make each step for you, see pricing. We take the domain to p=reject, or refund you in full if we do not get there within 60 days.

Sources

See where your domain stands in 10 seconds

Free. No signup. We do not store the domains you check.