Only 1 in 5 Startups Have SPF That Actually Rejects Forgeries

Last time we looked at DMARC and found that 45% of startups publish a policy that protects nothing. DMARC has a partner that does half the work — SPF — and when we checked the same 705 companies, SPF turned out to be in even worse shape. Most startups have an SPF record. Almost none of them have one that actually stops a forgery.

We passively scanned 705 US-based B2B SaaS companies (YC-seed stage, 5–50 employees) using only public data. Here's how their SPF records break down:

Only about 1 in 5 — 20.6% — have an SPF record that actually rejects unauthorized senders (it ends in -all). The other 79% either have no SPF, a broken one, or the far more common problem: ~all "softfail," which marks a forged message as suspicious and then delivers it anyway.

What "softfail" really means

SPF ends in one of a few ways, and the last two characters decide everything. -all ("hardfail") tells receiving mail servers to reject anything not on your approved list. ~all ("softfail") tells them to accept it but flag it. In practice, "flag it" usually means it still lands — often right in the inbox. So a domain on ~all looks configured, passes a quick glance, and still lets an impersonator through.

Softfail is the right starting point while you're figuring out who legitimately sends your mail — exactly like DMARC's p=none. And exactly like p=none, it's where almost everyone stops. 68.8% of the companies we scanned are parked there.

The quieter failures

• 8.2% publish no SPF at all — any server on the internet can send mail as them, full stop.
• 1.8% publish more than one SPF record. The spec allows exactly one; receivers treat two as a permanent error and SPF fails open — the same result as having none, while looking configured. This one is nasty because every tool that doesn't specifically check for it reports "SPF: present."
• A handful more use ?all ("neutral"), which explicitly tells receivers to have no opinion — spoofed mail is penalized by exactly nothing.

Why SPF and DMARC only work together

Here's the trap that catches teams who did some of the work. DMARC only enforces if SPF or DKIM passes and aligns with your domain. A softfail SPF plus a monitor-only DMARC is two half-measures that add up to zero protection — and that combination is the single most common configuration we see. If you fixed one and not the other, you may still be wide open.

What to actually do about it

• Publish exactly one SPF record, listing every service that legitimately sends your mail (your mail provider, marketing tool, invoicing app, ticketing system). Two records is a silent failure — consolidate to one.
• Watch your DMARC reports (you did add a rua= address, right?) until every real sender is accounted for.
• Then move the ending from ~all to -all — the setting that actually rejects a forgery. Do it alongside DMARC p=reject; that's the pair that closes the door.
• Mind the 10-lookup limit. SPF is capped at 10 DNS lookups; past it, SPF silently fails open. Adding one more sending service can quietly break a record that was working, so count your lookups when you change it.

How we know this

These numbers come from a passive external scan of 705 companies fitting the profile above, run in August 2026. We read only public information — public DNS records, public certificate-transparency logs, and one ordinary request to each public homepage. No scanning, probing, or logins, and no individual company is identified in the dataset. Aggregates are reported only where at least five companies share a result. It's the same passive check we run as the first step of an external security posture assessment.

Not sure whether your SPF actually rejects — or just softfails? Our External Security Posture Assessment checks your SPF, DMARC, DKIM, and the rest of what an attacker or an enterprise customer's security reviewer can already see, and hands you a plain-English report with the fixes. Passive and external-only; we never touch your systems.