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 measure the public internet. 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.
SPF: The One Almost Everyone Has (Sort Of)
SPF sits at the top of the funnel. Industry surveys put adoption somewhere around 80-85% for major domains. That sounds great until you look at how those records are configured.
The majority use ~all — softfail. Which means receiving servers can, and usually do, deliver the email anyway. The record technically exists. The protection is technically absent.
Then there’s the 10-lookup limit. SPF records can include other domains’ records via include: mechanisms. Each include triggers a DNS lookup. Exceed 10 lookups total and SPF silently fails. No error message. No warning. Large organizations routinely hit this limit — multiple email service providers, marketing platforms, CRM tools, each requiring an include:. The record grows. It breaks. Nobody notices for months.
DKIM: Where the Self-Hosted Drop Off
DKIM uses cryptographic signatures. The sending server signs email headers with a private key. The public key lives in DNS. Receiving server verifies.
If you use Google Workspace or Microsoft 365, DKIM is usually configured automatically. The provider manages the keys. You add a DNS record. 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 misconfigured or expired key means signatures fail silently.
Adoption drops to maybe 60-70% for domains that actually send email. A 2022 USENIX Security paper found 28.1% of the Alexa Top 1 million had enabled DKIM. The gap between top domains and the broader internet is stark. 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. Around 50-60% of major domains have some form of DMARC record. But the distribution is lopsided.
A 2026 scan over 5.5 million Tranco domains found 30.4% published DMARC. Only 12.8% of all scanned domains were at enforcement — p=quarantine or p=reject. Among domains that had DMARC at all, 57.9% still sat at p=none.
Moving from p=none to p=reject requires reading your DMARC reports, identifying every authorized sender, making sure they pass either SPF or DKIM, 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 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? Low single digits. Maybe 2-5% of domains.
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 SVG format meeting specific requirements, and a Verified Mark Certificate from a certificate authority.
VMCs cost $1,000-1,500 per year.
Adoption is a rounding error. Under 1% of domains. A small business isn’t paying $1,000/year to get a logo next to their emails. Many large enterprises aren’t either.
The Bottom of the Funnel
Rough numbers from industry data:
- SPF: ~85% of major domains
- DKIM: ~60-70% of email-sending domains
- DMARC (any policy): ~50-60%
- DMARC (enforcing): ~15-20%
- MTA-STS: ~3-5%
- BIMI: <1%
Domains that have all five properly configured — SPF with -all, DKIM with valid keys, DMARC at p=reject, MTA-STS with a valid policy, and BIMI with a VMC — are vanishingly rare. Fractions of a percent.
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 percentage of domains that have genuinely implemented all of them could fit in the margin of error of most surveys.