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.
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 SPF silently fails — your mail goes to spam with no error message. Most SPF validators don’t even warn you about this.
SPF has one fundamental flaw: it breaks when email is forwarded. If you send mail to a mailing list, the list server re-sends it 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 email headers with a private key, and publishes the public key in DNS. The receiving server verifies the signature. 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.
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 forces TLS for mail delivery, similar to what HSTS does for web traffic.
Almost nobody uses MTA-STS. Most mail administrators don’t know it exists.
BIMI (2020) is the latest addition. 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 despite IPv6 being available since 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 50-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 even have all of them configured correctly:
| Protocol | Year | Adoption | Reality |
|---|---|---|---|
| SPF | 2006 | High | Frequently misconfigured. 10-lookup limit silently 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 | Very low | Requires a well-known file + DNS record. Too much friction |
| BIMI | 2020 | Very low | Requires a Verified Mark Certificate ($1,000+/yr). Enterprise-only |
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.