Every few years someone announces they’re going to fix email. Encrypt it end to end, kill spam, make spoofing impossible, replace the whole creaking edifice with something modern. They never do. Not because they aren’t smart, but because they’ve misread the problem. Email isn’t a broken thing waiting for a good engineer. It’s a working thing whose foundation guarantees it can never be made secure without ceasing to be email.
Let me be precise about what I mean, because “email is broken” is a lazy thing to say and I want to say something sharper.
The original sin
SMTP was defined in RFC 821 in 1982. Read it today and the striking thing isn’t what’s missing — it’s how reasonable the omissions were. There is no authentication. None. A server connects, says MAIL FROM:<anyone@anywhere>, names some recipients, sends a message, and the receiving server accepts it. Nobody checks whether the sender is who they claim to be, because in 1982 the set of machines that could speak SMTP was small, known, and run by people who mostly knew each other. Adding cryptographic identity to that network would have been like putting a deadbolt on a tent.
The designers even marked the sender address as optional. Its stated purpose in the RFC was to give the system a path back to report a delivery failure — a return address on the envelope, nothing more. It was never meant to be a claim of identity you could trust. That single decision is the root of every email-security problem that followed, and it’s worth sitting with why.
Here’s the part most people never learn: an email has two senders, and they don’t have to match. There’s the envelope sender — the MAIL FROM your servers exchange during the SMTP conversation, defined by RFC 5321. And there’s the From: header, the one you actually see in your mail client, defined by a completely different document, RFC 5322. The envelope routes the mail; the header is displayed to the human. Nothing in the protocol requires them to be the same address. A message can be enveloped from bounces@marketing-vendor.com and displayed as From: ceo@yourbank.com, and that is not a bug or an exploit — it’s mailing lists and forwarding and every legitimate service that sends on someone else’s behalf working exactly as designed.
So spoofing isn’t a hole someone forgot to close. It’s the specified behavior. The protocol was built to let anyone claim to be anyone, because in its world that was a feature.
The tower of patches
Now watch what happens when you try to retrofit trust onto a protocol that was designed without it, and — crucially — that you cannot turn off, because tens of millions of servers speak the 1982 version and always will.
SPF (RFC 7208, 2014) was the first patch. Publish a DNS record listing which IP addresses are allowed to send mail for your domain. The receiver checks the connecting IP against the list. Reasonable — except SPF validates the envelope sender, the one nobody sees, not the From: header the user reads. So SPF can pass on a message that displays a forged From:. And SPF breaks the moment a message is forwarded, because forwarding changes the sending IP while preserving the original envelope sender. Twenty years on, mailing lists still routinely fail SPF for mail that is perfectly legitimate.
DKIM (RFC 6376, 2011) was the second patch. Sign selected headers and the body with a private key; publish the public key in DNS; let the receiver verify the signature survived transit. Better — it actually covers the visible From: header, and it survives some forwarding. But a mailing list that appends a footer or rewrites the subject breaks the signature, and a valid DKIM signature only proves some domain signed the message, not that the signing domain matches the one in the From: line.
Which is why we needed a third patch to make the first two mean anything. DMARC (RFC 7489, 2015) exists to tie SPF and DKIM to the From: header the user actually sees — a property called alignment — and to tell receivers what to do when neither aligns. Sit with that. The internet’s primary defense against email spoofing is a mechanism whose entire job is to bolt the two earlier anti-spoofing mechanisms onto the field they both forgot to check. And here’s the detail that tells you everything: DMARC isn’t even an IETF standards-track document. RFC 7489 is Informational, published through the independent submission stream. The single most important email-authentication standard on the internet was never ratified as an actual standard.
DMARC breaks forwarding too, of course — if SPF fails because the IP changed and DKIM fails because a list mangled the body, an aligned message gets rejected. So we needed a fourth patch, ARC (RFC 8617), to let intermediaries vouch that authentication passed before they touched the message, so the final receiver can choose to trust that chain. A patch, to preserve the patch, that fixes the patch that authenticated the original protocol.
I haven’t even gotten to encryption. SMTP is cleartext, so STARTTLS (RFC 3207) lets two servers opportunistically upgrade a connection to TLS. Opportunistically — meaning if the upgrade fails, or if a man in the middle simply strips the STARTTLS capability out of the greeting, the servers fall back to sending your mail in the clear rather than fail. It’s encryption you can silently turn off from the network. To close that, we got MTA-STS (RFC 8461) — a policy, published over HTTPS, that tells senders “no really, require TLS to reach me.” A patch instructing servers not to honor the downgrade that the encryption patch left open.
Count them. SPF, DKIM, DMARC, ARC, STARTTLS, MTA-STS — six protocols, spanning three decades, and every one of them exists to paper over a gap left by the one before, all of them optional, all of them backward-compatible with a 1982 protocol that assumes no security at all.
Why “just replace it” is a fantasy
Here’s the objection: fine, so design a clean successor. A modern messaging protocol with identity and encryption baked into layer one instead of stapled to layer nine.
People have. They’re called Signal, iMessage, WhatsApp, Slack, and a graveyard of secure-email startups. And notice what the successful ones did: they didn’t replace email. They built a walled garden next to it and told you to bring your friends. That works for chat because chat is social — you and the people you talk to can all move at once. Email’s value is precisely that it isn’t a walled garden. Anyone with any address on any provider can reach anyone else, no shared app, no account on the same platform. That universality is the entire product. And it is inseparable from the thing that makes email insecure: it must interoperate with every server that has ever spoken SMTP, including the one from 1982 that will happily accept an unauthenticated cleartext message claiming to be from anyone.
You cannot add a mandatory security requirement to a network whose defining feature is that it accepts mail from everyone, because the moment you make it mandatory, you stop accepting mail from everyone, and you have built a walled garden that happens to use the @ symbol. The protocol’s greatest strength and its unfixable weakness are the same property. You don’t get to keep one and discard the other.
What “unfixable” actually means
I’m not saying give up. SPF and DKIM and DMARC are worth deploying — I’d argue everyone should — and a domain with all three properly aligned is genuinely hard to spoof. The patches work, within their limits. Deploy them.
But be honest about what you’re doing. You are not fixing email. You are managing the permanent consequences of a decision made in 1982 to trust everyone on a small network, a decision that was correct then and cannot be unmade now because the network it created is too large, too old, and too useful to replace. Every “email security” product is a patch on that decision. There is no version of this that ends with a clean, secure email protocol, because the clean secure protocol wouldn’t be able to receive mail from the internet, and receiving mail from the internet is what email is.
Email is the cockroach of protocols. It will outlive every system built to replace it, imperfect and unkillable, exactly because it never demanded that anyone be trustworthy to participate. That was the mistake. It’s also the reason it still works.