The DMARC policy mix across three editions: none, quarantine, reject

You published a DMARC record, you set p=none because the setup guide said to start there, and nothing has changed since. Receivers still deliver anything that claims to come from your domain, because p=none instructs them to deliver and report. The September 2026 census puts you in a large crowd: about half of the DMARC records it observed carry that same policy, and the same was true in July and in August.

How the three editions are compared

The comparison below runs over the 1,244 TLDs present in all three lakes, July, August and September 2026. The number of domains inside a TLD moves from one edition to the next because the source lists differ, so this piece compares the mix inside the records that were observed, with each edition’s own record count as the denominator, and leaves the count of domains publishing a record alone. The method page, what we will and will not compare, sets out that rule and the others this track follows.

A share of published records tells you what the people who published chose to instruct receivers to do, and a TLD gaining or losing a few hundred thousand names between editions doesn’t disturb it.

The mix, July to September 2026

Shares are of published DMARC records in the same edition: 74,902,714 records in July, 79,014,727 in August and 80,986,763 in September. Those record counts are denominators only, since the cohort’s domain count moved as well.

The three rows don’t add to 100 in any column. The remainder is records whose p= value doesn’t parse as one of the three. That’s a separate problem with its own fix, and it stays out of this ledger.

Reading three points without drawing a line

Quarantine edged up across the three editions and reject edged down, while none barely moved. The biggest movement in any row is a fraction of a percentage point. A shift that small comes from which domains happened to answer that month as readily as from anyone changing a record. The table describes a mix that has stayed roughly where it was.

Three monthly points are enough to show a stable shape of published DMARC policy and too few to forecast anything: roughly half of the records receivers see are set to do nothing, roughly a quarter ask for quarantine, and a bit over a fifth ask for outright rejection. If your record is one of that half, the rest of this piece is about moving it.

What p=none tells a receiver

A record at p=none looks like this:

v=DMARC1; p=none; rua=mailto:[email protected]

When a receiver gets a message claiming to be from your domain, it checks whether the message passed SPF or DKIM with a domain that aligns with the visible From address. If neither passes, it consults your p= value. With p=none the answer is deliver as normal, then send an aggregate report to the rua address once a day summarising what it saw. The message lands in the inbox with your name on it, the same as it would have done before you published anything.

If your record has no rua tag at all, you don’t get the reports either. You’ve published a policy that changes no delivery decision and produces no information. A great many records sit in that state years after someone added them to tick a box on a supplier questionnaire.

The value to look at on your own domain is the p= tag, and it takes a few seconds to read.

What quarantine and reject tell a receiver

p=quarantine tells the receiver to treat a failing message as suspicious. In practice that means the spam or junk folder for most mailbox providers, and a raised spam score at gateways that don’t have a folder to put it in. The message still exists and the recipient can find it, so a forged invoice can be opened by someone who goes looking.

p=reject tells the receiver to refuse the message during the SMTP conversation, before it’s stored anywhere. The forger’s server gets a 5xx response and the recipient sees nothing, so there’s nothing for them to open or act on. This is the policy that stops someone using your domain to send a payment-change email to your customers, and it’s the reason can someone spoof my domain comes down to what your p= tag says.

Both policies accept a pct= tag that applies the policy to a percentage of failing messages; that tag is what makes a staged rollout possible. Both also apply to subdomains unless you set sp= separately, and that catches people out when a forgotten subdomain is still sending through an old relay.

Moving off none without losing your own mail

The reason so many records stay at p=none is a reasonable fear: tighten the policy and some legitimate mail stops arriving. That fear is well founded if you skip the reporting stage, and unfounded if you don’t. The move is a sequence, with the reports first, because they show you which senders will fail before you tighten anything.

Start by adding rua=mailto: to your existing record if it isn’t there, pointed at a mailbox or a report processor you’ll read. Leave p=none in place for a few weeks and watch which sending sources fail alignment. You’ll find your own mail server, your newsletter tool, your CRM, your invoicing system, a ticketing platform someone signed up for in 2021, and often a source nobody in the business recognises at all.

For each source you recognise, make it pass. That usually means getting the sender to sign with DKIM using a selector under your domain, or adding its outbound range to your SPF record, and confirming the aligned domain matches your From header. Sources you don’t recognise are either forgers or a departed contractor’s tool, and neither gets a fix.

Once the reports show your legitimate sources passing, change the record to p=quarantine; pct=10 and watch for another cycle of reports. Raise the percentage in steps until you’re at pct=100 with no legitimate failures. Then move to p=reject, again in steps if you’d rather, and keep the rua address in place permanently, because senders you add next year will need the same check.

The DMARC pillar walks through each tag with worked record values, and the free scan reads your current record and tells you which stage you’re at right now. That’s the point to start from: read the p= value on your own domain, and if it says none, add the reporting address and put the first policy change in your calendar for a few weeks out.

Figures as of 5 September 2026, from the September 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.