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

A DMARC (Domain-based Message Authentication, Reporting and Conformance) record at p=none leaves delivery as it was. Receivers still deliver anything that claims to come from your domain, because p=none instructs them to deliver and report. About half of the DMARC records the October 2026 census observed carry that policy, and the same was true in July, August and September.

How the four editions are compared

The comparison below runs over the 1,243 TLDs (Top-Level Domains) present in all four lakes, July, August, September and October 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.

One part of the method changed in October. Up to September, names that no longer exist were dropped by a pass before the scan. From October, names that answer NXDOMAIN (Non-Existent Domain) are removed after the scan. A name that doesn’t exist has no DMARC record, so the shares below are still shares of the records each edition observed.

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 October 2026

Shares are of published DMARC records in the same edition: 74,902,714 records in July, 79,014,727 in August, 80,986,763 in September and 85,699,874 in October. 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 four points without drawing a line

By the rule this site applies to trends, every row is flat. The rule needs a move of at least one full percentage point, and no row moves that far across the four editions. October has the lowest p=none share of the four and the highest p=reject share, and both are still less than a point from where they stood in July. A shift that small comes from which domains happened to answer that month as readily as from anyone changing a record.

Four 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:dmarc-reports@example.com

When a receiver gets a message claiming to be from your domain, it checks whether the message passed SPF (Sender Policy Framework) or DKIM (DomainKeys Identified Mail) 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 (Simple Mail Transfer Protocol) 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. 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. Leave the sources you don’t recognise failing, unless someone in the business can account for them.

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 from the defaults.exposed census, data as of 12 October 2026. Census numbers move every month; the current values are on the census data page.