Defaults.Exposed › Reports

DMARC Subdomain Policy: 1.3 Million sp= Back Doors

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.

1,313,312 domains locked the front door and propped open the side gate

We parsed 75.5 million DMARC records and found 1,313,312 domains that enforce a strict policy on their main domain, then explicitly weaken it for every subdomain with a single tag: sp=. That is one in every 27 enforcing domains. A domain in this cohort will reject a forged mail from company.com and wave through a forged mail from billing.company.com, on purpose, because someone wrote it into the DNS record.

The sp= tag is not obscure. It is right there in the DMARC record, one token long, and it overrides the main policy for every subdomain that does not publish its own. Most domain owners never touch it, which is the safe choice: an untouched sp= inherits the main policy. The 1.3 million domains in this report touched it, and turned it the wrong way.

Key numbers

• 1,313,312 domains set a DMARC subdomain policy (sp=) explicitly weaker than their main policy — 3.8% of the 35.0 million enforcing domains measured.
• 459,577 domains at p=reject — the strictest DMARC setting — drop their subdomains all the way to sp=none: full enforcement at the apex, zero at the side gate.
• 824,268 domains at p=quarantine set sp=none, 4.3% of the quarantine cohort.
• Domains that weaken subdomain policy outnumber domains that strengthen it (142,165) by 9 to 1.
• 87.6% of the 75.5 million DMARC records carry no sp= tag at all — the safe default, since subdomains then inherit the main policy.
• A further 476,465 enforcing domains dilute their policy a different way, with pct= below 100.

What does sp= actually do in a DMARC record?

DMARC has one main policy tag, p=, with three values: none (monitor only), quarantine (send failures to spam), and reject (refuse them outright). The sp= tag sets a separate policy for subdomains. When sp= is absent, subdomains inherit whatever p= says — that inheritance is written into the DMARC specification (RFC 7489, published 2015; industry reference, not census data).

So there are exactly three postures a domain can take on subdomain mail:

1. Say nothing. Subdomains inherit the main policy. This is what the vast majority of the 75.5 million DMARC records we parsed do, and for most owners it is correct.
2. Restate or strengthen. 7.4 million records set sp= equal to p= (harmless, redundant), and 142,165 set it stricter — most often p=quarantine with sp=reject (76,139 domains), with the rest raising a monitoring p=none to quarantine or reject on subdomains — a sensible pattern for domains that send from the apex but never from subdomains.
3. Weaken. 1,313,312 records set sp= looser than p=. This is the back door.

The asymmetry in that third group is the story. Weakening is a deliberate act: someone had to know the tag exists, understand what it does, and choose a value below the protection they had already decided the organisation needed.

How many domains weaken their subdomain policy?

Here is the full weakened cohort, from the 75.5 million DMARC records in the August 2026 census round:

The reject-to-none rows deserve a second look. These 459,577 domains made the hardest call in DMARC — reject forged mail outright, accept the delivery risk — and then exempted their entire subdomain space from it. Not softened to quarantine. Switched off. Every hostname under the domain that lacks its own DMARC record is back to monitor-only.

For contrast, the strengtheners: 142,165 domains set sp= stricter than p=. The weakeners outnumber them 9.2 to 1. When owners reach for this tag, they overwhelmingly reach for it to open something, not close it.

Why do attackers love a weak subdomain policy?

Because recipients don’t read DNS records; they read display names and domains that look right. [email protected] reads as more legitimate than [email protected] to plenty of people — it looks like it came from a dedicated finance system. Payment-redirect and invoice fraud runs on exactly this kind of plausibility, which is why the finance and B2B angle matters here more than anywhere else in DMARC.

Mechanically, the exploit is trivial. If acme-corp.com publishes p=reject; sp=none, an attacker forges mail from accounts.acme-corp.com — a hostname that need not exist at all; DMARC policy discovery falls back from the subdomain to the organisational domain’s record, and that record says subdomains are none. The receiving server checks the policy, finds monitor-only, and delivers. The apex reject never enters the picture.

The defence the apex bought is real. The perimeter it covers is not the one the attacker will probe first. A domain with p=reject; sp=none is, for spoofing purposes, an unenforced domain with extra steps — the steps just happen to protect the one address form attackers need least.

We should be fair about intent, though, and there are legitimate reasons to run a weaker sp=, covered below. The census measures the posture, not the reasoning behind it.

The pct= footnote: partial enforcement by percentage

sp= is not the only dilution tag in DMARC. The pct= tag applies the policy to only a percentage of failing mail, and 476,465 enforcing domains — 1.4% of the enforcing cohort — set it below 100. A domain at p=reject; pct=50 rejects half its forged mail and delivers the other half to a weaker treatment; an attacker who sends twice has sent once past the policy.

pct= below 100 has an honest use: staged rollout, ratcheting from 1 to 100 over weeks while watching reports. The trouble is that rollouts stall. Our snapshot cannot distinguish a domain three days into a ramp from one parked at pct=10 since 2021, so we report the count and the caveat together: 476,465 enforcing domains were partially enforced on the day we measured, whatever the intent.

Two smaller observations from the same table. First, 4.7 million domains write pct=100 explicitly — harmless, it is the default. Second, the parser caught invalid values in the wild, including 57 domains publishing pct=587, a number the specification has no meaning for. Receivers ignore an invalid pct= tag and default to 100, so these domains are protected by other people’s error handling.

Is sp=none ever the right choice?

Sometimes, yes — and this report should not be read as “1.3 million defects.”

The defensible case: an organisation whose subdomains send mail through systems it cannot yet authenticate — a legacy ticketing tool on support.example.com, a marketing platform on mail.example.com — while the apex is clean. Publishing p=reject; sp=none protects the primary domain today instead of waiting for the whole estate. As a transition state, that is rational engineering.

The problem is the same one as pct=: transition states fossilise. sp=none leaves no reminder, breaks nothing, and shows up in no dashboard. And the better pattern costs little more — publish explicit DMARC records on the subdomains that genuinely need leniency, and let the rest inherit reject. That inverts the default from “every subdomain is open unless closed” to “every subdomain is closed unless opened,” which is the direction every other part of security moved years ago.

The 9-to-1 ratio of weakeners to strengtheners suggests fossils outnumber transitions. We cannot prove that from one snapshot; future editions of this report will show whether the weakened cohort shrinks the way genuine transitions should.

How we measured this

• Source: the August 2026 census round (figures as of 2026-08-16, methodology v9). We parsed the p=, sp= and pct= tags from the DMARC records observed at each graded domain.
• Denominator: 75,543,004 DMARC records with a parsed policy combination. Within that, the enforcing cohort — p=quarantine plus p=reject — is 34,983,618 domains (46.3%), and it is the denominator for the headline 3.8%. Percentages per policy use that policy’s own cohort as stated in the table.
• Vantage: apex-domain DNS lookups from our EU measurement infrastructure. We read each organisational domain’s published record; we did not probe individual subdomains for their own DMARC records, so a domain with sp=none plus strict per-subdomain records on its active subdomains would still be counted in the weakened cohort. Treat the cohort as “weakened by default at the organisational level.”
• Tag-combination table truncation: the combination table covers the top 200 p=×pct=×sp= combinations. Everything outside it occurs on at most ~56 domains per combination; combination-level counts are therefore floors, and the residual mass is immaterial at the millions scale quoted here.
• Malformed records: policy tokens that do not parse to none/quarantine/reject (typos like quarentine, stray values, empty tags) are excluded from the cohort arithmetic; they are a separate, smaller problem covered in our DMARC typos article.
• No intent claims. We measure published posture on one day. We cannot distinguish a deliberate, risk-accepted sp=none from a forgotten one, and we do not try.
• Snapshot dupes: roughly 0.05% of rows are re-scan duplicates; immaterial to every figure quoted.
• Aggregate only. We never publish an individual domain’s record or grade.

What this means

For security and IT teams, the operational implication is immediate: a DMARC review that confirms p=reject at the apex domain and calls it done has missed the most obvious side-channel in the record. The 459,577 domains that reached full rejection and then set sp=none are not hardened against subdomain spoofing — they are specifically open to it. Any security audit that evaluates DMARC policy without also reading the sp= tag is auditing the lock on the front door while the side gate is propped open in the same document.

For finance and operations teams, the threat model is concrete. Subdomain-spoofed mail exploits the fact that billing.yourdomain.com or invoices.yourdomain.com reads as internal even to trained recipients. Invoice fraud and payment-redirect attacks do not require breaking authentication — they require that the receiving mail server follows the downgrade instruction the organisational DMARC record provides. A single DNS record update — removing sp=none or setting sp=reject — closes the gap. The barrier is not complexity; it is that nobody looked at the sp= tag.

For organisations that genuinely have subdomains sending through systems not yet authenticated, the correct path is to publish targeted DMARC records at the subdomain level for those specific hosts, not to exempt the entire subdomain namespace. An explicit per-subdomain record containing p=none on the systems under migration protects the transition while keeping every other subdomain under the apex enforcement. The 9-to-1 ratio of weakeners to strengtheners in this dataset suggests most sp=none records are not active engineering decisions but forgotten defaults — and forgotten defaults do not expire.

Data to cite

• “1,313,312 domains publish DMARC enforcement at the apex but explicitly weaken the subdomain policy with sp=, covering 3.8% of the 35.0 million enforcing domains in the August 2026 census.” — defaults.exposed August 2026 Domain Security Census (432M domains)
• “459,577 domains publish p=reject — the strictest DMARC setting — and then set sp=none, dropping their entire subdomain space to monitoring-only.” — defaults.exposed August 2026 Domain Security Census (432M domains)
• “Domains that weaken their subdomain policy outnumber those that strengthen it by 9 to 1 in the August 2026 census.” — defaults.exposed August 2026 Domain Security Census (432M domains)
• “87.6% of the 75.5 million DMARC records parsed carry no sp= tag at all, meaning their subdomains safely inherit the main enforcement policy.” — defaults.exposed August 2026 Domain Security Census (432M domains)
• “824,268 domains at p=quarantine set sp=none, exempting every subdomain from enforcement regardless of the apex policy.” — defaults.exposed August 2026 Domain Security Census (432M domains)

FAQ

What does sp=none mean in a DMARC record? It tells receiving mail servers to apply no enforcement to mail from subdomains, regardless of the main p= policy. A record like p=reject; sp=none rejects forged mail from the apex domain but lets forged subdomain mail through for monitoring only. In our August 2026 census, 459,577 p=reject domains and 824,268 p=quarantine domains publish exactly this pattern.

Do subdomains inherit the DMARC policy if sp= is missing? Yes. Without an sp= tag, subdomains inherit the main p= policy — that is the specification’s default and the safe configuration. 87.6% of the 75.5 million DMARC records we parsed have no sp= tag, so their subdomains are as protected as their apex.

Can attackers spoof a subdomain if the main domain has p=reject? If the record weakens subdomain policy, yes. The forged subdomain does not even need to exist: DMARC policy discovery falls back to the organisational domain’s record, and if that record says sp=none, receivers apply no enforcement to the forgery. This is why the 1,313,312 weakened domains matter — the apex policy never touches subdomain mail.

Is it ever OK to set a weaker subdomain policy? As a short transition while unauthenticated subdomain senders are brought into line, it is defensible. The cleaner pattern is the reverse: keep strict inheritance at the organisational level and publish explicit, temporarily lenient DMARC records only on the specific subdomains that need them. A weakened organisational sp= protects nothing by default and tends to be forgotten.

How common is partial DMARC enforcement with pct=? 476,465 enforcing domains — about 1.4% of the 35.0 million enforcing cohort — set pct= below 100, meaning their policy applies to only a fraction of failing mail. pct= is designed for staged rollouts; a value parked below 100 long-term is another form of the same side-gate problem this report measures.

How do I fix a weak sp= setting? Remove the sp= tag entirely and your subdomains will inherit your main p= policy — for most organisations this is the right answer. If specific subdomains send through systems you cannot yet authenticate, publish a DMARC record directly on those subdomains set to p=none, and remove or correct the organisational sp= tag. Both changes are single DNS record edits.

Does this trend improve over time, or are sp=none records accumulating? This August 2026 census establishes the first baseline at this level of detail. Future editions will track whether the 1.3 million weakened records decline as organisations complete their deployments, or whether the cohort grows as more domains add sp=none as a default. The 9-to-1 weakener-to-strengthener ratio suggests fossil records currently dominate deliberate transitions.

Check your own side gate

Check your domain free at defaults.exposed — see exactly how your DMARC record handles subdomain mail and whether the sp= tag is silently exempting your subdomains from enforcement. Takes 30 seconds. No account needed.

Read next: The DMARC Enforcement Report, August 2026 →

Related: Can someone spoof my domain? · DMARC reject vs quarantine · The Email Spoofability Index

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

How to cite this report

Press / blog: defaults.exposed (2026). DMARC Subdomain Policy: 1.3 Million sp= Back Doors. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/en/articles/dmarc-sp-subdomain-policy-report

Academic: defaults.exposed. (2026, August 18). DMARC Subdomain Policy: 1.3 Million sp= Back Doors. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/en/articles/dmarc-sp-subdomain-policy-report

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