SPF softfail: re-measured for October 2026

The October 2026 refresh puts SPF softfail back under the microscope. In the US B2B SaaS 5-50 population, sample size N = 1124, 69.2% of domains ended their SPF policy with ~all (n=778). This re-measures the same population covered previously, but the supplied aggregate contains no earlier result. It establishes the current position without showing whether softfail became more or less common.

For a business sending invoices, account notices or sensitive client correspondence, the practical question is whether its email policy reflects every legitimate sender. A published SPF record can look complete while leaving that question unresolved.

What that final character actually means

SPF lets a domain identify the servers authorised to send email using its envelope sender domain. A receiving mail server checks the sending server against that published policy. The mechanism at the end describes how to classify a sender that matched none of the preceding mechanisms.

An ending of ~all produces a softfail result. It says the sending server is probably not authorised, while signalling that the receiver should not reject the message solely because of that SPF result. It does not command acceptance or guarantee delivery. Spam filtering, DMARC and other receiver policies can still affect what happens.

An ending of -all produces an SPF fail result for unmatched senders. That is a firmer statement of authorisation, but changing the character does not independently guarantee rejection. Receivers apply their own handling policies, and SPF is only part of email authentication.

That distinction matters when someone proposes a quick fix. The character is easy to change. Establishing that the record accurately covers legitimate mail takes more care.

What this measurement can tell us

Methodology: This is OrangeStealth's monthly refresh 20261019 of the US B2B SaaS 5-50 population, with sample size N = 1124. The aggregate was generated on 2026-10-19 using passive, public-data-only observations. Findings are k-anonymised, and no company is named. The reported measure is the presence of an SPF softfail policy, not observed message delivery, abuse or compromise.

Public DNS shows the policy a domain publishes. It does not establish whether the business has finished its sender inventory, whether a vendor signs messages correctly, or whether a receiver accepted a particular message. The aggregate also does not explain why each domain uses softfail. A migration, an overlooked configuration or a deliberate operational choice could require different follow-up.

The useful finding is therefore a review opportunity: check whether the published policy still matches how the business sends mail.

A hypothetical invoice workflow

Imagine a business that sends everyday correspondence through its email provider and invoices through a separate billing platform. Its SPF record covers the email provider, but the billing platform's configuration has never been checked.

Replacing ~all with -all would change the SPF result for unmatched sending servers. Whether legitimate invoices encounter delivery problems would also depend on the sending configuration, DKIM, DMARC alignment and receiver policy. The responsible next step is to inspect real messages from both services before tightening anything.

DMARC passes when either SPF passes with alignment or DKIM passes with alignment. Both are not required. Conversely, an SPF pass alone does not establish DMARC alignment with the domain visible in the From address.

What to actually do about it

• Read the current public configuration. Use the free public checker as a starting point. Treat its findings as observations to investigate, rather than proof that your email has been abused.
• Confirm every legitimate sending service. Include billing, customer support, marketing and any other system sending on your behalf. Have the responsible administrator compare vendor requirements with the published configuration.
• Check authentication and alignment on actual messages. Review message headers from legitimate workflows. Confirm which mechanism provides an aligned pass before suggesting any SPF or DMARC enforcement-policy change.
• Make policy changes with evidence and monitoring. DMARC p=none requests no DMARC-based enforcement; receivers may still block mail under other policies. Reports require a configured reporting destination. Quarantine and reject express the domain owner's requested policy, rather than guaranteed receiver actions.

An External Security Posture Assessment can place these public email settings in the context of a broader passive, external-only review. It is separate from the free checker and cannot establish internal mail behaviour from DNS alone.

If your domain ends in ~all, start by finding who owns the sender inventory. Confirm what legitimately sends for your business, then make the published policy match that evidence.