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

The policy is the p= value in your DMARC record. With it, you ask receivers, the mail servers at Gmail, Outlook and the rest, how to handle mail that has your domain in the From address and fails both SPF and DKIM alignment. You can choose none, quarantine or reject.

Start with p=none and a rua address. Delivery stays the same, and receivers start sending you reports. The reports list the mail that fails, which is the mail a stricter policy would catch.

Publish that as a TXT record at _dmarc.example.com, with your own domain and address in place of the examples. For every step of publishing and checking the record, see the DMARC setup guide.

What Gmail and Microsoft 365 do with each value

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

Receiver overrides

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

In Microsoft 365, honouring the sender's DMARC policy is a setting in the anti-phishing policy. It's on by default, and admins can turn it off or pick a different action for each value. An admin who receives real mail that fails DMARC, from a forwarder or a mailing list, can add an exception for that source and leave your policy in force for everyone else.

Your aggregate reports show what each receiver did. For each sending source, an aggregate report gives a disposition of none, quarantine or reject. A disposition softer than your policy means the receiver overrode it, and some receivers give the reason in the report.

p=none

Google, Yahoo and Microsoft all count 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 bulk senders for at least p=none, and Microsoft asks the same of bulk senders to Outlook. For the bounce Outlook sends when a domain misses that requirement, see the 550 5.7.515 page.

With p=none you get the reports. Gmail, Yahoo, Microsoft and most other large receivers send a daily summary to the rua address. It lists each source that sent mail as your domain, how much it sent, and whether it passed. From that list you can find the forgotten invoice app before a stricter policy sends its mail to spam.

p=none doesn't protect your domain. 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

With p=quarantine, you ask the receiver to accept the message and file it as spam or junk. Gmail puts it in the spam folder. Microsoft 365 holds it in quarantine by default, and an admin can send it to Junk Email instead.

The receiver sends no bounce, so the sender doesn't find out. The recipient doesn't see the message unless they check the spam folder, or the quarantine in Microsoft 365. Mail from a real sender that fails under quarantine can go unnoticed for weeks. You'll find it in the reports, as a source you recognise with a quarantine disposition.

Quarantine is the usual middle step. It keeps forged mail out of the inbox, and a mistake costs you a message in spam instead of a bounce. To get a real sender out of spam, follow the quarantined email guide, which also shows what the recipient sees.

p=reject

With p=reject, you ask the receiver to refuse the message during the SMTP conversation. Google's page says the receiving server usually sends a bounce back. Microsoft 365 answers with 550 5.7.1, and the message never lands in any folder.

The sending server gets a bounce, so the sender finds out. A forger gets nothing through. A real platform you forgot gets a bounce for every message too, so you hear about the problem the same day. If you're the sender who got that bounce, see the p=reject bounce page.

End at p=reject. It's the only value that stops a forged message reaching a person. The guide to moving to p=reject lists the checks to run before each step, so you get there without losing mail.

Subdomains: the sp and np tags

A DMARC record at example.com covers every subdomain that has no record of its own. You can set a different policy with sp=, for subdomains that exist, and np=, for subdomains that don't exist in DNS at all. RFC 9989 section 4.7 defines both.

With that record, you ask receivers to quarantine failures on the main domain while you tune it. You also ask them to reject failures on real subdomains that don't send mail, and mail from any subdomain someone invented to forge you. Give a subdomain that sends mail through a platform its own record at _dmarc.that.subdomain. That record replaces all three tags for that name.

For a parked domain that sends no mail at all, Microsoft recommends this record:

The pct and t tags

With pct=, you ask receivers to apply the policy to a percentage of failing messages and to 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 move to a stricter policy in stages, publish the new policy with pct=25 and t=y. Gmail, Outlook and Yahoo apply pct and ignore t=y. Receivers that follow RFC 9989 read t=y instead. If the record has sp=quarantine, leave out pct and t=y, because both tags loosen the subdomain policy too. After three days of reports with none of your own mail failing, raise pct to 50. After three more, remove pct and t=y. Plan for the full policy from the first day, because receivers have always applied pct unevenly.

Microsoft 365 shows which messages were in the sample. It adds action=pct.quarantine or action=pct.reject to the Authentication-Results header of each one.

Steps from p=none to p=reject

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 pass with alignment. Each source of yours in the reports needs SPF or DKIM passing for your domain. Make the fix in the platform's settings, such as turning on DKIM signing with your domain.
3. Move to p=quarantine once the reports show only forgeries failing. Watch for sources you recognise with a quarantine disposition.
4. Move to p=reject after two weeks at full quarantine with none of your own mail failing. Do subdomains and low-volume domains first, and the main domain last.

Step 2 goes wrong most often, because a platform that sends once a month can be missing from two weeks of reports. 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.