People talk about email authentication as if it were a stack you can just “turn on.”

SPF, DKIM, DMARC, MTA-STS, BIMI. Five acronyms, five checkboxes, done.

That fantasy lasts right up until you look at how the public internet is actually configured. Then the shape becomes obvious. It is not a stack. It is a funnel. Lots of domains get through the first gate. Fewer make it through the second. By the time you ask for all five, correctly configured, you are no longer counting an ecosystem. You are counting a tiny club with paperwork.

So, the question in the title. The honest answer is that nobody can give you a clean number, and the reason is instructive. SPF, DMARC, MTA-STS and BIMI all live at predictable DNS names, so anyone can scan for them. DKIM doesn’t. Its keys sit under selector names the sender picks — google._domainkey, s1._domainkey, anything at all — and there is no way to list them. Every scan that tries to count “all five” is guessing at one of the five. What the partial measurements do agree on is the shape.

SPF: The One Almost Everyone Has (Sort Of)

SPF sits at the top of the funnel. It is the oldest of the five, the easiest to publish, and the one mail providers have nagged about the longest. That sounds great until you look at how the records are configured.

Many end in ~all — softfail. On its own, softfail means receiving servers can, and often do, deliver the email anyway. That isn’t automatically wrong: under DMARC, a softfail still counts as “SPF did not pass,” and DMARC is where the enforcement belongs. But a domain with ~all and no enforcing DMARC has a record that technically exists and protection that mostly doesn’t.

Then there’s the 10-lookup limit. SPF records can include other domains’ records via include: mechanisms. Each include triggers DNS lookups. Exceed 10 in total and SPF returns a permanent error instead of a pass. Nothing bounces back to warn you. Large organizations hit this all the time — multiple email service providers, marketing platforms, CRM tools, each requiring an include:. The record grows. It breaks. Nobody notices until someone reads the DMARC reports.

DKIM: Where the Self-Hosted Drop Off

DKIM uses cryptographic signatures. The sending server signs the body and a chosen set of headers with a private key. The public key lives in DNS. The receiving server verifies.

If you use Google Workspace or Microsoft 365, DKIM is close to a checkbox. The provider manages the keys. You add a DNS record or two. It works.

If you self-host, or use a patchwork of appliances and SaaS senders, DKIM becomes a key management problem. Each sending system needs its own selector and key pair. Keys should be rotated periodically. A missing or rotated-out key means signatures stop verifying, and nobody gets an error message.

Because selectors can’t be enumerated, DKIM is the hardest of the five to count. The best attempt I know of is a 2022 USENIX Security paper that leaned on five years of passive DNS data and hundreds of millions of real signatures instead of guessing: it found that 28.1% of the Alexa Top 1 million domains had enabled DKIM, and that 2.9% of those were misconfigured. Cloud defaults drag adoption upward. Everyone else gets to discover that crypto is easy compared with lifecycle management.

DMARC: The Policy That Stays on Training Wheels

DMARC ties SPF and DKIM together with a policy. Publishing a DMARC record got a big push in February 2024, when Gmail and Yahoo began requiring one from bulk senders. Look at what they required, though: a record. A p=none policy satisfies the rule.

That’s the lopsided part. Scan after scan finds large numbers of domains sitting at p=none — monitor, report, change nothing.

Moving from p=none to p=reject requires reading your DMARC reports, identifying every authorized sender, making sure they pass either SPF or DKIM with alignment, and flipping the switch. Most organizations start that process and never finish. A monitoring-only record is a waypoint, not a destination. Too many domains built a house at the waypoint.

MTA-STS: The One Nobody’s Heard Of

This is where the funnel goes off a cliff.

MTA-STS ensures email is delivered over an encrypted, verified TLS connection. Without it, SMTP’s STARTTLS upgrade is opportunistic — a man-in-the-middle can strip the encryption and email gets delivered in plaintext. Neither sender nor recipient knows.

MTA-STS fixes this by requiring a policy file at https://mta-sts.example.com/.well-known/mta-sts.txt plus a DNS TXT record. The policy says: only deliver to my servers over verified TLS.

Adoption? Rare. Outside the big mailbox providers you mostly won’t find it.

The problem is effort-to-benefit ratio. You need an HTTPS endpoint, a policy file, a DNS record, and they need to stay in sync. The protection you get — encrypted mail delivery — is something most people assume is already happening. (It often isn’t.) The attack it prevents — TLS stripping — is real but not keeping anyone awake at night.

MTA-STS also has zero visibility to end users. There’s no indicator saying “this email was delivered securely.” Nobody gets credit for deploying it. Nobody gets blamed for not deploying it.

BIMI: The Velvet Rope

BIMI puts your brand logo next to your emails in the inbox. Requirements: DMARC at p=quarantine or stronger, a published BIMI record, a logo in a restricted SVG format, and — for Gmail and Apple Mail — a mark certificate. Apple wants a Verified Mark Certificate, which in turn needs a registered trademark; Gmail also accepts the newer Common Mark Certificate. Yahoo will show a logo without one.

Those certificates typically cost from several hundred to well over a thousand dollars a year, depending on the issuer.

Adoption is tiny. A small business isn’t paying that to get a logo next to its emails. Many large enterprises aren’t either.

The Bottom of the Funnel

Put the gates in order, from most common to least:

  • SPF record: common
  • DKIM: common wherever a cloud provider set it up, hard to count everywhere else
  • DMARC record: common, and more so since the 2024 bulk-sender rules
  • DMARC at enforcement: much less common
  • MTA-STS: rare
  • BIMI: rarer still

Now ask for all five, properly configured — SPF inside the lookup limit, aligned DKIM, DMARC at p=reject, MTA-STS in enforce mode, and BIMI with a mark certificate. I’d bet on a fraction of a percent of domains. That is a bet, not a measurement; nobody has published a scan that can see all five, for the DKIM reason above. But every gate on the way down is narrower than the one before it, and the last two are very narrow.

That’s not a funnel. It’s a sieve.

Why the Funnel Breaks

Each standard was designed by different groups at different times to solve different problems. They weren’t designed as a unified system. There’s no single “enable email security” switch.

The complexity compounds. SPF is a DNS record. DKIM requires key management. DMARC requires monitoring infrastructure. MTA-STS requires hosting a web endpoint. BIMI requires buying a certificate. Each layer adds a different kind of operational burden — DNS, cryptography, monitoring, web hosting, procurement.

Five protocols. Twenty years of development. And the share of domains that have genuinely implemented all of them is so small that the surveys mostly don’t bother to ask.