Email is everywhere—but security? That came much, much later. For decades, our inboxes were built on blind trust. Understanding the evolution of email vulnerabilities isn't just a stroll through IT history. It's the key to knowing why protocols like DMARC exist, and what they're trying to fix.
Learning Objectives
- • Explain how email's original design created security loopholes
- • Describe key historical vulnerabilities like spam, spoofing, and Business Email Compromise (BEC)
- • Understand why older protocols like SPF and DKIM weren't enough
What is the History of Email Vulnerabilities?
Let's rewind to 1982. That's when the Simple Mail Transfer Protocol (SMTP)—the backbone of email—was born. It was designed in a more trusting time, where the internet was an academic tool, not a commercial battleground. Security wasn't a concern. As a result, SMTP never verified who was sending a message. It just passed along the mail, no questions asked.
Over time, this opened the door to spam, spoofing, and more serious threats. By the early 2010s, over 85% of email traffic was spam. Spoofing—where attackers fake the sender address—became rampant. Business Email Compromise (BEC) schemes started costing companies billions. And all this was possible because email, at its core, didn't verify identity.
Why Is That Important?
Every time you get an email, your client shows you a "From" address. You trust it. But unless safeguards are in place, anyone can write anything in that field. This is the core vulnerability: what you see in your inbox doesn't reflect who actually sent the message.
The stakes? High. Email spoofing enables:
- Phishing attacks, where fake senders try to steal credentials
- Fraudulent invoices from what appears to be your vendor
- Fake internal requests from "your boss" asking you to wire money
Between 2013 and 2022, BEC scams cost over $50 billion globally, according to the FBI's Internet Crime Complaint Center. And that's just one type of exploit made possible by spoofing.
How Does It Work?
Imagine this: You get a letter in the mail with a return address that says "IRS". Looks official. But the letter was actually dropped into your mailbox by a scammer who wrote that return address by hand. That's SMTP in a nutshell.
SMTP accepts whatever is in the MAIL FROM: command (the envelope sender), and does not require it to match the From: field you see in your email client. So, while the backend routes the message based on one value, your email app displays a potentially fake "From" address that looks trustworthy. Attackers exploit this disconnect.
It gets worse:
- Open Relays: Initially, many mail servers were "open relays," meaning they would accept and forward email from anyone, to anyone. Spammers exploited this for decades to send massive volumes of email while hiding their true origin.
- The HELO/EHLO handshake, which identifies the sending server, isn't verified either
- Headers? Completely forgeable
- Policies? None were standardized until much later
Over the years, various patches tried to fix this. SPF was introduced to validate sending IPs. DKIM added cryptographic signatures. But each had big gaps (we'll cover those in separate articles). Long story short: neither one could fully stop spoofing.
What Does a Vulnerable Email Look Like?
Here's a raw SMTP example that illustrates the spoofing problem:
HELO mail.some-other-domain.com
# The "envelope" sender is from a domain the attacker controls
MAIL FROM:<[email protected]>
# The recipient
RCPT TO:<[email protected]>
DATA
# The "header" From, which the user sees, is the spoofed address
From: "Your Bank" <[email protected]>
Subject: Urgent: Verify Your Account
...
What's going on here?
- The attacker's server provides a HELO name that isn't verified.
- The MAIL FROM (envelope sender) uses a domain the attacker controls, which might pass a basic SPF check for
some-other-domain.com. - But the "From" header—what the user sees in their inbox—is a forged address from a legitimate bank.
- Without DMARC's alignment check, the receiving server sees a valid SPF result for the envelope domain but has no way to know that the visible "From" address is a complete fake.
(And if you're wondering, this kind of spoofing still works on many misconfigured domains.)
What Are the Most Common Pitfalls?
Even today, the road to email authentication is bumpy. Here are the most common issues:
1. Blind Trust in SPF or DKIM
Many admins think, "We've got SPF and DKIM, we're good." Not quite. Without alignment checks (like DMARC), these technologies can validate a sender that still spoofs the "From" field.
2. Email Forwarding Breaks SPF
A lot of email gets forwarded—think of students forwarding college email to Gmail, or internal aliases. When this happens, the original sending IP changes, and SPF often fails. Without DKIM or DMARC, legitimate mail ends up looking like spoofed mail.
3. Short DKIM Keys and Bad DNS
In the early days, many organizations used 512-bit DKIM keys, which could be cracked for under $100 by 2012. RFCs now recommend at least 1024-bit keys (2048 is better), but old keys still linger. Also, DMARC, DKIM, and SPF all depend on correct DNS configuration. A typo can break everything.
4. Display Name Deception
Even when protocols are configured, a scammer can write:
If the domain example.net is authenticated, the message might pass checks—even though it's not from Amazon. DMARC doesn't verify the name, just the domain. And users often read names, not addresses.
Next Steps: From Band-Aids to Blueprint
SPF and DKIM were the first attempts to fix email's trust issues, but they weren't enough. DMARC came along to tie everything together and close the gaps—adding alignment, policies, and reporting.
To understand the solutions that evolved to fix these problems, explore our other guides:
- SMTP Weaknesses & Open Relays: Why Email Needed DMARC
- Why DMARC Was Created: Closing SPF & DKIM Gaps
- Intro to DMARC: Protect Your Domain & Inbox Trust
In Summary: The history of email vulnerabilities is really the story of what happens when an essential technology outgrows its original purpose. SMTP was designed for a friendlier internet. What it needed—and what DMARC provides—is a passport control system for email, one that doesn't just ask "Where are you going?" but "Are you really who you say you are?"