Defaults.Exposed

Defaults.Exposed › Reports

SPF Hard Fail vs Soft Fail: Why 82 Million Domains Are Using the Weaker Setting

Published

SPF Hard Fail vs Soft Fail: Why 82 Million Domains Are Using the Weaker Setting

Of the 146,413,297 domains that publish an SPF record in the August 2026 census, 82,539,695 (56.4%) end their record with ~all, the soft fail qualifier. By contrast, 56,268,491 (38.4%) end with -all, the hard fail qualifier. The remaining fraction uses ?all (neutral) or +all (pass all, which is effectively a disabled policy).

The difference between ~all and -all is not cosmetic. It determines whether your SPF record actually prevents unauthorised senders from delivering mail, or merely annotates their messages as suspicious before most receivers quietly ignore the annotation.

What the Qualifiers Actually Mean

RFC 7208, the SPF specification, defines four qualifiers that can prefix the all mechanism at the end of an SPF record.

-all (hard fail) instructs the receiving server to treat mail from any source not explicitly listed in the SPF record as a policy failure. The RFC defines the result as “fail,” and DMARC treats this as a definitively failed authentication channel on the SPF side.

~all (soft fail) instructs the receiving server to treat mail from unlisted sources as a “soft fail” result — suspicious but not definitively rejected. In practice, most receiving servers treat soft fail identically to pass for delivery purposes. The message arrives in the inbox. The soft fail annotation appears in the Received-SPF header, where it is read by no one except forensic investigators after the fact.

?all (neutral) explicitly declines to make a policy statement. The RFC describes this as “neither Pass nor Fail.” It provides no protection whatsoever and should not appear in a production SPF record that has security intent.

+all (pass all) explicitly passes mail from any source. It defeats the purpose of SPF entirely.

The census finds 7,743 domains with SPF permerrors: records that exceed the RFC 7208 limit of 10 DNS lookups during evaluation. A permerror result causes SPF evaluation to fail for all senders on that domain, including legitimate ones. It is not a soft failure — it is a broken record that neither passes authorised mail nor blocks unauthorised mail cleanly.

Why Soft Fail Is So Widespread

The prevalence of ~all over -all has a documented origin. Early SPF deployment guidance, including guidance from major mail providers and hosting company documentation in the 2010s, recommended ~all as a safer starting point. The reasoning was pragmatic: hard fail (-all) will cause delivery failures for any legitimate sending path that is not enumerated in the SPF record. If an organisation has shadow IT services, forgotten newsletter platforms, or legacy mail infrastructure that is not documented in the SPF record, switching to -all will cause those messages to fail SPF and potentially be rejected at enforcing receivers.

Soft fail was positioned as a monitoring posture: deploy ~all to observe which sending sources are in use, then tighten to -all once all legitimate senders are enumerated. In practice, most organisations never completed the second step. The ~all record was deployed and the subsequent tightening was never scheduled, never prioritised, and never done.

The result, visible in the August 2026 census, is 82.5 million domains locked in a permanent soft fail posture that was originally intended as a temporary observation window.

The DMARC Interaction

The relationship between SPF qualifiers and DMARC adds another dimension to the analysis.

DMARC (RFC 7489) takes the SPF result and the DKIM result and applies its policy based on alignment: whether the From header domain aligns with the domain that passed SPF (envelope from) or DKIM (d= tag). If SPF returns a soft fail, DMARC treats that as a failed SPF channel for alignment purposes. The DMARC policy then determines what happens next.

For a domain with DMARC at p=reject and SPF at ~all, a message that fails SPF alignment but has valid DKIM alignment will still pass DMARC. DKIM is an independent authentication channel. The SPF soft fail does not propagate to a DMARC failure if DKIM alignment succeeds.

However, for a domain that relies on SPF as its primary (or only) DMARC alignment mechanism, soft fail creates a real gap. DMARC alignment requires the SPF result to be “pass” (not soft fail) for the envelope domain to align. An SPF ~all result produces a “softfail” result, which DMARC does not treat as a pass for alignment. In most real-world DMARC implementations, a softfail SPF result combined with a missing or failing DKIM result produces a DMARC failure, but with p=none the receiver still delivers the message.

The practical upshot: ~all is weaker than it appears on the SPF side. For organisations with enforcing DMARC and working DKIM across all mail streams, the SPF qualifier matters less. For the substantial cohort of domains that have SPF but no DMARC, or DMARC at p=none, soft fail provides no meaningful protection because no enforcement mechanism sits behind it.

Who Should Move to Hard Fail

The case for moving from ~all to -all is clear for organisations that have completed a full audit of their sending infrastructure. The audit requires answering one question: what servers, services, and third-party platforms send email using this domain, and are all of them listed in the SPF record?

For organisations that can answer that question confidently, the move to -all is a single DNS record update. It increases the strength of SPF from advisory to enforcement. Combined with DMARC at p=reject, it closes the door on spoofed messages that rely on the SPF channel.

For organisations that cannot answer the question confidently, the path is:

  1. Enable DMARC reporting at p=none with a rua address that delivers aggregate reports.
  2. Review the aggregate reports for 30 to 60 days to identify all sending sources.
  3. Verify that every source is covered by the SPF include: chain.
  4. Update the SPF record to end with -all.
  5. Move DMARC to p=quarantine, then p=reject.

The aggregate reports provided by DMARC (RFC 7489, Section 7.2) are the authoritative source for this audit. They show every source IP that sent mail claiming to be from the domain, whether the SPF check passed or failed, and whether DKIM was present and aligned. Any source appearing in the reports that is not in the SPF record represents either a legitimate sender not yet enumerated (fix the SPF record) or an illegitimate sender (evidence that enforcement is needed).

The Permerror Problem

The 7,743 domains with SPF permerrors represent a distinct failure class. RFC 7208 limits SPF evaluation to 10 DNS lookups, a constraint designed to prevent SPF from being used as a DDoS amplification vector against DNS infrastructure. The include: mechanism, which pulls in SPF records from third-party providers, is the primary way operators exceed this limit. Each include: costs one lookup, and each included record may itself contain further include: directives that consume additional lookups recursively.

An organisation that has added multiple email service providers (ESP), a CRM system, a transactional email platform, a marketing platform, and a security scanning service to its SPF record via include: directives can easily exceed ten lookups in total. The resulting permerror causes SPF to fail for all senders, including legitimate ones.

The fix for permerror is SPF flattening: replacing the nested include: chain with a flat list of the IP addresses or CIDR ranges that the included records ultimately resolve to. This must be maintained when any included service changes its IP ranges, which makes automated SPF management tools valuable for complex sending environments. Several commercial tools and open-source scripts exist for this purpose.

Regulatory and Framework Context

No major regulatory framework specifies the SPF qualifier explicitly. GDPR Article 32 requires appropriate security measures for email as a channel carrying personal data. CISA Binding Operational Directive 18-01 requires DMARC enforcement for federal agencies but does not mandate SPF hard fail independently. Google’s and Yahoo’s bulk sender requirements (February 2024) require SPF alignment for DMARC compliance but do not specify the qualifier.

The practical guidance from CISA and NCSC operational guidance points consistently toward hard fail as the intended endpoint. The NCSC’s email security guidance describes the complete authentication stack as SPF with -all, DKIM signing, and DMARC at p=reject. Any qualification short of that is described as incomplete.

PCI-DSS 4.0 Requirement 12.1.3 requires that security policies address email security for cardholder data environments. PCI-DSS assessors increasingly treat the SPF qualifier as within scope for evidence reviews, particularly in environments where email is a channel for cardholder communications.

The Gap Worth Closing

The August 2026 census shows 82.5 million domains in a soft fail posture that was meant to be temporary. For the majority, no technical barrier prevents moving to hard fail. The barrier is administrative: no one has scheduled the work.

The tools exist. The data, in the form of DMARC aggregate reports, is available to every domain that has published even a p=none DMARC record. The standards are published. The regulatory direction is clear.

Soft fail was a starting point, not a destination.

What this means

For IT managers, the operational question is whether anyone on your team has revisited your SPF record since it was first published. If the answer is “not recently” or “we’re not sure,” the most likely finding is ~all — originally set as a precaution during testing, never updated. Soft fail gives you no protection against unauthorised sending from your domain; it gives you a header annotation that the vast majority of receiving servers ignore at delivery time. The 82.5 million domains in this posture are not meaningfully different from domains with no SPF enforcement at all.

For security teams, the DMARC interaction is the critical point. If your domain relies on SPF as its primary DMARC alignment path — because DKIM is inconsistently deployed or not all your sending infrastructure signs — then ~all means a soft fail result on the SPF side, which DMARC does not treat as an alignment pass. The gap only matters when DKIM also fails or is absent, but that is exactly the scenario where enforcement most needs to hold. A domain at p=reject with DMARC but soft fail SPF is not fully closed.

For business owners, the path from soft fail to hard fail is a single DNS record change — replacing ~all with -all at the end of your SPF record. The prerequisite is knowing what sends email as your domain, which DMARC aggregate reports answer if you have published even a p=none record. The work is an afternoon, not a project. The risk of not doing it is that unauthorised senders continue to reach inboxes with mail claiming to be from you.

Data to cite

FAQ

What is the difference between SPF hard fail and soft fail? Hard fail (-all) tells receiving mail servers to treat messages from unauthorised sources as a policy failure and reject or block them. Soft fail (~all) marks them as suspicious but instructs servers to deliver them anyway. In practice, most receiving servers ignore the soft fail annotation at delivery time, making ~all provide little protection against spoofed or unauthorised mail.

Why do 82 million domains still use soft fail? Soft fail was the recommended starting point during SPF deployment in the 2010s — a safe observation window before tightening to hard fail. Most organisations never completed the second step. The record was set once and not revisited. The August 2026 census shows 82.5 million domains locked in that temporary posture permanently.

Does soft fail SPF affect my DMARC enforcement? Yes, in specific scenarios. DMARC requires SPF alignment to return a “pass” result, not a soft fail. If your DMARC policy relies on SPF alignment and DKIM is absent or fails, a soft fail SPF result means no DMARC alignment succeeds and enforcement depends entirely on the DMARC policy level. Domains at p=none will deliver the message regardless.

How do I move from soft fail to hard fail? Replace ~all with -all at the end of your SPF record. Before doing so, review DMARC aggregate reports (available if you have published any DMARC record, even p=none) to confirm every legitimate sending source is listed in your SPF record. Any source not listed will begin failing SPF — which is the signal you want, because it means an unlisted sender is reaching your recipients.

What is an SPF permerror and how do I fix it? A permerror occurs when evaluating your SPF record requires more than 10 DNS lookups — typically caused by too many include: directives pointing to third-party mail providers. Receivers treat a permerror as an SPF failure for all senders. The fix is SPF flattening: replacing the include: chain with a direct list of IP addresses, which can be done using commercial or open-source SPF management tools.

What is the trend compared to July 2026? The August 2026 census is the first edition to report soft fail and hard fail counts at this level of detail across 146 million SPF records. Future editions will track whether the soft fail cohort declines as organisations complete their deployments. The 82.5 million figure is the August 2026 baseline.

Data source: defaults.exposed August 2026 census, methodology v9, as of 2026-08-16. 376,928,750 domains graded from approximately 432 million scanned. SPF total: 146,413,297. SPF soft fail (~all): 82,539,695 (56.4% of SPF publishers). SPF hard fail (-all): 56,268,491 (38.4% of SPF publishers). SPF permerror: 7,743. References: RFC 7208 (SPF), RFC 7489 (DMARC), CISA BOD 18-01, NCSC email security guidance, Google/Yahoo bulk sender requirements February 2024.

Check your domain free at defaults.exposed — see whether your SPF record ends with hard fail or soft fail, and what your overall email authentication posture looks like against the August 2026 census baseline. Takes 30 seconds. No account needed.

How to cite this report

Press / blog: defaults.exposed (2026). SPF Hard Fail vs Soft Fail: Why 82 Million Domains Are Using the Weaker Setting. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/en/articles/spf-hard-fail-vs-soft-fail-2026

Academic: defaults.exposed. (2026, August 20). SPF Hard Fail vs Soft Fail: Why 82 Million Domains Are Using the Weaker Setting. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/en/articles/spf-hard-fail-vs-soft-fail-2026

In-line citation: (defaults.exposed, August 2026 Domain Security Census, n=146,413,297 SPF 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