The domains actively sending mail with no authentication at all

If a company's mail domain has no SPF alignment and no DMARC policy, anyone on the internet can send email that looks like it came from that domain — landing in a customer's inbox with the real "From" address, no red flag, no warning banner. For a small SaaS company that means invoices, password resets, and account notices are all fair game for a forger who never has to touch the company's actual mail server.

That's not a hypothetical middle ground. It's closer to binary: either a domain publishes an SPF record and a DMARC policy that mail providers will actually enforce, or it doesn't — and a domain that doesn't is openly spoofable today, this hour, by anyone who bothers to try.

What we found

We ran a passive scan across our aggregate of 1,054 US B2B SaaS companies with 5–50 employees (population refreshed 2026-09-04), checking public DNS records only — nothing that touches a mailbox, a login, or a server. 14.4% of that population, 152 companies, are actively sending live mail from a domain with no SPF and no DMARC enforcement at all. Not a weak DMARC policy, not "p=none" with reporting turned on and nothing else — zero authentication a receiving mail server can check.

This is a k-anonymised aggregate. No company is named, and none of this comes from touching anyone's systems — every data point here is a public DNS record any resolver can already see.

A concrete example

Picture a 20-person project-management SaaS that's been sending customer invoices and password-reset links from billing@theirdomain.com for three years. Nobody ever set up SPF or DMARC — it wasn't on anyone's list, mail kept working, and nothing ever forced the question. Today, anyone can send a message that says From: billing@theirdomain.com, spoofing an overdue-invoice notice with a new payment link, and it lands in a customer's inbox looking exactly as legitimate as the real ones. The receiving server has no SPF record to check the sender against and no DMARC policy telling it what to do with a failure, so it has no basis to flag or reject anything. The forged mail is indistinguishable from the real thing until a customer clicks.

What to actually do about it

• Publish an SPF record listing every service authorized to send as your domain — your mail provider, your CRM, your invoicing tool, your transactional-email service.
• Turn on DKIM signing in each of those services and add the DKIM record to DNS — SPF alone breaks the moment mail gets forwarded.
• Publish a DMARC record, even starting at p=none, so you can see in the reports who's actually sending as your domain before you enforce anything.
• Once the reports show only your real senders, move DMARC to p=quarantine and then p=reject — that's the setting that actually stops spoofed mail from reaching an inbox.
• Recheck every time you add a new tool that sends mail on your behalf — a new invoicing or marketing platform missing from your SPF record is a new gap, not a coincidence.

If you don't know whether your own domain sits in that 14.4%, that's exactly the kind of gap our External Security Posture Assessment finds — email authentication is one line item in a full passive read of what your company already exposes to the internet. See what it checks.