The startups publishing no SPF at all

If you run a small B2B SaaS company, someone on your team has almost certainly sent an invoice, a password reset, or a "your trial is ending" email through a third-party tool (Stripe, SendGrid, HubSpot, whatever) that sends mail as if it came from your domain. Whether a receiving mail server trusts that email, or a spoofed lookalike, often comes down to one DNS record most founders have never looked at: SPF.

SPF (Sender Policy Framework) is a short text record published in your domain's DNS that lists which mail servers are allowed to send email on your behalf. It's not glamorous, but it's foundational: it's one of the first things a receiving mail server checks, and it's one of the easiest things for an attacker to exploit when it's missing.

What we found

We ran a passive, public-data-only scan across a sample of US B2B SaaS companies with roughly 5 to 50 employees (monthly refresh dated 2026-09-04, N = 1,054). Every observation came from information already public on the internet: DNS records and HTTP responses that any browser or mail server can see. No company is identified individually, and results are reported only in aggregate (k-anonymised) so no single domain can be picked out of the sample. This is not a penetration test or any kind of intrusive testing: it's the same kind of lookup a spam filter performs before deciding whether to trust a message.

Across that sample, 8.3% (n = 88 of 1,054) of domains publish no SPF record at all. Without one, a receiving mail server has nothing to check the sending host against: it can't tell the difference between mail from your real provider and mail from an attacker who simply typed your domain into the "From" field.

How this plays out

Consider a hypothetical 15-person SaaS company (call it "Acme Cloud," a stand-in, not a real domain we scanned) that sends product emails through one platform and support replies through another, but has never published an SPF record. Nothing stops someone from sending a fake invoice or a "your account is suspended, click here" email that appears to come from billing@acmecloud.com. Some receivers may flag it as suspicious on other signals, but without SPF, alignment isn't even something a spam filter can check: the domain owner never gave it a list of legitimate senders to compare against. That gap doesn't guarantee a message gets through, but it removes one of the checks a receiver could otherwise rely on.

If you want to know where your own domain stands, OrangeStealth's free checker at https://orangestealth.com/check runs the same kind of passive, public-data lookup and shows you your SPF and DMARC posture in seconds, no login, no scan of your systems. For a broader look at what's publicly visible about your company's attack surface, our External Security Posture Assessment covers this and more, passively and externally, without ever touching your infrastructure.

What to actually do about it

• Inventory every service that sends mail as your domain: your product, your CRM, your support desk, your marketing tool, your invoicing platform. Most founders are surprised how many there are.
• Publish an SPF record that lists only those senders. Each provider documents the exact include line to add: it's usually a five-minute DNS change.
• Add DKIM signing for each sending platform if you haven't already. DMARC alignment only requires an aligned SPF pass or an aligned DKIM pass, not both, so DKIM gives you a second path to alignment if SPF ever breaks.
• Add a DMARC record starting at p=none with a reporting address (rua=) so you can see who is sending mail as your domain before you tighten anything. p=none by itself doesn't request enforcement from receivers, and without a reporting destination configured you won't get reports at all.
• Only move toward quarantine or reject once you've confirmed every legitimate sender is aligned. That's a policy you're requesting receivers honor, not a guarantee, and it's the step most teams skip too early or never take.