Defaults.Exposed

Defaults.Exposed › Reports

DMARC Without SPF: 16 Million Domains With Half an Email Authentication Stack

Published

DMARC Without SPF: 16 Million Domains With Half an Email Authentication Stack

Approximately 16 million domains publish a DMARC record with no SPF record at all. In the August 2026 census across 376,928,750 graded domains, 75,571,248 carry a DMARC record. Of those, only 59,332,569 also carry SPF, leaving roughly 16.2 million operating their email authentication stack with one pillar missing. DMARC still functions for these domains if DKIM signing is consistent. But any sending path that does not carry a DKIM signature has no fallback, and the SPF channel, an independent check that has existed for over two decades, is completely absent.

This is not a hypothetical risk class. It is the predictable output of a particular deployment sequence that mail providers, compliance frameworks, and vendor onboarding flows have collectively encouraged.

How DMARC alignment works without SPF

DMARC (RFC 7489) does not authenticate mail directly. It checks whether either SPF or DKIM alignment passes, then applies the domain owner’s stated policy. Alignment means the authenticated domain matches the RFC 5322 From header: the address the recipient actually sees.

There are two paths to a DMARC pass:

  1. SPF alignment: the envelope Mail From (SMTP MAIL FROM, also called the return-path) must pass SPF under RFC 7208, and that domain must align with the From header. SPF alignment can be strict (exact match) or relaxed (organisational domain match).
  2. DKIM alignment: a DKIM signature under RFC 6376 must validate, and the d= domain in the signature must align with the From header.

Either one is sufficient. A domain with DMARC and DKIM but no SPF can pass DMARC, as long as the sending mail server applies a valid DKIM signature with a matching d= value. The RFC is explicit: if a message can be authenticated using either SPF or DKIM, the DMARC check may succeed. There is no requirement that both mechanisms be present.

So the technical statement is careful: DMARC without SPF is not broken. It is operating with one authentication channel instead of two.

The operational statement is less comfortable.

The specific failure modes when SPF is absent

Sending paths that do not sign with DKIM. Not every mail sender supports DKIM. Older infrastructure, some transactional systems, third-party tools added without proper configuration, and mail relay architectures that strip or break signatures are all real and common. A domain with SPF has a fallback for these paths: the SPF check is path-based and does not depend on the sending application’s support for cryptographic signing. Without SPF, any path that does not sign means a DMARC fail with no recovery mechanism.

Forwarding and indirect mail flows. Email forwarding breaks SPF. When a message is forwarded by an intermediate server, the envelope Mail From changes and the original SPF result is invalidated. The mechanism for handling this case is DKIM alignment, which survives forwarding as long as the signature is intact. But this is exactly the situation where having two working authentication channels matters most. A domain relying solely on DKIM for DMARC alignment has no SPF path to fall back on when DKIM is stripped or not signed in the first place.

SPF is an independent signal to receiving infrastructure. Mail receivers evaluate SPF separately from DMARC; it feeds into their own reputation and filtering decisions, not only the DMARC verdict. A domain with no SPF record at all is treated differently by receivers than a domain with a properly configured SPF record. RFC 7208 section 8.7 is clear that a missing SPF record (a “none” result) means the sending domain has chosen not to participate in the SPF mechanism. Some receivers treat this as a weaker trust signal independent of DMARC outcome.

Misconfigured DKIM is silent until it fails. DKIM keys have selectors and are hosted in DNS. They can expire, rotate without notification, or be misconfigured for a subset of sending infrastructure. SPF is simpler: a list of authorised IP addresses and mechanisms, verifiable immediately with a DNS lookup. Organisations that rely entirely on DKIM for DMARC alignment have no awareness of the failure until DMARC reports start showing authentication failures, at which point deliverability is already affected.

How this situation arises operationally

The DMARC-first deployment pattern is well documented in vendor onboarding flows, particularly from cloud mail providers and compliance tooling. The advice is: publish v=DMARC1; p=none; rua=mailto:[email protected], wait for reports, then tighten. This is sound advice for domains that already have SPF and DKIM in place. It becomes a problem when it is the first step on a domain where neither exists.

The sequence tends to run like this: a compliance requirement arrives. DMARC is the named control. Someone publishes the record. The scanner goes green. The report shows aggregate authentication data, which is assumed to be reassuring. What the aggregate data does not immediately surface is that SPF is absent, because DKIM alignment may be passing for most mail, giving the impression that authentication is working correctly.

The gap surfaces when a new sending path is added, when DKIM key rotation goes wrong, or when forwarding-heavy recipients begin reporting failures. By that point the domain has been running without SPF for months or years.

Google and Yahoo’s 2024 sender requirements make this explicit: both SPF and DKIM are required, not either-or. Domains with DMARC and DKIM but no SPF are technically non-compliant with those requirements regardless of their DMARC verdict.

The role of aggregate DMARC reports in discovering the gap

DMARC aggregate reports (the rua= channel) are the primary mechanism for discovering incomplete authentication configuration. A properly structured report from a major receiver will show, for each source IP that sent mail claiming to be from the domain: the SPF result, the DKIM result, and the DMARC disposition. A domain with no SPF will show SPF “none” or “fail” against every source IP, regardless of DKIM outcome.

Domains that publish a DMARC record without a rua= tag will never see this signal. Without the reports, the missing SPF is invisible: DMARC verdicts may be passing via DKIM alignment, everything appears functional, and no alert fires.

The practical consequence: the gap between “DMARC record exists” and “email authentication stack is complete” is not visible from external inspection alone. A domain can show a valid DMARC record at p=reject while having no SPF record and depending entirely on a single DKIM key whose rotation policy is unknown.

What a complete stack looks like

Email authentication has three components, each with a distinct function:

SPF (RFC 7208): authorises specific IP addresses and mechanisms to send mail for the domain. Protects the envelope-from path. Deployed as a TXT record on the organisational domain.

DKIM (RFC 6376): cryptographically signs outgoing messages using a private key held by the sending server. Receivers validate the signature against the public key published in DNS. Signs the message headers and body, meaning the signature survives forwarding if the signed content is unchanged.

DMARC (RFC 7489): ties SPF and DKIM alignment together and adds a policy enforcement layer. Tells receivers what to do with mail that fails both alignment checks: p=none (take no action, report only), p=quarantine (send to spam), or p=reject (refuse delivery).

A complete stack requires all three. A domain with DMARC and DKIM but no SPF has one authentication channel. If that channel fails for any reason, DMARC fails with no fallback.

The fix for a domain in this state is a single DNS change: publish an SPF record. The minimal form is straightforward:

v=spf1 include:_spf.yourmailprovider.example -all

The include: mechanism delegates authorisation to the mail provider’s published IP ranges. The -all hard-fail instructs receivers to reject mail that does not match any authorised mechanism.

For domains that have been operating without SPF: (1) identify every sending source; (2) draft an SPF record covering all of them; (3) publish with ~all initially to verify against DMARC reports; (4) tighten to -all once confirmed; (5) verify DMARC reports show consistent SPF alignment.

The SPF lookup limit of 10 DNS queries (RFC 7208 section 4.6.4) applies. Large sending inventories should use SPF flattening tools to stay within the limit.

Regulatory and compliance context

DMARC without SPF creates specific compliance exposure. The UK National Cyber Security Centre’s DMARC guidance requires both SPF and DKIM as prerequisites for meaningful DMARC deployment.

The NIS2 Directive (Directive 2022/2555) does not name DMARC or SPF specifically but requires appropriate technical measures for email security in essential and important entities. ENISA’s technical guidelines recommend SPF, DKIM, and DMARC at p=quarantine or p=reject as the baseline. A domain with DMARC but no SPF does not meet that baseline.

DORA (Regulation 2022/2554), applying to financial entities in the EU, includes ICT security requirements covering email-borne attack vectors. An incomplete authentication stack that fails for specific sending paths is a gap under those requirements.

CISA’s Binding Operational Directive 18-01 requires federal agencies to deploy DMARC at p=reject alongside both SPF and DKIM. Any deployment guidance that assumes both, without confirming both, misses the point of the directive.

What this means

For IT and security teams, the operational risk is specific and testable today. If your domain has a DMARC record but no SPF, look at your DMARC aggregate reports: every source IP will show an SPF result of “none” or “fail.” If those reports are not being reviewed — or if your DMARC record has no rua= tag — you have no visibility into how your authentication is performing in practice. The fix is a single DNS record: an SPF TXT record on your organisational domain. It does not require a change to your mail server, your provider, or your DKIM configuration.

For compliance officers, the exposure is concrete. Google and Yahoo’s 2024 bulk sender requirements explicitly require both SPF and DKIM — not either-or. A domain with DMARC and DKIM but no SPF is non-compliant with those requirements regardless of whether its DMARC record passes for most mail. NIS2 and DORA assessors are increasingly checking for the complete authentication stack; a missing SPF record is a documented gap. The NCSC’s guidance treats all three components as prerequisites, and ENISA’s baseline explicitly requires SPF alongside DMARC and DKIM.

For business owners, the issue shows up most visibly when something goes wrong. DKIM keys expire, rotate, or are misconfigured. When that happens on a domain with no SPF, every message from every sending path fails authentication simultaneously with no fallback. Mail starts bouncing or going to spam. The root cause is not the DKIM problem — it is that SPF was never there to catch the failure. Publishing an SPF record is free and takes minutes. The only requirement is knowing what sends email as your domain, which your DMARC reports can tell you.

Data to cite

FAQ

Can DMARC work without SPF? Technically yes, if DKIM alignment passes for every message. DMARC requires either SPF or DKIM alignment to succeed — not both. But any sending path that lacks a valid DKIM signature has no fallback, and DMARC fails for that message. A domain with DMARC and no SPF is operating with one authentication channel where two are available, and one of those channels depends entirely on every sender signing correctly and every key rotating without error.

Why do 16 million domains have DMARC but no SPF? The DMARC-first deployment sequence is the most common cause. Compliance requirements name DMARC; someone publishes a DMARC record; the compliance scanner goes green. SPF was never required as a first step, and if DKIM is signing most traffic, the absence of SPF is invisible in the DMARC reports. The gap only surfaces when a sending path lacks DKIM or when a DKIM key fails.

What does “no SPF” mean for my deliverability? Receivers evaluate SPF separately from DMARC and use the result in their own reputation and filtering decisions. A missing SPF record returns a “none” result, which some receivers treat as a weaker trust signal independent of DMARC outcome. For bulk senders, Google and Yahoo’s 2024 requirements explicitly require SPF — a missing record is a compliance gap regardless of whether most mail passes via DKIM.

How do I know if my domain has both DMARC and SPF? Your SPF record is a TXT record on your organisational domain; your DMARC record is at _dmarc.yourdomain. Both are public DNS and can be checked with any DNS lookup tool. If your SPF record does not exist, nslookup -type=txt yourdomain will return no SPF result (no record starting with v=spf1). Our free check at defaults.exposed reads both records and shows you their status in plain English.

What is the difference between SPF and DKIM? SPF authorises specific IP addresses and services to send mail for your domain — it is path-based and checks the sending server’s identity. DKIM cryptographically signs the message content using a key held by the sending server — it is content-based and the signature survives forwarding if the signed headers remain intact. Both feed into DMARC alignment; a complete authentication stack requires all three.

What is the trend — is this gap growing or shrinking? The August 2026 census establishes the first baseline for this specific overlap: 16.2 million domains with DMARC but no SPF. Future editions will track whether the gap closes as Google and Yahoo’s requirements pressure bulk senders to complete their stacks. The gap is likely to be persistent for non-bulk-sender domains, which face no delivery consequence for missing SPF.

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

Check your domain free at defaults.exposed — see whether your domain has both SPF and DMARC deployed, or whether you are one of the 16 million running with half an authentication stack. Takes 30 seconds. No account needed.

Data source: defaults.exposed August 2026 census, methodology v9, as of 2026-08-16. 376,928,750 total graded. SPF present: 146,413,297. DMARC any: 75,571,248. Both SPF and DMARC: approximately 59,332,569. DMARC without SPF: approximately 16,238,679. The overlap figure is an approximation derived from per-domain check joins. References: RFC 7489 (DMARC), RFC 7208 (SPF), RFC 6376 (DKIM), Google/Yahoo bulk sender requirements February 2024, CISA BOD 18-01, NIS2 Directive 2022/2555, DORA Regulation 2022/2554, ENISA email security guidance.

How to cite this report

Press / blog: defaults.exposed (2026). DMARC Without SPF: 16 Million Domains With Half an Email Authentication Stack. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/en/articles/dmarc-without-spf-16-million-domains-2026

Academic: defaults.exposed. (2026, August 20). DMARC Without SPF: 16 Million Domains With Half an Email Authentication Stack. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/en/articles/dmarc-without-spf-16-million-domains-2026

In-line citation: (defaults.exposed, August 2026 Domain Security Census, n=75,571,248 DMARC records; SPF overlap n=59,332,569)

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