Defaults.Exposed

Defaults.Exposed › Reports

The Google-and-Yahoo Deadline, Two Years On: Where Email Authentication Stands in August 2026

Published

The Google-and-Yahoo Deadline, Two Years On: Where Email Authentication Stands in August 2026

Finding: Two and a half years after Google and Yahoo made DMARC a hard requirement for bulk senders, only 9.3% of the 376 million domains graded in the August 2026 census enforce it. The majority of the internet, 56.8% of all graded domains, publishes neither SPF nor DMARC at all.

The February 2024 announcements from Google and Yahoo were the most consequential forcing function email authentication had seen in a decade. Any sender dispatching 5,000 or more messages per day to Gmail or Yahoo Mail addresses was required to authenticate with SPF and DKIM, publish a DMARC record, and support one-click unsubscribe. The deadline was not aspirational. Google began rejecting non-compliant traffic. Yahoo followed. For the first time, authentication failure carried a delivery consequence that could not be deferred.

This article uses the August 2026 census (methodology v9, as of 2026-08-16, covering 376,928,750 graded domains from approximately 432 million scanned) to measure the directional response of the broader sending web. These figures are not a compliance rate for bulk senders specifically. The rules bind senders to Gmail and Yahoo, not every domain that exists. What the census measures is the readiness posture of the web as a whole: the infrastructure that would need to exist before any domain could credibly meet those requirements.

What the Rules Actually Require

Google’s bulk sender requirements, published February 2024 and enforced from April 2024, set three authentication conditions for senders exceeding 5,000 daily messages to Gmail addresses. First, SPF or DKIM must pass for the sending domain. Second, a DMARC record must be published at the organisational domain level. Third, the DMARC record must align with either SPF or DKIM. Google’s documentation does not require a specific DMARC policy for initial compliance, but the direction of travel is clear: enforcement policy (p=quarantine or p=reject) is the intended destination.

Yahoo’s parallel requirements, announced simultaneously, are substantively identical on authentication. Both platforms also require that marketing and subscriptions messages support RFC 8058 one-click unsubscribe, and that senders maintain spam complaint rates below 0.10%.

These requirements draw on two published standards: RFC 7208 (SPF, Sender Policy Framework), which defines how a domain authorises sending infrastructure, and RFC 7489 (DMARC, Domain-based Message Authentication, Reporting, and Conformance), which defines how receivers should handle mail that fails that authorisation and how domain owners receive feedback. CISA’s email security guidance, updated in 2023, independently recommends p=reject as the target state for federal agencies, a position that aligns with where the Google and Yahoo requirements are pushing commercial senders.

In the EU, the compliance surface is wider. GDPR imposes accountability obligations on organisations that send personal data by email. NIS2, the Network and Information Security Directive 2 (transposed by member states from October 2024), extends security obligations to a broader set of entities and their supply chains. An organisation that cannot authenticate its email cannot demonstrate control over its sending infrastructure, which is directly relevant to both frameworks. The Google and Yahoo requirements, in this context, function as a floor, not a ceiling.

Where the Web Stands Now

The August 2026 census graded 376,928,750 domains. Here is what the data shows.

DMARC adoption: 75,571,248 domains publish a DMARC record of any kind, representing 20.0% of all graded domains. Of those, 34,983,618 (9.3% of total) publish an enforcing policy: either p=quarantine or p=reject. The remaining 40,541,896 DMARC publishers sit at p=none, a monitoring-only posture that provides visibility but no protection against spoofing.

SPF adoption: 146,413,297 domains publish an SPF record, representing 38.8% of all graded domains. SPF is present at roughly twice the rate of DMARC, which is consistent with its earlier standardisation and simpler deployment path. SPF without DMARC, however, does not meet the Google and Yahoo requirements on its own. Alignment requires both.

The uncovered majority: 214,276,774 domains, 56.8% of all graded domains, publish neither SPF nor DMARC. More than half the internet has no email authentication infrastructure in place at all. For the State of Domain Security 2026, this figure has been the defining characteristic of the global posture.

Full protection: Only 10,902,284 domains (2.9%) meet all five criteria measured in the census: SPF, enforcing DMARC, DNSSEC, HTTPS, and HSTS. This is the cohort that has closed the most common attack surfaces simultaneously.

The SPF Quality Problem

SPF presence is a necessary but insufficient signal. The quality of SPF records matters as much as their existence, and the August 2026 data exposes a significant quality gap.

Of the 146,413,297 domains that publish SPF, 82,539,695 (56.4%) use a soft fail qualifier (~all). Soft fail instructs receivers to accept the message but mark it as suspicious. In practice, most receivers treat soft fail as a pass. A DMARC policy set to p=quarantine or p=reject does not compensate for this, because DMARC acts on the authentication result, and a soft fail result is treated as a pass by most implementations. Soft fail SPF combined with enforcing DMARC produces less protection than it appears to.

By contrast, 56,268,491 domains (38.4% of SPF publishers) use hard fail (-all), which instructs receivers to reject mail from unauthorised sources. This is the configuration that actually delivers the protection SPF promises.

The SPF permerror count, 7,743 domains with too many DNS lookups (exceeding the RFC 7208 limit of 10), is small in absolute terms but represents a class of misconfiguration that causes SPF to fail entirely for those domains. A permerror result means SPF neither passes nor fails: it errors. DMARC treats an SPF permerror as a failure on the SPF channel, which means a domain relying on SPF for DMARC alignment and running a permerror has no authentication path for that channel.

The Enforcement Gap

The gap between DMARC publication and DMARC enforcement is the most actionable finding in this dataset. Of the 75,571,248 domains that publish DMARC, 40,541,896 (53.6% of DMARC publishers) remain at p=none. These domains have made the investment to publish a record and, by implication, to configure DMARC reporting. They are receiving aggregate and forensic reports. But they have not moved to enforcement.

This is not standing still: it is a stall. The p=none phase is intended as a temporary observation window, typically 30 to 90 days for a competent deployment, during which the domain owner reviews reports, identifies authorised sending sources not yet covered by SPF, and validates DKIM signing across all mail streams. A domain that has been at p=none for months or years is not in transition. It has stopped.

The Google and Yahoo requirements do not mandate a specific policy level, but the intent is unambiguous. Google’s own guidance recommends moving to p=quarantine and then p=reject. For any bulk sender aiming to be clearly compliant rather than technically eligible, p=none is not a durable position.

The distance between the 20.0% that publish any DMARC and the 9.3% that enforce it represents a cohort of approximately 40 million domains that have started the authentication journey and have not finished it. This is the highest-leverage segment for improvement: the infrastructure is partly in place, the reporting data exists, and the remaining step is a policy update.

What This Means for IT Teams

For IT and security teams evaluating their organisation’s position against the Google and Yahoo requirements, or against CISA guidance, or against NIS2 obligations, the August 2026 census provides a benchmark.

If your domain is at p=none: You are not meeting the spirit of the bulk sender requirements, and you are not protected against domain spoofing. The reporting data you have accumulated is the input to your next step. Review your DMARC aggregate reports, confirm all authorised sending sources are covered by SPF or DKIM, and set a date to move to p=quarantine.

If your SPF record uses ~all: Evaluate whether you can move to -all. The operational risk of hard fail is that any unauthorised sending source, a shadow IT service, a forgotten newsletter platform, a vendor sending on your behalf without your SPF record covering them, will begin failing. This is the failure mode you want to know about before a threat actor exploits it.

If your domain publishes neither SPF nor DMARC: Any email that claims to come from your domain is unauthenticated. Receivers have no policy instruction from you. Threat actors can spoof your domain with no technical friction. Publishing SPF and an initial p=none DMARC record costs nothing and takes less than an hour. There is no justification for remaining in the 56.8%.

For EU organisations: The NIS2 and GDPR accountability arguments are independent of whether you send bulk email. Authentication is a control. The absence of authentication is a documented gap. Regulators and auditors are increasingly treating email security posture as a measurable security control, not an IT administration detail.

What this means

For IT and security teams, the enforcement gap is the most actionable finding: 40 million domains have published DMARC but remain at p=none, meaning they have the infrastructure and reporting in place but have not taken the step from visibility to protection. If your organisation is in this cohort — DMARC published, p=none, reporting working — moving to p=quarantine is a single DNS record change. The reporting data you have accumulated tells you whether all your sending infrastructure is authenticated. If the reports show clean SPF and DKIM alignment across all sources, there is no technical reason to remain at p=none.

For compliance and legal teams, the Google and Yahoo requirements have been in effect since April 2024 — this is not a future obligation. Any organisation sending bulk email to Gmail or Yahoo addresses that has not completed SPF, DKIM, and DMARC deployment is currently non-compliant and at risk of delivery failures. In the EU, NIS2 assessors and GDPR accountability reviews are increasingly treating the absence of email authentication as a documented security gap, not a technical footnote. The 56.8% of domains with neither SPF nor DMARC have no documented control over their email-sending infrastructure — which is a defensible position in approximately no compliance framework.

For business owners who are not bulk senders, the argument for authentication is not compliance — it is spoofing protection. A domain with no SPF and no DMARC can be impersonated in email with no technical friction. Fake invoices, payment-redirect requests, and supplier impersonation attacks require only that the receiving mail server has no policy instruction from you. Publishing SPF and an initial p=none DMARC record costs nothing and takes under an hour. The 214 million domains currently in the uncovered majority have left that door open.

Data to cite

FAQ

What did Google and Yahoo actually require in February 2024? For senders dispatching 5,000 or more messages per day to Gmail or Yahoo Mail, the requirements are: SPF or DKIM must pass, a DMARC record must be published at the organisational domain level, the DMARC record must align with either SPF or DKIM, marketing messages must support one-click unsubscribe (RFC 8058), and spam complaint rates must stay below 0.10%. Google began enforcing these requirements in April 2024, with Yahoo implementing in parallel.

If I only send transactional email, do these requirements apply to me? The 5,000-message daily threshold is counted per sending domain across all messages to Gmail. A business sending order confirmations, password resets, and account notifications may reach that threshold without running a marketing campaign. The guidance is to treat authentication as a baseline for all email, not only marketing — the cost is the same and the protection is broader.

My domain is at DMARC p=none. Is that compliant with Google’s requirements? Technically eligible but not the intended destination. Google’s requirement is to publish a DMARC record with any policy, including p=none. But Google’s guidance explicitly states the goal is to move to p=quarantine and then p=reject. A bulk sender permanently at p=none is meeting the letter of the initial requirement but not the direction of travel — and receives no spoofing protection.

What is the fastest path from no authentication to compliant? Publish an SPF record covering all your sending sources (one DNS record), ensure your mail provider is signing with DKIM (typically a configuration step in the provider’s admin panel), then publish a DMARC record at p=none with a rua= address to start receiving reports. That sequence takes under an hour for a simple sending environment. The subsequent steps — reviewing reports, completing SPF coverage, moving to p=quarantine — take 30 to 90 days depending on sending complexity.

What does NIS2 require for email authentication? NIS2 (Directive 2022/2555, transposed by EU member states from October 2024) does not name SPF, DKIM, or DMARC specifically but requires appropriate technical measures for ICT security in essential and important entities. ENISA’s technical guidelines, which inform NIS2 implementation, recommend SPF, DKIM, and DMARC at p=quarantine or p=reject as the baseline. An organisation without these controls has a documented gap against the ENISA baseline that NIS2 assessors are likely to surface.

What is the trend — is adoption improving? The August 2026 census measures the same population as July 2026 with updated data. DMARC enforcement (p=quarantine or p=reject) sits at 9.3% of all graded domains. Future editions will report month-over-month movement in all four adoption metrics: SPF presence, DMARC any, DMARC enforcement, and the uncovered-majority count. The 56.8% with no authentication is the August 2026 baseline.

Check your domain to see your current SPF, DMARC, DNSSEC, and HTTPS posture scored against the August 2026 census baseline.

Check your domain free at defaults.exposed — see whether your domain meets the Google and Yahoo authentication requirements and where you stand relative to the 376 million domains graded in the August 2026 census. Takes 30 seconds. No account needed.

Data source: defaults.exposed August 2026 census, methodology v9, as of 2026-08-16. 376,928,750 domains graded from approximately 432 million scanned. All figures are counts of graded domains unless otherwise noted. References: RFC 7208 (SPF), RFC 7489 (DMARC), Google Bulk Sender Requirements (February 2024), Yahoo Sender Requirements (February 2024), CISA Binding Operational Directive 18-01 and subsequent guidance.

How to cite this report

Press / blog: defaults.exposed (2026). The Google-and-Yahoo Deadline, Two Years On: Where Email Authentication Stands in August 2026. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/en/articles/google-yahoo-email-authentication-deadline-2026

Academic: defaults.exposed. (2026, August 20). The Google-and-Yahoo Deadline, Two Years On: Where Email Authentication Stands in August 2026. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/en/articles/google-yahoo-email-authentication-deadline-2026

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

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