DMARC policy: what none, quarantine and reject do at the receiver

The policy is the p= value in your DMARC record. It's your request to receivers about mail that carries your domain in the From address and fails both SPF and DKIM alignment. There are three values, and each one asks for something different.

Which policy should I start with? p=none, with a rua address. It changes nothing about delivery and it starts the reports that tell you what the other two would have done.

Publish that as a TXT record at _dmarc.example.com, replacing the domain and the address with your own. Our setup guide covers the record end to end. This page is about what each policy value does once it's published.

Three values, and what each receiver does with them

The middle column comes from RFC 9989, the DMARC standard, which defines each value in terms of what the domain owner considers the failure to mean. The Gmail column is from Google's DMARC setup page. The Microsoft column is from Microsoft's DMARC documentation, with its default anti-phishing setting to honour the sender's policy turned on.

A receiver may not do what you asked

The standard is explicit. RFC 9989's introduction says a receiver can choose to honour the domain owner's requested handling but is not required to. A policy is a request, and each receiver has its own local rules on top of it.

Microsoft 365 makes that a setting. Its anti-phishing policy has an option to honour the sender's DMARC policy, on by default, and admins can turn it off or pick a different action for each value. A mail admin who receives legitimate mail that fails DMARC, from a forwarder or a mailing list, can add an exception for that source rather than ignore your policy for everyone.

Your aggregate reports show what happened. Each row carries a disposition of none, quarantine or reject. When the disposition is softer than your policy, the receiver overrode it, and the report may say why. Our report walkthrough covers that field.

p=none is a working policy

Every major receiver treats a record with p=none as DMARC in place. Google's sender guidelines say a bulk sender's enforcement policy can be set to none. Yahoo asks for at least p=none. Microsoft's Outlook requirement is the same, and our 550 5.7.515 page covers what happens without it.

What p=none gives you is the reports. Every receiver that supports DMARC sends a daily summary to the rua address showing each source that used your domain, how much it sent, and whether it passed. That list is how you find the forgotten invoice app before a stricter policy sends its mail to spam.

What it doesn't give you is protection. A forged message with your domain in the From line passes through untouched. Stay on p=none only as long as it takes to get every real sender passing.

p=quarantine files the failure as spam

Quarantine asks the receiver to accept the message and file it as spam or junk. Gmail puts it in the spam folder. Microsoft 365 puts it in Junk Email by default, and an admin can route it to the quarantine store instead.

Nobody is told. The sender gets no bounce, and the recipient sees nothing unless they open the spam folder. A real sender that fails under quarantine can go weeks without anyone noticing. Only the reports show it, as rows with a quarantine disposition from a source you recognise.

That silence is why quarantine is the middle step. It stops forged mail reaching the inbox while the cost of a mistake is a message in spam rather than a bounce. Our quarantined email guide covers what a recipient sees and how to get a real sender out.

p=reject refuses the message during delivery

Reject asks the receiver to refuse the message in the SMTP conversation. Google says the receiving server usually sends a bounce back. Microsoft 365 answers with 550 5.7.1 and the message never lands anywhere.

The sender is told. That's the strength and the risk. A forger gets nothing through. A real platform you forgot gets a bounce for every message, which is loud enough that someone finds out the same day. Our p=reject bounce page covers that bounce from the sender's side.

Reject is where a domain should end up. It's the only value that stops a forged message reaching a person. Our p=reject guide covers the checks to run before each step so you get there without losing mail.

Subdomains follow the parent unless you say otherwise

A DMARC record at example.com covers every subdomain without a record of its own. Two tags change that. sp= sets the policy for subdomains that exist, and np= sets it for subdomains that don't exist in DNS at all. RFC 9989 section 4.7 defines both.

That record quarantines failures on the main domain while it's still being tuned, rejects them on real subdomains that don't send mail, and rejects anything from a subdomain that was invented for the purpose. A subdomain that sends mail through a platform gets its own record at _dmarc.that.subdomain, which overrides all three tags for that name.

A domain that sends no mail at all gets the shortest record. Microsoft recommends exactly this for parked domains:

pct and the t tag: testing a stricter policy first

pct= asks receivers to apply the policy to a percentage of failing messages and treat the rest under the next softer value. Google and Microsoft both document it, and Microsoft suggests stepping through 10, 25, 50, 75 and 100 on the way to a stricter policy. The default is 100.

RFC 9989 removed pct from the standard and replaced it with a test flag. t=y marks the record as testing, and reports still arrive. Receivers that follow RFC 9989 apply one level below the published policy, so p=reject acts as p=quarantine and p=quarantine as p=none. Receivers still on RFC 7489 ignore t=y and apply the policy in full.

To test a stricter policy first, publish it with t=y and leave pct out. Plan for the full policy from the first day, because receivers on RFC 7489 apply it in full. Remove t=y once the reports show none of your own mail failing.

The reports show which was applied. Microsoft marks sampled messages with action=pct.quarantine or action=pct.reject in the Authentication-Results header, so a message that was in the sample can be told from one that wasn't.

Move up one step at a time

1. Publish p=none with a rua address and wait for reports from every receiver your mail reaches. A week covers the weekly sends. A month covers the monthly invoices.
2. Get every real source to an aligned pass. Each row in the reports that's yours needs SPF or DKIM passing for your domain. Fix the platform, not the record.
3. Move to p=quarantine once the reports show only forgeries failing. Watch for rows with a quarantine disposition from a source you recognise.
4. Move to p=reject once quarantine has run clean. Do subdomains and low-volume domains first, and the main domain last.

The step that goes wrong is the second one, because a source that fails today may not send again until next month. On a paid plan we email you the first time a source fails DMARC. The weekly digest shows the reported results by source, so a forgotten platform shows up before you tighten the policy. Your first domain is free.