SMTP was designed in 1982. It had no concept of sender verification. You could put anything in the “From” field and the receiving server would accept it. That was fine when the internet had a few hundred hosts and everyone knew each other.
It’s not 1982 anymore.
If you came here for the short list, here it is. Only three of the five are authentication in the strict sense: SPF says which servers may send for a domain, DKIM signs the message, and DMARC ties both to the visible From address and tells receivers what to do when they fail. The other two ride on top: MTA-STS protects the delivery connection, and BIMI shows a logo once DMARC is enforced. The rest of this post is about why it took five separate pieces to get there.
The Patching Begins
The first attempt to fix this was SPF (2006). The idea was simple: publish a DNS record listing which servers are allowed to send mail for your domain. Receiving servers check the record and reject unauthorized senders.
Warning: SPF has a hard limit of 10 DNS lookups. Exceed it and the check returns a permanent error instead of a pass — and many receivers treat that the same as a failure. Nothing bounces back to tell you; you only find out from a checker or from DMARC reports.
SPF has one fundamental flaw: it breaks when email is forwarded. Say you send to someone’s old university address that automatically forwards to their Gmail. The university server re-sends your message from its own IP — which isn’t in your SPF record. Legitimate mail fails SPF checks constantly. This is not an edge case. It’s how email works.
So they built DKIM (2007). Instead of checking the sending IP, DKIM uses cryptographic signatures. The sending server signs the body and a chosen set of headers with a private key, and publishes the public key in DNS. The receiving server verifies the signature. Plain forwarding doesn’t break it because the signature travels with the message.
DKIM works. The problem is that SPF and DKIM operate independently. A domain can pass SPF but fail DKIM, or vice versa. There’s no policy that says what to do when one passes and the other fails. There’s no reporting mechanism. There’s no way to tell receiving servers “if both fail, reject it.”
Enter DMARC (2012). DMARC is a policy layer on top of SPF and DKIM. It tells receiving servers: “here’s what to do when authentication fails” — none, quarantine, or reject. It also adds reporting, so you can see who’s sending mail as your domain. It started as an industry spec, became an informational RFC (7489) in 2015, and only reached the standards track in May 2026 as RFC 9989.
DMARC should have been the end of the story. It wasn’t.
The Stack Keeps Growing
MTA-STS (2018) addresses a different problem entirely. Even with SPF, DKIM, and DMARC, the actual mail delivery can happen over an unencrypted connection. SMTP’s STARTTLS upgrade is opportunistic — a man-in-the-middle can strip it. MTA-STS lets a domain demand verified TLS for delivery, similar to what HSTS does for web traffic.
Outside the large mail providers, MTA-STS is rare. Plenty of mail administrators have never had a reason to look at it.
BIMI is the latest addition, and it isn’t even an RFC — it’s still an IETF draft that mailbox providers adopted anyway, with Gmail showing BIMI logos broadly from 2021. It puts your brand logo next to your emails in the inbox — but only if you have DMARC at p=quarantine or p=reject. It’s essentially a carrot to drive DMARC adoption. The security value is debatable. The marketing value is clear.
Why Not Just Replace SMTP?
This is the question everyone asks and nobody acts on.
The answer is the same reason we still use IPv4 even though IPv6 was standardized in 1998: migration cost. Every email server in the world speaks SMTP. Replacing it requires coordinated action from every mail provider simultaneously. That’s not going to happen.
So we keep stacking protocols on a 40-year-old foundation. Each one fixes a specific flaw. None of them fix the fundamental problem: SMTP was designed for a world where trust was assumed.
The Current State
Five protocols, and most domains don’t have all of them configured correctly:
| Protocol | Year | Adoption | Reality |
|---|---|---|---|
| SPF | 2006 | High | Frequently misconfigured. 10-lookup limit quietly breaks larger setups |
| DKIM | 2007 | Medium | Technically sound, but many publish keys without checking alignment |
| DMARC | 2012 | Medium | Widely deployed at p=none — “monitor but don’t enforce.” Decorative |
| MTA-STS | 2018 | Low | Requires a well-known file + DNS record. Too much friction |
| BIMI | ~2021 (draft) | Very low | Gmail and Apple Mail want a paid mark certificate (VMC; Gmail also takes a CMC). Mostly big brands |
The result is a system where the tools exist but adoption lags years behind availability. The gap between “published as RFC” and “actually deployed” is where most email security problems live.
There’s no sixth protocol coming to fix this. The five we have are sufficient — if people actually used them.