Defaults.Exposed

Defaults.Exposed › Reports

The Silent Domain: 56.8% of the Internet Has No Email Authentication

Published

The Silent Domain: 56.8% of the Internet Has No Email Authentication

The August 2026 census, covering 376,928,750 graded domains measured as of 2026-08-16, finds that 214,276,774 of them — 56.8% — publish neither an SPF record nor a DMARC policy. Not a weak policy. Not a misconfigured one. Nothing at all.

More than half the internet is silently spoofable.

The finding is not a marginal shift from last quarter. It is a structural fact about the internet: most registered domains have made no attempt to assert control over who can send email in their name. Many of them never send email at all. That is precisely the problem.

Why a Non-Sending Domain Is Still a Threat Vector

The intuition that “we don’t send email, so we don’t need email authentication” is wrong, and the wrongness is dangerous.

Email authentication — SPF (RFC 7208), DKIM (RFC 6376), and DMARC (RFC 7489) — exists to let receiving mail servers verify that a message claiming to come from a domain was actually authorised by that domain’s operator. If a domain publishes no SPF record and no DMARC policy, a remote mail server has no authoritative signal to check. The absence of authentication is not neutral. It is an open door.

An attacker constructing a phishing campaign against your customers, your staff, or a government agency does not need to compromise your mail server. They need only a sending service that will relay mail with your domain in the From header. Without SPF or DMARC, there is nothing to stop that message from reaching its target. Without a DMARC policy at enforcement, there is nothing instructing the recipient’s mail server to reject or quarantine it.

Domains that are parked, dormant, or used purely for web traffic are attractive targets for precisely this reason. Their operators are not watching for abuse. Their legitimate users are not expecting email from them, which makes a spoofed message more surprising and therefore more persuasive. A phishing email purportedly from a company’s dormant subsidiary or an agency’s legacy domain carries the full weight of brand trust.

The 2023 CISA advisory on business email compromise identified legacy and parked domains as a persistent gap in enterprise authentication posture. Attackers map corporate domain portfolios, including historical registrations, product sub-brands, and acquired company domains, and select the ones with the weakest posture. A domain that has never sent mail has, by definition, never been hardened.

The Defensive Posture for Non-Sending Domains

Two standards together close the spoofing gap for domains that deliberately send no email.

RFC 7505 (null MX) allows a domain to publish a DNS record that explicitly declares it accepts no inbound mail: MX 0 .. This is a positive assertion, not an absence. It signals to sending mail servers that delivery attempts to this domain should be rejected, and it signals to anyone inspecting the domain that the operator has consciously opted out of mail service rather than simply neglecting configuration.

DMARC at p=reject closes the outbound side. A policy of v=DMARC1; p=reject; sp=reject; instructs every compliant receiving mail server to reject, without delivery, any message that claims to originate from this domain but cannot pass SPF or DKIM alignment. For a non-sending domain that publishes no SPF authorisation and has no DKIM keys in use, every spoofed message will fail alignment. With p=reject, those messages are rejected rather than delivered.

Together, null MX and p=reject form the complete defensive posture for a non-sending domain: inbound delivery is declared impossible, and outbound impersonation is instructed to be rejected. Neither alone is sufficient. A domain with p=reject but no null MX can still receive mail. A domain with null MX but no DMARC policy still offers no rejection instruction to receiving servers.

The implementation cost is two DNS records. The operational overhead is close to zero. The protection is complete within the time DNS changes propagate.

90.7% of Domains Offer No Spoofing Protection

The August 2026 census finds that 341,945,132 domains — 90.7% — have no enforcing DMARC policy. That includes domains with no DMARC record at all, and domains with a DMARC record set to p=none, which is a monitoring posture that instructs receiving servers to take no action.

CategoryCountShare
DMARC any policy75,571,24820.0%
DMARC at p=quarantine or p=reject34,983,6189.3%
No enforcing DMARC (spoofable)341,945,13290.7%

Of domains that do publish a DMARC record, a significant portion remain at p=none: published during a monitoring phase and never advanced to enforcement. This is a common failure mode. Organisations deploy DMARC tooling, observe their mail flows, resolve alignment issues, and then deprioritise the final step of moving to enforcement. The record exists; the protection does not.

SPF coverage is broader. Approximately 146.4 million domains publish an SPF record, compared with 75.6 million that have DMARC at any policy level. SPF without DMARC is partial protection. SPF defines which servers are authorised to send for a domain, but SPF alone does not instruct receiving servers what to do with a failure. DMARC provides that instruction, and it adds the alignment requirement that links SPF and DKIM results to the visible From header, the address the recipient actually sees.

A domain with SPF but no DMARC is better than a domain with nothing. It is not a defended domain.

Regulatory and Industry Requirements

Three frameworks are now directly relevant to organisations managing domain portfolios.

Google and Yahoo bulk sender requirements (February 2024): Senders dispatching more than 5,000 messages per day to Gmail or Yahoo Mail accounts are required to authenticate with SPF, publish DKIM keys, and have a DMARC record at p=none or above. This requirement is enforced: non-compliant bulk senders face delivery failures. It covers sending domains, not parked or dormant ones, but it has accelerated DMARC adoption among organisations that previously treated authentication as optional.

CISA Binding Operational Directive 18-01: Federal civilian executive branch agencies in the United States are required to implement DMARC with a p=reject policy target for all their domains. BOD 18-01 was issued in 2017 and has driven measurable improvement in .gov domain authentication posture. The directive explicitly addresses agency subdomains and secondary domains, not only primary agency domains. The principle, that every domain under an organisation’s control requires the same defensive posture, applies equally outside the federal context.

NIS2 Directive (EU, October 2024 transposition): The Network and Information Security Directive 2 imposes security obligations on essential and important entities across the EU, including obligations around the security of network and information systems used in their operations. Email infrastructure falls within scope. While NIS2 does not enumerate specific technical controls in the directive text, national supervisory authorities have increasingly cited email authentication as a baseline expectation during assessments. Organisations that cannot demonstrate SPF, DKIM, and DMARC deployment across their domain portfolio face compliance risk as NIS2 enforcement matures.

The trajectory of regulatory pressure is consistent: email authentication for all operational domains, with enforcement-level DMARC, is moving from best practice to baseline requirement.

What IT and Security Teams Should Do

The action set differs by domain category, but the outcome requirement is the same: every domain in your portfolio should be explicitly configured, not silently unconfigured.

For sending domains:

  1. Audit SPF records for all domains that send operational mail. Verify that the include: chain is complete and that the record ends with -all (hard fail) rather than ~all (soft fail). RFC 7208 defines the semantics; -all is the correct terminator for a fully enumerated policy.

  2. Deploy DKIM signing for every sending service. Each third-party sender, marketing platforms, transactional email providers, CRM systems, requires its own DKIM key published in your DNS. A missing DKIM key for any sender prevents DMARC alignment for messages from that sender.

  3. Advance DMARC from p=none to p=quarantine, then to p=reject. The monitoring phase has a defined purpose: observe aggregate reports to identify unauthenticated mail flows, resolve them, and then enforce. Leaving DMARC at p=none indefinitely provides no protection.

For non-sending domains:

  1. Publish a null MX record per RFC 7505: example.com. MX 0 .
  2. Publish an SPF record that explicitly authorises no senders: v=spf1 -all
  3. Publish a DMARC policy at p=reject with the subdomain policy also set to reject: v=DMARC1; p=reject; sp=reject;

These three records take under ten minutes to configure and propagate within 48 hours. There is no ongoing operational cost. There is no mail flow to monitor. The posture is set and forgotten.

For domain portfolio management: Organisations with large domain portfolios, holding companies, enterprises with acquired brands, agencies managing client domains, should conduct a complete audit against the current registered domain set. The gap between domains under management and domains with complete authentication is consistently larger than teams expect.

The Majority Is Not a Baseline

56.8% of graded domains having no email authentication does not make the absence of authentication normal or acceptable. It makes it a widespread vulnerability. The scale of the gap reflects the aggregate cost of inaction across millions of operators who registered domains without configuring them, acquired domains without auditing them, or parked domains on the assumption that silence is safety.

Silence is not safety. A domain that says nothing about its email posture says everything an attacker needs to hear.

The defensive configuration for a non-sending domain is two DNS records away. The defensive configuration for a sending domain is a structured process with a defined endpoint. Neither requires specialised infrastructure. Both are within reach of any organisation with DNS access and an hour to spend.

The internet’s email authentication problem is not a technical unsolved problem. It is an adoption problem. The standards are published. The tools are available. The regulatory direction is clear.

What this means

For IT managers and security teams, the 56.8% figure is both a benchmark and a warning. The benchmark: if your primary domain has SPF, DKIM, and an enforcing DMARC policy, you are ahead of the majority of the internet. The warning: that majority includes the parked domains, acquired companies, product sub-brands, and legacy properties in your own portfolio that nobody has audited. The domains you don’t think about are the domains attackers target first, precisely because they carry brand credibility and nobody is watching for abuse reports.

For business owners, the most actionable insight from this data is that email authentication is not just for companies that send bulk email. The 214 million domains with no authentication are predominantly non-sending domains — parked names, brand registrations, redirect shells. Attackers use these domains to send phishing email that appears to come from legitimate brands. The three-record lockdown (null MX, SPF -all, DMARC p=reject) is free, takes under ten minutes, and converts a phishing vehicle into a dead end. Every domain in your portfolio that receives no legitimate email should have this configuration applied today.

For organisations navigating NIS2 compliance in the EU or aligning with CISA guidance, the 90.7% figure for domains without enforcing DMARC is the gap that regulators are increasingly focused on. “We have DMARC at p=none” is not a compliant posture — it is a monitoring posture, and monitoring without enforcement provides no protection. The path to compliance is defined: p=none while you audit, p=quarantine once you have confidence, p=reject once you have verified all legitimate senders are authenticated. The August 2026 census shows this path has been taken by only 9.3% of the graded web. The gap is the opportunity for any organisation that acts now.

FAQ

What is the difference between SPF, DKIM, and DMARC? SPF defines which mail servers are authorised to send email for your domain. DKIM adds a cryptographic signature to outbound messages that recipients can verify. DMARC ties them together: it publishes a policy instructing receiving servers what to do when SPF or DKIM checks fail — monitor (p=none), quarantine, or reject — and adds alignment requirements that connect the technical checks to the From header the recipient actually sees. All three are needed for complete protection; SPF alone or DMARC alone is partial.

Does a DMARC record at p=none protect my domain? No. p=none is a monitoring posture: it generates reports about mail failing authentication but instructs receiving servers to take no action. The 90.7% of graded domains with no enforcing DMARC includes all domains at p=none. Enforcement begins at p=quarantine (route suspicious messages to spam) and reaches full protection at p=reject (block them entirely).

What is the minimum authentication posture for a non-sending domain? Three DNS records: null MX (MX 0 . per RFC 7505), SPF (v=spf1 -all), and DMARC (v=DMARC1; p=reject; sp=reject). This configuration declares the domain accepts no inbound mail, authorises no senders, and instructs receiving servers to reject any message claiming to come from it. All three are free. The combination takes under ten minutes to deploy.

How does NIS2 relate to email authentication? NIS2 imposes security obligations on essential and important entities across the EU, with email infrastructure in scope. While the directive does not enumerate specific controls, national supervisory authorities have increasingly cited SPF, DKIM, and DMARC deployment as baseline expectations during assessments. Organisations unable to demonstrate authentication across their full domain portfolio — not just their primary domain — face growing compliance risk as NIS2 enforcement matures through 2026 and beyond.

Why do so many domains have SPF but not DMARC? SPF (146.4 million domains) significantly outnumbers DMARC (75.6 million at any level) because SPF predates DMARC by a decade and appeared earlier in deliverability guides. Many organisations deployed SPF to improve mail delivery and never took the additional step of publishing DMARC. The result is partial protection: SPF defines authorised senders, but without DMARC there is no instruction to receiving servers about what to do when a message fails — and no alignment requirement connecting SPF results to the visible From header.

Data to cite

See where your own domain stands

Check your domain’s email authentication posture against the August 2026 census baseline.

Check your domain free at defaults.exposed — see instantly whether your domain is among the 56.8% with no authentication or the 9.3% with full enforcement, and get a clear view of every check that is failing. Takes 30 seconds. No account needed.

Data source: defaults.exposed census, asOf 2026-08-16, methodology v9. Total graded domains: 376,928,750. Dead domains are graded F and included in all figures. References: RFC 7208 (SPF), RFC 6376 (DKIM), RFC 7489 (DMARC), RFC 7505 (null MX), CISA BOD 18-01, EU NIS2 Directive 2022/2555, Google/Yahoo bulk sender requirements February 2024.

How to cite this report

Press / blog: defaults.exposed (2026). The Silent Domain: 56.8% of the Internet Has No Email Authentication. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/en/articles/silent-domain-56-percent-no-email-authentication-2026

Academic: defaults.exposed. (2026, August 20). The Silent Domain: 56.8% of the Internet Has No Email Authentication. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/en/articles/silent-domain-56-percent-no-email-authentication-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

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