DMARC policy none quarantine reject: what receivers do with each, and when to move up

A DMARC policy is the p= tag in a domain’s DMARC record: the instruction a receiving server reads when a message claiming to be from that domain fails authentication. Searching for “DMARC policy none quarantine reject” usually comes down to one question: which of the three values should I publish, and when? The short answer is all three, in that order, at a pace your reports justify.

The record lives at _dmarc. followed by your domain, as a TXT record. A receiver that sees a message with your domain in the From header looks that record up, checks whether SPF or DKIM passed with an aligned domain, and if neither did, applies the policy. It then counts what it saw and, once a day, mails you a summary. That loop — policy out, reports back — is the whole design, and it is why the value you publish first is the one that does nothing.

This post assumes you know what SPF, DKIM and alignment are. The three-records explainer covers those, and the alignment entry in the glossary is the one-paragraph version. Here we stay on the policy value, the tags around it, and the reports that tell you when to move up.

The three values are a ladder, and every rung is defined in RFC 7489 as a request rather than a command: a receiver may apply local policy over yours. In practice the large mailbox providers honour the request, and the differences between the rungs are exactly what the table says.

Two things the table hides. First, a p=none record is not nothing to a receiver: Google’s sender guidelines require bulk senders to publish a DMARC record and say in the same breath that the enforcement policy can be set to none. Publishing it is the requirement; the value is your choice. Second, p=reject is the only value that stops a phishing message pretending to be your invoices team. Quarantine puts it in a folder people still open.

The policy tag is rarely published alone. Four other tags decide how much of your mail it covers, what happens to subdomains, and whether you ever hear about any of it.

_dmarc.acme.example.   TXT   "v=DMARC1; p=quarantine; pct=25; sp=reject; rua=mailto:dmarc@acme.example"

Two tags this post leaves at their defaults: adkim and aspf, which switch alignment from relaxed to strict. Relaxed lets a subdomain align with its parent, which is the shape nearly every sender has once the return path is on a subdomain. Strict is for a domain that wants exactly one sending identity and knows it has one.

An aggregate report is a gzipped XML file, one per receiver per day, listing every source IP address that sent mail with your domain in the From header, how many messages it sent, and what the receiver decided. The XML is not friendly, but the shape is small enough to read once and understand forever.

<record>  <row>    <source_ip>192.0.2.10</source_ip>    <count>142</count>    <policy_evaluated>      <disposition>none</disposition>      <dkim>pass</dkim>      <spf>fail</spf>    </policy_evaluated>  </row>  <identifiers>    <header_from>acme.example</header_from>  </identifiers>  <auth_results>    <dkim>      <domain>acme.example</domain>      <selector>rasket</selector>      <result>pass</result>    </dkim>    <spf>      <domain>mail.example.net</domain>      <result>pass</result>    </spf>  </auth_results></record>

Each <record> is one source. <row> holds the IP, the count and the verdict. <policy_evaluated> is the DMARC view: dkim and spf here are pass or fail after alignment, and disposition is what the receiver did. <auth_results> is the raw view: what SPF and DKIM themselves said, and for which domain.

The record above is the one worth learning to recognise. Raw SPF passed, but for mail.example.net, which does not align with acme.example, so DMARC counts SPF as a fail. DKIM passed for acme.example under the rasket selector, which aligns, so the message passes DMARC on DKIM alone. That is an unaligned pass: authentication worked, alignment did not, and one of the two legs is carrying the whole weight. It is fine today. It becomes a failure the moment that DKIM signature breaks in transit.

• Both aligned: healthy. Either leg can fail and the message still passes.
• One aligned: passes, but fragile. Find out why the other leg does not align and fix it before moving up.
• Neither aligned, but you recognise the source: a legitimate stream that will be quarantined or rejected when you move up. This is what p=none is for finding.
• Neither aligned, unknown source: spoofing, or a system nobody remembered. Check before you assume.

Expect reports to arrive daily from each receiver that saw your mail, usually within a day or two of the record going live. Failure reports, if any come, arrive rarely and per message. A parsing service turns the daily files into a table by source; if your volume is small, a script that unzips the attachments and prints source_ip, count and the two policy_evaluated results is enough to start.

What a week of reports should show before you move up: every source you recognise with at least one aligned leg on every day it sent, no legitimate source with both legs failing, and a short tail of low-volume unknowns that are either forwarders or spoofing. Volume matters here. A stream that sends once a month has not been seen until it has sent, so an inventory that includes the monthly invoice run is worth more than a long wait.

The order below is the one RFC 7489 anticipates and the one that has never cost anyone a legitimate message when followed. Each step converts something you would only read about into something that affects delivery, so the reports gate every step.

1. Inventory your streams. Write down everything that sends with your domain in the From header: the application, the support desk, the CRM, the billing system, the newsletter tool, the office mail. Include the ones on subdomains. You will miss some, which is what the next step is for.
2. Publish p=none with rua. One record at _dmarc.your domain, no pct, no sp, a rua address you will actually read. Nothing changes for anyone. Wait a week, then compare what the reports show against the inventory.
3. Fix alignment per stream. For every legitimate source, get at least one leg aligned. For a sending service that means signing with your domain and putting the return path on a subdomain of it; for office mail it usually means an SPF include and a DKIM key the provider issues. Repeat until every known stream shows an aligned pass. Retire the streams nobody could identify.
4. Quarantine at pct=25, then 100. Change to p=quarantine; pct=25. Watch the reports and your support inbox for a week or two. If nothing legitimate appears with a quarantine disposition, raise pct to 50, then remove it. Stay at full quarantine for a few weeks.
5. Reject. Change to p=reject. If quarantine ran clean, this changes nothing for legitimate mail and everything for impersonation. Add sp=reject at the same time if you have not already.
6. Keep reading. A new vendor, a marketing tool someone signed up for, a migration that drops a DKIM record: each one shows up in the reports first. Reject is a destination for the record and a starting point for the habit.

Once the obvious streams are fixed, the failures that remain fall into four groups. RFC 7960 catalogues them in detail; this is the version you need to recognise them in a report.