The SPF setting that looks done but rejects nothing

If your SPF record ends in ~all, it can feel like a settled line on the checklist — the DNS record exists, some tool somewhere said "SPF: configured," done. It isn't done. That single tilde is the difference between a mail server that blocks a forged message and one that shrugs, flags it as questionable, and delivers it to the inbox anyway.

For a small B2B SaaS company, that gap usually stays invisible until it's used against a customer. Someone forges a message from "billing@yourcompany.com," asks a customer to update payment details, and the receiving mail server never gets a real vote in the matter — because your own SPF record told it not to worry too much either way.

What "softfail" actually tells a mail server

An SPF record ends with an instruction to receivers. -all ("hardfail") means: reject anything not from an address on the approved list. ~all ("softfail") means: accept it, but mark it as questionable. In practice, "mark it as questionable" rarely stops delivery on its own — plenty of receiving systems still route softfail-flagged mail straight to the inbox, often with no warning visible to the recipient. A domain on ~all passes a glance-level check ("do they have SPF? yes") while doing almost nothing to stop a forged sender from landing.

What we found

We ran a passive, external-only scan of 705 US-based B2B SaaS companies at YC-seed stage, 5–50 employees — reading only public DNS records, nothing installed and nothing logged into. Results are reported in aggregate and k-anonymised: no individual company is named. In that population, 68.8% (485 of 705) end their SPF record in ~all. That's not a fringe misconfiguration — it's the modal setting. More companies in this population softfail than do anything else with SPF.

Put differently: for a majority of small B2B SaaS companies, the SPF record sitting in DNS right now is one character — a tilde instead of a dash — away from actually rejecting a forged sender.

A realistic version of this

Picture a 30-person invoicing SaaS. Their SPF record correctly lists their mail provider and their marketing platform, and ends in ~all. Someone spoofs a message from their domain, targeting one of their customers with a fake "updated bank details" note. The customer's mail server checks SPF, sees the softfail signal, and — because softfail is explicitly a "deliver but flag" instruction, not a "block" one — lets it through anyway. The invoicing company did the DNS work. It just never finished it, and finishing it costs nothing extra to publish.

What to actually do about it

• Check what your SPF record currently ends in. A DNS TXT lookup on your domain shows it in seconds — look for ~all or -all at the very end.
• Confirm every legitimate sender is listed first. Mail provider, invoicing tool, marketing platform, support desk — anything that sends as your domain needs to be in the record before you tighten it.
• Watch DMARC reports for a stretch before flipping it. If DMARC reporting is on, let it run until you're confident nothing legitimate is being missed.
• Change ~all to -all. That's the entire fix — one character, once the sender list is confirmed complete.
• Recheck after adding any new sending tool. A new tool that never gets added to the SPF record is exactly how a correct -all record quietly turns into a new softfail problem.

This is one setting out of dozens we look at in an External Security Posture Assessment — a passive, external-only look at what an attacker, or an enterprise customer's security reviewer, can already see about your company from the outside. If you don't know what your own SPF record currently ends in, that's usually the fastest five minutes of the whole review.