SPF Is Everywhere. Strong Email Protection Is Not.

Executive takeaway

Publishing SPF is a starting point, not proof that a domain is protected. Large scans find widespread softfail policies, evaluation errors, and authorizations broad enough to create opportunities for attackers. But changing ~all to -all is not a complete fix: receiving servers decide how to handle results, and DMARC alignment matters. Teams should inventory legitimate senders, validate SPF evaluation, narrow unnecessary permissions, and use DKIM and DMARC reports to guide enforcement. Measure working protection and reliable delivery—not just whether a DNS record exists.

The SPF checkbox hides three different questions

In DMARCguard’s 5.5-million-domain scan, 56.0% of all scanned domains had valid SPF, while 53.6% of valid SPF records used softfail (~all). Those percentages have different denominators: one measures coverage across domains; the other describes policy choices among valid records.

SPF, or Sender Policy Framework, is a DNS-published list of infrastructure authorized to send mail for a domain. Receiving servers check a message’s sending IP address against that list, using the domain in its technical return address—not necessarily the From address readers see.

That makes “SPF enabled” an incomplete answer. Three separate tests matter:

• Presence: Does the domain publish an SPF record?
• Validity: Can receivers interpret and evaluate it successfully, including within DNS-lookup limits?
• Policy strength: What result does it specify for unauthorized senders, and how does that fit the wider enforcement policy?

Authorization scope is an essential companion check: how much infrastructure does the record permit? A strict ending cannot compensate for an oversized allow list, while softfail alone does not reveal whether DMARC—the policy layer connecting authentication to the visible sender—enforces protection.

The comparison below shows why apparently conflicting adoption headlines can coexist. They count different populations and do not all measure validity. Source: DMARCguard, SPF Supply Chain 2026

Comparison figure: what each headline counts.

Study	Reported SPF rate	Population and measure
DMARCguard	56.00%	5,499,028 Tranco domains; valid SPF
SpamCipher	62.80%	Resolvable top-million domains; publication
Lazy Gatekeepers	56.50%	12.8 million domains collected across five months; publication

Historical measurements add context, not a like-for-like growth curve. Changes in domain lists, sample size, and validation criteria prevent treating these snapshots as one continuous series.

Historical figure: different snapshots, different denominators.

Measurement	Reported rate
2018 Alexa analysis	47% adoption
Fortra, Q2 2025, top 10 million domains	36.7% syntactically valid SPF
DMARCguard, 2026	56.0% valid SPF

Internet-wide adoption is useful background, not a security score for your domain. The practical question is whether your deployment limits unauthorized sending without breaking legitimate mail.

Contrasting headline SPF publication and softfail/hardfail usage across DMARCguard’s 5.5M-domain dataset, SpamCipher’s top-million scan, and Lazy Gatekeepers’ 12.8M-domain study. Method: Table cells use published adoption percentages and policy breakdowns from the three studies, aligned on comparable metrics where definitions are compatible.

Line series track SPF deployment from mid-2010s to 2026 across Alexa top 1M, multi-top-list scans, and Tranco-based measurements. Method: Adoption percentages are taken from Foster’s Alexa study, SIGCHI-format historical measurements, multi-top-list scans by Korczynski et al., Lazy Gatekeepers’ 12M-domain dataset, and SpamCipher’s 2026 top-million scan, plotted chronologically by study year.

What softfail really says—and what it does not

The difference between ~all and -all is a statement about authorization, not a guaranteed delivery outcome. At the end of an SPF record, ~all means “a sender not matched by the preceding rules is probably unauthorized”; -all means “that sender is unauthorized.”

These results are called softfail and hardfail, respectively. Neither promises a particular mailbox destination: softfail does not automatically mean “send to spam,” and hardfail does not guarantee rejection, because the receiving system applies its own policies.

Softfail is nevertheless common. Among SPF-publishing domains in its scanned sample, SpamCipher’s 2026 review reports:

• 55.7% using softfail (~all).
• 38.7% using hardfail (-all).
• About 3.0% classified as permissive, such as configurations using +all.
• 1.6% carrying multiple-record errors that invalidate SPF.

Those are reported categories, not a complete, cleanly exclusive breakdown to normalize into a perfect 100%. In particular, multiple-record errors describe a validity problem, whereas softfail and hardfail describe authorization results; treating them as equivalent measures of protection would blur an important distinction.

Softfail alone does not establish that a domain is unprotected. As Valimail’s DMARC guidance explains, DMARC connects authentication to the domain in the visible From address and lets owners request monitoring, quarantine, or rejection when its checks fail.

A domain can therefore publish ~all while requesting DMARC enforcement against messages that fail those checks. Conversely, -all alone does not establish that DMARC is enforced; neither SPF softfail nor hardfail counts as an SPF pass for DMARC, but a passing DKIM signature aligned with the visible From domain can still satisfy DMARC.

There are legitimate reasons to proceed cautiously, particularly an incomplete inventory of third-party senders. A marketing platform, support service, or transactional-mail provider missing from that inventory may send genuine messages that fail SPF, making tighter handling disruptive before the omission is fixed.

That is a possible operational explanation, not a motive established by the scans. A snapshot of a DNS record cannot tell whether an operator is actively investigating missing senders or has forgotten the configuration.

The practical distinction is deliberate monitoring versus indefinite neglect. Monitoring should have an owner, reviewed authentication reports, and a migration plan with clear criteria for stronger enforcement—not simply a standing instruction to replace every ~all with -all.

Radial segments illustrate the predominance of softfail over hardfail in SPF records, combining reported shares from DMARCguard and SpamCipher for illustrative comparison. Method: Percentages are taken directly from DMARCguard’s softfail rate and SpamCipher’s breakdown of hardfail, softfail, permissive, and invalid records; values are presented side by side as indicative rather than aggregated.

A valid-looking record can still break

In Ashiq and colleagues’ 17-month study of 176 million domains, fewer than 0.4% of SPF records had syntax errors, but 6.5% incurred excessive DNS lookups. That gap exposes an important distinction: a record can be correctly written yet fail when a receiving server tries to evaluate it.

Fortra’s Q2 2025 analysis offers corroborating evidence: it identified 110,732 SPF records exceeding the lookup limit among the top 10 million domains. This is a different population and measurement exercise—not a directly comparable rate—but it reinforces that evaluation failures are more than an edge case.

SPF evaluation involves following instructions, not simply reading a list of approved senders. The receiving server may need to retrieve another domain’s SPF policy through an include, then follow additional instructions inside that policy.

The 10-lookup limit restricts the number of DNS-triggering SPF terms encountered during an evaluation, including those reached through nested includes. It is not a simple allowance for ten email services: one provider’s include can consume several steps, while directly listed ip4 and ip6 address ranges do not consume this budget.

Exceeding that limit produces permerror, short for “permanent error”: SPF cannot reach a valid authorization result because the policy has a configuration or evaluation problem. “Permanent” describes the error category, not an irreversible condition; correcting the policy can resolve it.

A permerror is not an SPF pass, so it cannot supply the successful, aligned SPF authentication that DMARC needs. However, DMARC can also pass through aligned DKIM—a valid signature whose signing domain matches the visible From domain under DMARC’s alignment rules—so SPF failure does not automatically mean DMARC failure.

Flattening replaces lookup-based references with explicit IP addresses, reducing lookup pressure. Treat it as a managed option rather than a universal cure: those addresses must stay synchronized with providers’ infrastructure, or legitimate sending systems may lose authorization.

Before treating a record as healthy, use SPF setup guidance alongside evaluation tests to check:

• Duplicate SPF records: publish one SPF policy per domain, rather than separate policies for each service.
• Malformed mechanisms: catch misspellings, invalid address notation, and other syntax problems.
• Nested includes: inspect the full evaluation chain, not just the visible record.
• Ongoing evaluation: retest after provider changes and monitor authentication results and DMARC reports for new failures.

Source: Ashiq et al., SPF Beyond the Standard, USENIX Security 2024

Tools such as AutoSPF can help organizations validate SPF records, identify configuration errors, and support effective SPF, DKIM, and DMARC implementation as part of a broader email security strategy.

A strict gate is useless if the guest list is too broad

An SPF record ending in -all can look reassuringly strict: any sender that does not match an earlier authorization gets an SPF fail. But a strict ending cannot fix an oversized allow list—a sender already authorized by the record never reaches that final rule.

Lazy Gatekeepers reports that, in its 12.8 million-domain dataset, 34.7% of domains authorized more than 100,000 IP addresses. That finding highlights a different question from whether SPF exists or uses hardfail: how much infrastructure has actually been granted permission to send?

The include mechanism helps explain how that permission can grow: it delegates part of the authorization decision to another domain’s SPF policy, commonly a mail provider’s. That policy can reference further policies, so a short, tidy-looking record may expand into a substantial sender footprint. Its effective permissions depend on those downstream policies, not just the text the domain owner publishes.

The BreakSPF researchers demonstrated why this can matter, identifying 23,916 vulnerable domains in the Tranco top million, including 23 in the top 1,000. Under exploitable authorization conditions, they demonstrated spoofed messages passing both SPF and DMARC by abusing infrastructure trusted by the target domain’s SPF policy.

Conceptually, the weakness is a mismatch between the infrastructure a domain authorizes and who can use that infrastructure to send mail. SPF checks whether the sending IP is permitted; it does not, by itself, establish that the person using that address has permission to represent the domain.

Broad infrastructure use alone does not prove vulnerability: exploitation also depends on an attacker’s ability to send through an authorized route under suitable conditions. And an SPF pass satisfies DMARC only when the SPF-authenticated domain aligns with the visible From domain—meaning they match under DMARC’s alignment rules.

The practical response is to review expanded permissions, not merely the final qualifier: inspect included policies, confirm which services still send legitimate mail, and retire unnecessary authorizations without disrupting active senders. Narrow excessive permissions where possible; changing ~all to -all does not remove an attacker who is already inside the allow list.

SPF needs two partners: DKIM and DMARC

SPF answers a narrow question: is this server authorized to send for the domain used in the message’s delivery envelope? That is not necessarily the domain readers see in the From field, which is why SPF needs partners.

NIST’s email authentication guidance describes three complementary mechanisms. Their division of labor is straightforward:

• SPF authorizes infrastructure. It checks the connecting server against the envelope domain’s published permissions, rather than authenticating the visible From address.
• DKIM provides a verifiable domain signature. A receiving server uses the signing domain’s public key to verify the signature and detect changes to signed parts of the message.
• DMARC connects authentication to the visible From domain. It checks domain alignment—whether an authenticated domain matches the From domain under DMARC’s rules—and publishes a requested handling policy for failures.

Crucially, DMARC can pass through either aligned SPF or aligned DKIM; it does not require both paths to pass. A successful SPF check for an unrelated domain is not enough.

Forwarding shows why that alternative matters. An intermediary changes the connecting IP address, so the final receiver may see a server the original sender’s SPF record never authorized.

DKIM can survive that journey because its verification does not depend on the connecting IP. If the signature remains valid and aligned, the forwarded message can still pass DMARC despite an SPF failure.

The enforcement gap is substantial: Fortra’s Q2 2025 analysis found valid DMARC on 18.2% of its 10-million-domain sample. Of the entire sample, 10.6% published p=none, which requests no DMARC-based enforcement, while just 7.6% published p=quarantine or p=reject.

For applicable high-volume senders, mailbox-provider requirements from Gmail, Yahoo, and Microsoft call for SPF, DKIM, and DMARC, with p=none accepted as a minimum policy. Scope and thresholds differ, so these are not identical obligations for every sender—or a universal requirement to end SPF with -all.

Meeting a delivery minimum is not the same as mature protection. Publishing monitoring-only DMARC can satisfy an entry requirement without requesting action against impersonation; stronger protection requires reliable alignment and carefully managed enforcement that preserves legitimate mail.

A safer route from monitoring to enforcement

The safest route to stronger email protection is a sequence of decisions, not a blanket replacement of ~all with -all. Each step should establish whether legitimate mail will keep working—and whether unauthorized senders are actually being constrained.

1. Assign ownership and inventory every sender. Name an accountable owner, with support from DNS administrators, security, and the teams buying email services. Inventory corporate platforms, marketing tools, transactional services, scanners and other devices, plus every domain and subdomain, recording who manages each sending service. If a service’s purpose or owner is unknown, resolve that gap before treating the inventory as complete. Google’s SPF setup guidance emphasizes identifying all email senders, including third-party services, before configuring authorization.
2. Validate evaluation, not just syntax. Check that each domain has only one SPF record, and test evaluation against the 10-DNS-lookup limit, including lookups introduced by nested provider includes. Review whether each authorized address range and service is necessary and appropriately scoped; a final -all cannot undo an earlier, overly broad authorization. If evaluation fails, simplify or correct the configuration before tightening policy. Remove clearly unsafe permissive rules such as +all and narrow unjustified ranges rather than treating monitoring as permission to retain them indefinitely; UK SPF guidance provides an operational reference.
3. Confirm DKIM and inspect real traffic. Verify that legitimate services sign mail with DKIM, then review DMARC aggregate reports for authentication and alignment—the relationship between the authenticated domain and the visible From domain. Include forwarding paths in testing, because forwarding can break SPF even when the original sender was authorized. If unknown senders or legitimate authentication failures remain, investigate ownership, configuration, and message paths before advancing. Do not automatically authorize every source appearing in reports: first establish whether it belongs to legitimate traffic.
4. Coordinate enforcement when the evidence supports it. Move toward DMARC p=quarantine and then p=reject, while making an informed, separate decision about SPF hardfail. Softfail alone does not establish that DMARC is unenforced, and hardfail alone is not a guarantee of rejection. Test for delivery regressions across legitimate services and forwarding routes after changes, using reports and delivery failures to guide corrections. Canada’s email-domain protection guidance offers a framework for deploying these controls together; the pace should follow operational evidence, not a universal timetable or success threshold.

Sector-specific obligations may affect priorities and required policies. Check applicable guidance rather than assuming every organization faces the same requirements, particularly in government environments.

Keep a short operational dashboard:

• SPF coverage: domains and subdomains accounted for.
• Evaluation errors: syntax and lookup-limit failures.
• Authorization scope: unnecessary services or broad ranges.
• Qualifier distribution: interpreted alongside DMARC policy.
• Legitimate-mail alignment: including forwarded traffic.
• DMARC enforcement: monitoring, quarantine, or reject.
• Delivery failures: regressions following changes.

Measure maintained, working controls, not completed DNS checkboxes. Success means constraining unauthorized senders while legitimate mail continues to arrive.

A practical decision guide for organizations considering SPF enforcement, structured around sender inventory completeness, DMARC readiness, and sectoral risk. Method: Nodes and branches are derived as inferences from guidance in provider sender requirements, DMARC rollout best practices, and government frameworks that mandate hardfail SPF and DMARC reject policies.

Methodology

This article is a reader-friendly edition of a longer, fully cited Maxout Research report. Facts come from the sources listed below; the full research version keeps every citation.

Limitations

• Studies cover different domain populations, years, and definitions of validity; their percentages are not directly interchangeable.
• Several provider, regulatory, and 2026 statistics come through secondary summaries. Verify dates, scope, and original evidence before publication.
• Softfail and hardfail are authentication results, not guaranteed inbox, spam-folder, or rejection outcomes; receiver policy and DMARC also matter.
• DNS scans cannot establish actual delivery outcomes or prove that a configuration caused a successful phishing attack.

References

1. dmarcguard.io › research › spf-supply-chainSPF Supply Chain 2026: Email Sender Market Share Across 5.5 …
2. PDF Email Authentication at Scale: A Systematic Review and 2026 …
3. Global DMARC Adoption Trends in Q2 2025
4. How email authentication requirements are changing …
5. A Quantitative Study of the Deployment of the Sender Policy Framework
6. Lazy Gatekeepers: A Large-Scale Studyon SPF Configuration in the Wild
7. Email Domain Protection
8. Email Authentication Mechanisms: DMARC, SPF and DKIM
9. Using Sender Policy Framework (SPF) in your organisation
10. Set up SPF | Apps & integrations - Google Workspace Help
11. DMARC in government: Email security for the public sector - Valimail
12. BREAKSPF: How Shared Infrastructures Magnify
13. This paper is included in the Proceedings of the