How Email Still Works Like It's 1971 (And Why That's Both Good and Bad)

a picture of some blue lights in the dark

5 min read

SMTP, the protocol that delivers your email, has operated on essentially the same design since 1971, predating personal computers and the modern internet.

The protocol's original strength—radical openness that let any server communicate with any other—became its greatest vulnerability when bad actors discovered they could impersonate anyone.

Spam exploded because SMTP has no built-in sender verification, allowing anyone to claim any email address as their own.

Modern authentication systems like SPF, DKIM, and DMARC attempt to retrofit security onto SMTP by verifying sender identity and message integrity.

Email's evolution demonstrates how foundational technology assumptions persist for decades, requiring endless patches rather than fundamental redesigns.

When you hit 'send' on an email, you're using technology designed before the first Star Wars movie, before personal computers existed, and before anyone imagined Nigerian princes would need your urgent financial assistance. SMTP—Simple Mail Transfer Protocol—has been shuffling messages across the internet since 1971, making it older than most of the people using it.

The wild part? It still works basically the same way. Your email travels through the internet using a protocol that was designed when everyone on the network knew each other personally and trust was assumed. This quaint origin story explains both email's remarkable staying power and why your spam folder exists in the first place.

SMTP Basics: The Simple Protocol That Conquered Digital Communication

SMTP works like a very polite postal system where every server says 'hello' before doing anything useful. When you send an email, your mail client connects to a server and they have a structured conversation: HELO, I'm sending from here. MAIL FROM this address. RCPT TO this person. Here's the DATA. It's almost embarrassingly straightforward, which is exactly why it won.

Back in 1971, Ray Tomlinson was just trying to send messages between computers at ARPANET. He picked the @ symbol to separate usernames from computer names (you're welcome, Twitter), and the basic concept hasn't fundamentally changed since. Your email bounces from server to server, each one accepting the message and promising to pass it along, like a game of telephone played by very reliable robots.

The beauty of SMTP is its radical simplicity and openness. Any server can talk to any other server. There's no central authority, no permission needed, no account to create. This decentralized design meant email could scale from a few hundred researchers to billions of users without anyone's approval. It's the internet's original social network, and it worked precisely because it trusted everyone.

Takeaway
SMTP's success came from being simple enough that anyone could implement it and open enough that no one controlled it—a design philosophy that enabled global adoption but created vulnerabilities we're still patching today.

Spam Problems: Why Email's Openness Became Its Biggest Weakness

Here's the thing about trusting everyone: eventually, someone abuses that trust. SMTP was designed when the internet had maybe a few thousand users who all worked at universities or research labs. The protocol has no built-in way to verify that senders are who they claim to be. When I send you an email claiming to be your bank, SMTP just shrugs and delivers it.

The first spam email arrived in 1978—an advertisement for computers sent to 393 ARPANET users. People were outraged. If only they knew what was coming. By the 1990s, marketers discovered they could send millions of emails for essentially nothing, and by the 2000s, spam accounted for over 90% of all email traffic. The system designed for trusted colleagues was drowning in pharmaceutical advertisements and advance-fee fraud.

Phishing attacks exploit SMTP's fundamental innocence even more dangerously. Since anyone can claim any 'FROM' address, attackers impersonate banks, employers, and tech companies with disturbing ease. The protocol that enabled global communication also enabled global fraud, and for decades, the email industry just... hoped people would learn to be careful. Spoiler: they didn't, and the criminals got better at their craft.

Takeaway
Email's spam problem isn't a bug that slipped through testing—it's the inevitable consequence of building a global communication system on the assumption that everyone acts in good faith.

Modern Patches: How SPF, DKIM, and DMARC Try to Fix 50-Year-Old Problems

Since we can't rebuild email from scratch (billions of addresses, countless servers, no central authority to coordinate migration), the industry invented clever patches to verify sender identity. SPF, DKIM, and DMARC work together like a three-part authentication system bolted onto SMTP's trusting frame.

SPF (Sender Policy Framework) lets domain owners publish a list of servers authorized to send their email. When mail arrives claiming to be from your-bank.com, the receiving server can check: 'Did this actually come from a server your-bank.com approves?' DKIM (DomainKeys Identified Mail) goes further, adding a cryptographic signature that proves the message wasn't tampered with in transit. It's like a wax seal for the digital age.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties everything together, telling receiving servers what to do when authentication fails. Should they quarantine suspicious messages? Reject them outright? DMARC also sends reports back to domain owners, revealing who's trying to impersonate them. These systems have dramatically reduced spoofing—when properly configured. The catch? Implementation remains optional, inconsistent, and often misconfigured. We're retrofitting security onto a 50-year-old foundation, one patch at a time.

Takeaway
Check if your email domain has SPF, DKIM, and DMARC configured properly—these authentication layers are your primary defense against impersonation, and many organizations still haven't implemented them correctly.

Email's persistence is both triumph and tragedy. A protocol designed for a few hundred trusted researchers now handles billions of daily messages, connecting humanity in ways its creators never imagined. That it works at all is remarkable engineering; that it's still fundamentally the same protocol is either beautiful simplicity or accumulated technical debt, depending on your perspective.

The lesson extends beyond email: the assumptions baked into foundational technologies shape everything built on top of them. SMTP assumed trust, and fifty years later, we're still managing the consequences. Every patch we add is a conversation with decisions made before email had spam folders—or needed them.