How blind trust in email cost the world $55 billion

Email was built on trust

In 1971, Ray Tomlinson sent the first network email across ARPANET. By 1982, RFC 821 defined SMTP as the standard way to send messages between computers. The protocol was simple and completely trusting.

That made sense at the time. ARPANET connected a few hundred hosts, all operated by known research institutions. Nobody needed to verify identities because everybody already knew each other. SMTP reflected that reality:

• No sender verification. The MAIL FROM command accepted any address without checking if the sender actually owned it.
• No encryption. Messages traveled as plain text, readable by anyone on the network path.
• No identity checks. The HELO command, where the sending server identifies itself, was accepted on faith.

As RFC 5321 itself acknowledges: "SMTP mail is inherently insecure in that it is feasible for even fairly casual users to negotiate directly with receiving and relaying SMTP servers and create messages that will trick a naive recipient into believing that they came from somewhere else."

In other words, the protocol's own specification admits the flaw. SMTP was never designed for a hostile internet. But a hostile internet is exactly what it got.

How attackers exploited that trust

The history of email attacks follows a clear pattern. Each time attackers found a new way to exploit SMTP's blind trust, defenders built a countermeasure. Then attackers adapted, and the cycle repeated.

Phase 1: Open relays and the spam flood (1988-2002)

The first large-scale abuse came through open mail relays. By default, most SMTP servers in the 1990s would accept email from anyone and forward it to anyone else. Spammers discovered they could route millions of messages through these servers, hiding their identity and offloading the bandwidth costs onto their victims.

The scale was staggering. According to the Internet Mail Consortium, 55% of mail servers were open relays in 1998. By 2002, that number dropped below 1%, thanks to blocklists and configuration changes. But closing relays only solved the delivery problem. The identity problem remained wide open.

Phase 2: Sender forgery and the birth of SPF (2000-2007)

Closing open relays stopped spammers from hijacking other people's servers. But it didn't stop them from forging sender addresses. Anyone could still send an email claiming to come from [email protected], and the receiving server had no way to know the difference.

This is the fundamental SMTP vulnerability. The protocol has two separate sender fields, and they don't need to match:

In 2003, SPF (Sender Policy Framework) was proposed as a fix. Domain owners could publish a DNS record listing which IP addresses were authorized to send email on their behalf. If an email arrived from an unlisted IP, the receiving server could reject it.

SPF helped, but it only checked the envelope sender (MAIL FROM). Attackers quickly realized they could pass SPF by using their own domain in the envelope while forging the visible From header. The user still saw a trusted name in their inbox.

Phase 3: Message tampering and DKIM (2007-2012)

While SPF answered the question "did this email come from an authorized server?", it said nothing about whether the message had been altered in transit. An attacker who intercepted an email could modify the content, change the reply-to address, or inject malicious links without breaking SPF validation.

DKIM (DomainKeys Identified Mail, RFC 4871, 2007) addressed this by adding cryptographic signatures. The sending server signs specific headers and the message body with a private key. The receiving server looks up the public key via DNS and verifies the signature.

DKIM proved that a message hadn't been tampered with and that a specific domain had signed it. But it had a similar gap to SPF: the signing domain didn't need to match the visible From address. An attacker could sign a forged email with their own domain's DKIM key and pass validation.

Phase 4: The alignment gap and DMARC (2012-2015)

By 2012, email had two authentication mechanisms, and both could be bypassed by the same trick: using one domain for authentication while forging a different domain in the visible From header. SPF and DKIM each answered a useful question, but neither asked the critical one: does the authenticated domain match what the user actually sees?

DMARC (Domain-based Message Authentication, Reporting and Conformance) was developed by a coalition including Google, Microsoft, Yahoo, PayPal, and Bank of America to close this gap. Published as RFC 7489 in 2015, DMARC added what SPF and DKIM were missing:

• Alignment. The authenticated domain (from SPF or DKIM) must match the domain in the visible From header. No more passing SPF with one domain while displaying another.
• Policy enforcement. Domain owners can tell receiving servers what to do with messages that fail alignment: monitor (p=none), quarantine (p=quarantine), or reject (p=reject).
• Reporting. Receiving servers send reports back to domain owners showing who is sending email using their domain, both legitimate services and attackers.

The $55 billion problem: Business Email Compromise

While defenders built authentication protocols, attackers shifted tactics. Rather than forging domains directly (which DMARC could block), they turned to social engineering. The result is Business Email Compromise. In 2024 alone, BEC cost victims $2.77 billion, more than any other category of cybercrime except investment fraud.

BEC works because it targets people, not protocols. An attacker studies a company's structure on LinkedIn, identifies the CFO's email patterns, and sends a request that looks like an internal communication. Sometimes they spoof the domain. Sometimes they register a lookalike (bigc0rp.com instead of bigcorp.com). Sometimes they compromise a legitimate account.

Real-world BEC attacks

In June 2014, the commodities trader Scoular Co. wired $17.2 million to a Chinese bank after its corporate controller received emails faked to appear from the CEO. In 2015, Ubiquiti Networks lost $46.7 million and toy maker Mattel lost $3 million to similar schemes. None of these required exploiting a software vulnerability. All of them exploited SMTP's inability to verify identity.

BEC losses over time

Source: FBI IC3 Public Service Announcement, September 2024.

Modern attack techniques

Today's email attacks combine SMTP's structural weaknesses with social engineering and new technology. Even with SPF, DKIM, and DMARC deployed, attackers have adapted.

Lookalike domains

Instead of spoofing company.com directly (which DMARC can block), attackers register visually similar domains and set up full authentication for them:

SPF record abuse

Overly permissive SPF records create unexpected attack surfaces. When a domain authorizes large shared email platforms, any customer of those platforms can potentially send email that passes SPF for the domain:

AI-enhanced social engineering

Attackers now use AI to make their emails harder to spot:

• AI-generated emails. Messages that mimic a specific person's writing style, with none of the spelling or grammar mistakes that used to give phishing away.
• Voice cloning. Attackers synthesize a CEO's voice for phone calls that follow up on a fraudulent email. The recipient hears a familiar voice confirming the fake request.
• Deepfake video. Video calls where an executive's face and voice are simulated in real time to authorize transfers.

Protocol-level vulnerabilities

Beyond social engineering, attackers continue to find technical weaknesses:

• SMTP smuggling. Exploiting differences between SMTP implementations to bypass authentication checks.
• DNS cache poisoning. Redirecting SPF, DKIM, or DMARC lookups to attacker-controlled records.
• TLS downgrade attacks. Forcing connections back to unencrypted SMTP to intercept or modify messages in transit.

The defense stack today

Each vulnerability in email's history produced a specific defense. Together, they form a layered security model. NIST Special Publication 800-177 recommends that all organizations implement SPF, DKIM, and DMARC with an enforcement policy.

Next steps

Email authentication is not a single switch you flip. Each layer exists because the previous one left a gap. The same pattern continues today, which is why monitoring your DMARC reports matters as much as setting up the records in the first place.

Continue with these guides to go deeper:

• SMTP weaknesses and open relays: why email needed DMARC
• Why DMARC was created: closing SPF and DKIM gaps
• Intro to DMARC: protect your domain and inbox trust
• State of DMARC: top 100 domains live dashboard