Defaults.Exposed

Defaults.ExposedReports

The Security Correlation: Which Controls Cluster Together, and Which Sit Alone

Published

The Security Correlation: Which Controls Cluster Together, and Which Sit Alone

Only 2.9% of domains on the internet have all five core security controls in place. That figure is striking on its own. What it conceals is more instructive: that 2.9% is not a random scatter of diligent operators who happened to tick every box. It is a population. And the 56.8% of domains with neither SPF nor DMARC is also a population, for almost exactly the opposite reasons.

The August 2026 defaults.exposed census, covering 376,928,750 graded domains (methodology v9, as of 2026-08-16), makes the clustering effect visible at scale. Security controls on the internet do not distribute independently. They distribute together, because the thing they actually measure is whether anyone is actively operating the domain.

The Five Controls and How They Pair

The census tracks five controls: SPF, DMARC (any policy), DMARC enforcing (quarantine or reject), DNSSEC, and HTTPS. Global adoption rates:

Taken as a list, these look like five separate adoption problems. The pairwise view changes the picture significantly.

Of the 146.4 million domains with SPF, approximately 59.3 million also have DMARC, meaning about 40% of SPF adopters have gone on to add DMARC. Conversely, roughly 16.2 million domains have DMARC without SPF. That figure is technically invalid under RFC 7489, which requires SPF or DKIM alignment for DMARC enforcement. Those records exist, but they provide limited protection. The more consequential number: 214,276,774 domains (56.8%) have neither SPF nor DMARC. That is a majority of the measurable internet without any email authentication infrastructure at all.

The direction of correlation is consistent across every pairing:

The Latent Variable: Operator Maturity

The most parsimonious explanation for the correlation pattern is that a single underlying variable drives most of the variance in control adoption. Call it operator maturity, or active maintenance. The controls are not causing each other. They are effects of the same cause.

A domain is either actively managed by someone who monitors its security posture, or it is not. If it is, that operator tends to:

If it is not, none of these controls are present, because none of them are defaults. Every one of the five requires a deliberate choice. Parked domains, abandoned registrations, and small-operator domains that have never been touched after the initial DNS setup share a common profile: no email authentication, no DNSSEC, and often no HTTPS beyond whatever the hosting provider has opportunistically enabled.

The internet, measured this way, is bimodal. There is a large population of managed domains and a larger population of unmanaged ones, with a thin middle of partially configured domains that are typically in transition in one direction or the other.

What This Means for Security Improvement Programs

This framing has direct implications for how security improvement programs should be designed.

DMARC adoption campaigns, SPF push initiatives, and similar programs work well on the managed population, because those operators are already moving in the right direction. They have infrastructure, they have someone reading the admin inbox, and they respond to outreach about misconfiguration or absent records. The returns from this segment are real, but they are also limited: the managed population is already partially protected, and the incremental improvement per domain is bounded.

The unmanaged population is harder to reach and more important to reach. A domain with no SPF, no DMARC, no DNSSEC, and no HSTS is not one step behind. It is five steps behind, and those steps reflect an operator who is not monitoring the domain at all. Email to the abuse contact bounces. The registrant record is stale. The domain may have changed hands without any DNS review.

Campaigns that reach this population cannot rely on the normal signals: the operator will not see a DMARC failure report because they never set up reporting URIs. They will not see a Google Search Console alert because the domain is not verified. They may not even see a renewal reminder before the domain lapses.

The practical implication for security architects and IT managers running improvement programmes is that the low-hanging fruit (managed domains without full coverage) and the hard cases (unmanaged domains with zero coverage) require fundamentally different approaches. A phishing simulation that generates DMARC non-delivery reports is useful evidence when the target has DMARC in monitor mode. It is invisible when they have no DMARC at all.

The 2.9% Fully Protected Cohort

The 10,902,284 domains with all five controls in place are not a random cross-section. The profile, inferred from the census data and consistent with prior measurement literature, skews toward enterprise registrations, technology sector domains, recently registered domains (where the current operator set up DNS from scratch with modern defaults), and domains operated by organisations with dedicated IT or security functions.

These domains have almost certainly not assembled five independent security choices. They have made one organisational choice, which is to maintain an active security posture for their domain infrastructure. The five controls are outputs of that choice.

This cohort is important for benchmarking. If your organisation’s domains are not in this 2.9%, the gap is not a missing checkbox. It is a signal about operator attention. The question worth asking is not “which control should we add next” but “do we have a defined owner for this domain’s security posture, and are they reviewing it on a cycle.”

The 0.33% Fully Exposed Cohort

At the opposite end: 1,235,352 domains with none of the five controls. This is a small percentage but a large absolute count, and the population profile is approximately the mirror image of the fully protected cohort.

These are predominantly parked domains, expired registrations still resolving, domains registered speculatively and never built out, and small-operator domains where the registrant set up DNS once and has not returned. Some fraction of this cohort represents a real security risk: domains that are spoofable via email, that have no HTTPS, and that may be hosting content served over unencrypted connections to real users.

The 0.33% figure should not be read as reassuring. A domain with zero controls is maximally spoofable. An attacker who wishes to impersonate that domain has no SPF to align against, no DMARC to fail, no HSTS to pin, and no DNSSEC to validate. For domains that are genuinely inactive, this may be low consequence. For domains that are inactive only in the sense that their operator has stopped paying attention, it is a direct exposure.

Practical Takeaways

For security architects assessing supplier or partner domains: a domain with enforcing DMARC is a reasonable proxy for an operator who maintains their security posture. A domain with no SPF is a reasonable proxy for the opposite. The controls are correlated strongly enough that checking one gives useful signal about the others.

For CISOs building vendor risk programmes: the absence of DMARC is not merely an email security gap. It is an indicator that the operator may have gaps across all five dimensions. The census data supports using email authentication status as a lightweight screen for broader security hygiene.

For IT managers running internal DMARC or SPF rollouts: if your organisation has reached enforcing DMARC, the marginal cost of adding HSTS and reviewing DNSSEC status at your registrar is low, and the signal value to external assessors is high. The clustering effect works in your favour: being in the managed cohort is visible.

For policy and standards bodies: RFC 7489 (DMARC), RFC 7208 (SPF), RFC 4033 to 4035 (DNSSEC), and RFC 6797 (HSTS) each specify controls that require active operator choice. None of them are defaults in any common hosting environment. The aggregate result of making security controls opt-in rather than opt-out is visible in the census data: 56.8% of the internet’s domains have no email authentication, and 97.1% are not fully protected. The correlation finding suggests that changing this does not require fixing five problems. It requires fixing one: the absence of active operators who are responsible for domain security posture.

The clustering is the message. Controls travel together because attention travels together. The path to a more secure internet is not a longer checklist. It is more domains with someone responsible for reading the results.


Data source: defaults.exposed August 2026 census, 376,928,750 graded domains, methodology v9, as of 2026-08-16. Pairwise overlap figures are approximate where noted. References: RFC 7208 (SPF), RFC 7489 (DMARC), RFC 4033-4035 (DNSSEC), RFC 6797 (HSTS), RFC 2818 (HTTPS/TLS). Prior measurement work: USENIX Security DMARC longitudinal studies; M3AAWG DMARC Best Practices; ICANN DNSSEC deployment reports.

What this means

For IT managers and security teams, the clustering finding changes how you should read a vendor’s or partner’s domain posture. If you check a supplier domain and find no DMARC record, the census data says you should not treat that as an isolated email-security gap. An operator who hasn’t published DMARC is statistically unlikely to have DNSSEC, HSTS, or a consistent security review process. The absence of one control is a reasonable proxy for the absence of all of them — and for vendor risk purposes that is a different risk conversation than a single missing record.

For CISOs and security programme owners, the bimodal structure of the internet has a direct implication for roadmap prioritisation. If your organisation is already in the managed cohort — enforcing DMARC, HTTPS everywhere, HSTS deployed — you are in the 2.9% that has all five controls, and the marginal effort to get there is low: adding DNSSEC and HSTS once SPF and DMARC are in place is the natural continuation of the same pattern of attention. If your organisation is not yet in that cohort, the question is not which individual control to add next. It is who owns the domain’s security posture and whether they are reviewing it regularly.

For security improvement programme designers, the hardest and most important target population — the 56.8% with no email authentication at all — is precisely the one that cannot be reached through normal channels. They have no DMARC reporting addresses to receive alerts, no verified search console property to receive notifications, and often no current abuse contact. Reaching them requires channels that work even in the absence of a functioning email security infrastructure: registrar-level nudges, hosting-panel defaults, and awareness campaigns that do not assume the recipient is already paying attention.

Data to cite

FAQ

Why do security controls cluster together instead of being adopted independently? Because the controls are all effects of the same underlying cause: active operator management. None of SPF, DMARC, DNSSEC, HTTPS, or HSTS is a default in common hosting environments. Every one requires a deliberate choice. Operators who make one deliberate security choice tend to make the others; operators who make none tend to have none. The result is a bimodal internet — managed domains with multiple controls, unmanaged domains with zero.

What does it mean for a vendor assessment if a supplier domain has no DMARC? It is a reasonable proxy for a broader hygiene gap. The census data shows controls correlate strongly enough that the absence of DMARC is statistically associated with the absence of DNSSEC, HSTS, and consistent security review. For vendor risk purposes, a missing DMARC record is worth treating as a flag for a full posture check rather than just an email-security finding.

How do I know if my organisation is in the 2.9% fully protected cohort? Check your domain at defaults.exposed — the scan shows pass/fail for all five controls. You need SPF published, DMARC at p=quarantine or p=reject with a reporting address, HTTPS serving correctly with a redirect from HTTP, HSTS deployed with an adequate max-age, and DNSSEC signing with a valid chain from your registrar.

Has the clustering pattern changed since July 2026? This report uses the August 2026 census round (376,928,750 graded domains, asOf 2026-08-16). The structural pattern — controls clustering together, bimodal distribution between managed and unmanaged populations — is consistent across rounds. Adoption percentages for individual controls may shift slightly between months as new domains are configured and old ones lapse.

What is the best first step for an organisation that has none of the five controls? Start with SPF, then DMARC at p=none with a reporting address. These are the two free DNS records that establish email authentication and begin generating visibility into your mail flows. Once you can see what is sending on your behalf, move DMARC to enforcement. HTTPS follows naturally if you have a web presence; HSTS and DNSSEC are the finishing steps. The sequence matters because DMARC enforcement without understanding your mail flows can disrupt legitimate email.


Check your domain free at defaults.exposed — see which of the five core controls your domain has in place, and whether you are in the 2.9% fully protected cohort or the 56.8% with no email authentication at all. 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). The Security Correlation: Which Controls Cluster Together, and Which Sit Alone. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/en/articles/security-controls-correlation-clustering-2026

Academic: defaults.exposed. (2026, August 20). The Security Correlation: Which Controls Cluster Together, and Which Sit Alone. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/en/articles/security-controls-correlation-clustering-2026

In-line citation: (defaults.exposed, August 2026 Domain Security Census, n=376,928,750)


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