DMARC pct Tag: 476,000 Domains Water Down Enforcement

Q: What does pct mean in a DMARC record?

pct tells receiving mail servers what percentage of authentication-failing messages your published policy applies to, sampled at random. The default is 100. Messages outside the sample get the next policy down: reject falls to quarantine, quarantine falls to none (normal delivery). In the August 2026 census, 476,465 enforcement records set it below 100.

Q: Why would anyone set pct=0?

p=quarantine; pct=0 is a known deliverability trick: some mailing-list software applies sender-rewriting compatibility behaviour based on the policy tag alone, so this record triggers it without quarantining any mail (industry knowledge). But the census found 4,755 records saying p=reject; pct=0, which has no such upside — and all 10,940 zero-percent enforcement records share the same practical property: the enforcement they announce is switched off.

Q: How do I check my own pct setting?

Your DMARC record is public DNS: look up the TXT record at _dmarc.yourdomain and read the tags. No pct tag means 100, which is what a finished deployment should say. Any explicit value below 100 means your enforcement is sampled — and if it has been sitting there longer than a testing window, your record and your actual protection have drifted apart.

Published 2026-08-18

Figures as of 2026-08-16 · methodology v9. This is a recurring report; each edition re-measures the same population so the numbers can be tracked over time. All figures are aggregate — we never publish an individual business’s grade or name an individual registrant’s domain.

The headline: 476,465 domains publish enforcement their own record waters down

Across 75.5 million DMARC records parsed in the August 2026 census, at least 476,465 domains publish an enforcement policy — quarantine or reject — and then weaken it in the same line of text, using a pct value below 100. Another 10,940 of them have turned the dial all the way to zero: a record that reads as enforcement and enforces nothing.

The pct tag is DMARC’s sampling dial. It tells receiving mail servers what percentage of failing messages the published policy should actually apply to. It exists for a good reason: it lets a cautious admin ramp from monitoring to full enforcement in stages. The problem is the ramp has a parking brake, and a measurable population of domains set it years ago and walked away.

Most DMARC coverage — ours included — sorts the world into three buckets: none, quarantine, reject. Our DMARC enforcement report counts those buckets across the graded web. This report looks inside the enforcement buckets at the tag almost nobody audits, because a p=quarantine record at pct=10 is not a quarantine policy. It is a 90%-delivery policy wearing a quarantine label.

Key numbers

476,465 domains publish DMARC enforcement (quarantine or reject) with pct below 100 — 1.4% of the 35.0 million enforcement records parsed in the August 2026 census.
10,940 enforcement records set pct=0 — enforcement fully disabled by the domain’s own record.
90.0% of the watered-down cohort sits at p=quarantine (428,995 domains) — the combination where sampled-out mail falls all the way through to normal delivery.
pct=90 is the most common weakened setting: 218,420 domains, 45.8% of the sub-100 cohort — and 208,867 of them share the exact combination p=quarantine; pct=90; sp=none.
241,605 domains run enforcement at half strength or less (pct ≤ 50) — 50.7% of the weakened cohort.
2,422,718 p=none records carry a pct tag that does nothing at all — on a monitoring policy, the dial is not connected to anything.

What does the DMARC pct tag actually do?

A DMARC record’s p= tag tells receivers what to do with mail that fails authentication: none (deliver, just report), quarantine (spam-folder it), or reject (refuse it). The pct tag, defined alongside the rest of DMARC in RFC 7489 (2015 — industry context, not census data), adds sampling: apply the policy to this percentage of failing messages, chosen at random by the receiver.

The subtle part is what happens to the messages that fall outside the sample. They do not get a free pass to the inbox by definition — they get the next policy down. Under p=reject; pct=50, the unsampled half is treated as quarantine. Under p=quarantine; pct=50, the unsampled half is treated as none: delivered normally, exactly as if the domain published no enforcement at all.

That asymmetry is the whole story of this report. A weakened reject still catches everything one way or another — half refused, half spam-foldered. A weakened quarantine leaks. Every percentage point below 100 on a quarantine policy is a percentage point of spoofed, authentication-failing mail that receivers are instructed to deliver as if nothing were wrong. And 90% of the watered-down cohort is quarantine.

The design intent was a ramp: publish p=quarantine; pct=5, watch your reports for a week, move to 25, then 50, then 100, then repeat at reject. Used that way, pct is one of the more thoughtful pieces of the standard. Our census can’t observe intent. What it can observe is where the dials are set on one day in August 2026 — and a dial that was meant to be turned weekly does not naturally come to rest at 10.

How many domains weaken their own DMARC policy?

Of the 75.5 million DMARC records the census could parse a policy from, 35.0 million publish enforcement. Here is where their dials sit:

Policy	Records parsed	`pct` < 100	Share weakened
p=quarantine	19,129,666	428,995	2.24%
p=reject	15,853,952	47,470	0.30%
All enforcement	34,983,618	476,465	1.36%

Two readings of that table are both true. The optimistic one: 98.6% of enforcement records run at full strength — the vast majority of domains that made it to quarantine or reject either never touched the dial or finished the ramp. The other one: nearly half a million domains sit in a state their own security tooling probably reports as “DMARC enforced,” and quarantine domains are more than seven times more likely than reject domains to be in it.

That gap makes sense once you remember the downgrade rule. Reject publishers tend to be the domains that finished the journey; quarantine is where ramps live — and where ramps stall. (A further 4.7 million enforcement records write pct=100 explicitly. That is harmless: it restates the default.)

Where is the dial actually set?

The distribution of sub-100 values is not smooth. It clusters hard at the round numbers, and one value dominates everything:

`pct` value	Enforcement records	Share of weakened cohort
90	218,420	45.8%
50	52,496	11.0%
25–49	48,964	10.3%
11–24	19,000	4.0%
51–89	14,503	3.0%
91–99	1,937	0.4%
10	63,360	13.3%
1–9	46,845	9.8%
0	10,940	2.3%

Buckets are our grouping of the exact values in the census data; every underlying figure is a per-value count.

The pct=90 spike deserves a closer look. It is not just a popular number — 208,867 of those 218,420 domains publish the identical three-tag combination: p=quarantine; pct=90; sp=none. Fingerprints like that almost never come from two hundred thousand admins independently making the same choice. They come from a template — a hosting panel, a setup wizard, a widely copied tutorial — stamped out at scale. Our census sees the record, not its author, so we can’t attribute it, but the shape is unmistakable: one default, replicated across a fifth of a million domains, each quietly delivering one in ten failing messages and exempting subdomains from enforcement entirely (sp=none — a back door we examine separately).

At the other end, a quarter of the weakened cohort — 121,145 domains — runs at pct=10 or below. At those settings the label and the behaviour have almost nothing to do with each other: a p=quarantine; pct=5 record instructs receivers to spam-folder one failing message in twenty and deliver the other nineteen normally.

pct=0: enforcement in name only

10,940 enforcement records set pct=0. Read literally, that instructs receivers to apply the published policy to nothing: every failing message gets the downgrade treatment, which for the 6,185 quarantine records means full normal delivery, indistinguishable in effect from p=none.

To be fair to some of these publishers: p=quarantine; pct=0 has a life as a deliberate operational trick. Because some mailing-list software checks only the policy tag when deciding whether to rewrite sender addresses, publishing quarantine-at-zero-percent triggers that compatibility behaviour without any mail actually being quarantined — a known technique from deliverability practice (industry knowledge, not something our census can confirm per record). Some fraction of the 10,940 chose this state on purpose.

But the trick only explains quarantine records, and 4,755 of the zero-percent records say p=reject; pct=0 — a configuration with no known operational upside, since the unsampled remainder still lands at quarantine. However the domains got here, the census reading stands: nearly eleven thousand records announce an enforcement policy and then, in the same seventy characters, suspend it.

The dial connected to nothing

The strangest finding in the data is not on the enforcement side at all. 2,422,718 p=none records carry a pct tag. On a monitoring policy, pct is inert — none downgraded is still none, so the tag changes nothing regardless of its value. 2.28 million of these write pct=100, harmless boilerplate probably copied from a generator. But 143,256 publish p=none with a pct below 100 — including 14,705 at pct=0, domains meticulously specifying that zero percent of their mail should receive no enforcement.

The census also caught 57 domains publishing pct=587. The tag takes 0 to 100; receivers ignore an invalid value and fall back to the default. Fifty-seven zones on the public internet have carried an impossible percentage through at least one census round, which tells you exactly how often these records get reread after the day they were written.

None of this inert-tag population is a security hole. It is something more familiar: evidence that DMARC records are written once, by tools or from tutorials, and then not understood by the people who own them. The same copy-paste culture that parks 143 thousand meaningless dials on monitoring records is the culture that parked 208 thousand quarantine records at 90%.

What should the dial say?

For a domain that has finished deploying, the answer is short: nothing. Omit pct entirely — the default is 100 — or state pct=100 if your tooling insists. The tag has one legitimate job, and that job is temporary: a ramp position held for days or weeks while reports confirm nothing legitimate is failing, then raised.

If your record says p=quarantine with any pct below 100 and you can’t name the person currently watching the reports, the ramp has stalled and the honest next step is one of two moves: finish it (raise pct, then move to reject), or accept that you are running partial enforcement and read your record accordingly. What the data argues against is the third state — the one 476,465 domains are in — where the record says one thing, the mail flow does another, and nobody is looking. Checking takes ten seconds: your DMARC record is public, and the dial is right there in the text.

How we measured this

Source: the August 2026 census round (figures as of 2026-08-16, methodology v9). DMARC policy, pct, and sp values were parsed from the census’s stored DNS evidence text for each graded domain’s DMARC record.
Denominator: 75,543,004 DMARC records (a residue of roughly 48,000 carries no readable policy token and counts toward no policy cohort), of which 34,983,618 publish quarantine or reject. Where this report says “domains,” it means one parsed DMARC record per domain.
Floors, not ceilings: the combination table behind this report covers the 200 most common policy/pct/sp combinations. Rarer combinations fall outside it, so the weakened-cohort counts (476,465; 10,940; and the per-value figures) are floors, and the denominators are correspondingly approximate to well under 1%.
First record only: parsing takes the first DMARC record at _dmarc.<domain>. Domains publishing duplicate records (itself an error condition) are represented by one.
Blank means default: records with no pct tag are treated as the RFC 7489 default of 100. Only explicit sub-100 values count toward the weakened cohort.
Published policy, not receiver behaviour: we measure what the record instructs. Individual receivers vary in how faithfully they implement pct sampling; some large providers are known to treat quarantine and reject more strictly or more loosely than the letter of the record (industry knowledge). We make no claim about any specific receiver.
Vantage: DNS queries from our EU measurement infrastructure during the August 2026 round.
Aggregate only. We never name, grade, or publish data about an individual registrant’s domain.

What this means

For IT managers and security teams, the practical consequence is this: a DMARC report from your tooling that says “quarantine enforced” may be telling you something that is technically true and operationally misleading at the same time. If the underlying record carries a pct value below 100, the policy is partial — and in the most common case (quarantine at pct=90), nine in ten spoofed messages are directed to the inbox path exactly as if no enforcement existed. The dashboard green-light is accurate about the record; it is not accurate about the protection.

The 208,867 domains sharing the identical fingerprint p=quarantine; pct=90; sp=none point to a specific operational hazard: configuration tools and hosting panels that pre-fill a “safe-looking” record and then move on. If your domain’s DMARC record was created by a wizard or copied from a template more than a few months ago, checking the actual pct value takes ten seconds and the result will tell you whether the ramp ever moved. A value below 100 that nobody on the current team remembers setting is almost certainly a stalled ramp, not a live testing window.

For business owners, the stakes are direct: an email impersonating your domain to a supplier or customer will pass right through a watered-down quarantine policy on the percentage of messages that fall outside the sample. Fake-invoice fraud does not require bypassing your enforcement — it only needs the receiving mail server to follow the downgrade instruction your own record provides. The fix is free and involves one DNS record update.

Data to cite

“In the August 2026 Domain Security Census of 75.5 million DMARC records, 476,465 domains publish an enforcement policy — quarantine or reject — and then weaken it with a pct value below 100.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“10,940 enforcement records set pct=0, meaning the enforcement they announce is switched off by the domain’s own record.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“90.0% of the watered-down enforcement cohort sits at p=quarantine — the combination where sampled-out mail falls all the way through to normal delivery.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“208,867 domains share the identical DMARC combination p=quarantine; pct=90; sp=none — a template fingerprint replicated across a fifth of a million domains.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“241,605 domains run DMARC enforcement at half strength or less (pct ≤ 50), representing 50.7% of the weakened cohort.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“2,422,718 p=none records carry a pct tag that does nothing, because sampling has no effect on a monitoring-only policy.” — defaults.exposed August 2026 Domain Security Census (432M domains)

FAQ

What does pct mean in a DMARC record? pct tells receiving mail servers what percentage of authentication-failing messages your published policy applies to, sampled at random. The default is 100. Messages outside the sample get the next policy down: reject falls to quarantine, quarantine falls to none (normal delivery). In the August 2026 census, 476,465 enforcement records set it below 100.

Is pct=90 good enough for DMARC? It means one in ten spoofed messages that fail authentication is delivered as if your policy didn’t exist — and under p=quarantine, delivered to the inbox path, not the spam folder. The census found 218,420 domains at exactly pct=90, the single most common weakened setting, which points at templates rather than deliberate choices. If you finished testing, remove the tag.

Does pct do anything with p=none? No. Sampling downgrades a policy to the next level down, and there is nothing below none, so the tag is inert on a monitoring record. The census still found 2,422,718 p=none records carrying a pct tag, 143,256 of them with values below 100 that change nothing.

Why would anyone set pct=0? p=quarantine; pct=0 is a known deliverability trick: some mailing-list software applies sender-rewriting compatibility behaviour based on the policy tag alone, so this record triggers it without quarantining any mail (industry knowledge). But the census found 4,755 records saying p=reject; pct=0, which has no such upside — and all 10,940 zero-percent enforcement records share the same practical property: the enforcement they announce is switched off.

How do I check my own pct setting? Your DMARC record is public DNS: look up the TXT record at _dmarc.yourdomain and read the tags. No pct tag means 100, which is what a finished deployment should say. Any explicit value below 100 means your enforcement is sampled — and if it has been sitting there longer than a testing window, your record and your actual protection have drifted apart.

How does a stalled pct ramp affect my spoofing exposure? Under p=quarantine, every percentage point below 100 is a percentage point of failing messages that get delivered normally. At pct=10 — held by 63,360 domains — 90% of spoofed messages that fail authentication are delivered to the inbox as if no DMARC enforcement exists. The label says quarantine; the mail flow says delivery.

What is the trend compared to previous census rounds? This is the first census round in which the pct tag distribution has been reported at this level of detail. Future editions of this report will track whether the stalled cohort grows or shrinks. The count of 476,465 weakened records is the August 2026 baseline.

DMARC enforcement report, August 2026 — the none/quarantine/reject picture across the graded web.
DMARC: reject vs quarantine — choosing an enforcement level, and why the downgrade rule matters.
What is DMARC none, quarantine, reject? — the plain-English explainer.
The 6 stages of DMARC maturity — where a stalled pct ramp sits on the maturity curve.

See where your own domain stands

Check your domain free at defaults.exposed — see exactly what your DMARC pct value is set to and whether your enforcement is running at full strength or silently diluted. Takes 30 seconds. No account needed.

Read the flagship census report: The State of Domain Security 2026 →

Aggregate data only. Data stored and processed in the EU.

How to cite this report

Press / blog: defaults.exposed (2026). DMARC pct Tag: 476,000 Domains Water Down Enforcement. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/en/articles/dmarc-pct-the-forgotten-dial

Academic: defaults.exposed. (2026, August 18). DMARC pct Tag: 476,000 Domains Water Down Enforcement. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/en/articles/dmarc-pct-the-forgotten-dial

In-line citation: (defaults.exposed, August 2026 Domain Security Census, n=75,543,004 DMARC records)

About the defaults.exposed August 2026 Census

The defaults.exposed Domain Security Census is a recurring independent measurement of the public domain namespace. The August 2026 edition scanned 432,127,908 domains between 1–16 August 2026 and graded 376,928,781 of them using methodology v9. Scans are conducted from EU infrastructure. No individual domain, registrant, or business is named in any report. All figures are aggregate distributions. Data is stored and processed within the EU.

Methodology: defaults.exposed/en/articles/domain-security-scoring-methodology-v9 Full census report: defaults.exposed/en/articles/the-state-of-domain-security-2026