Email Security is Kind of Sketchy

At some point in the twists and turns of my software engineering career, I found myself in charge of the email sending infrastructure for a company that sends a lot of email (>1B messages per year). This is what we in the business call a "bulk sender." Over time, running this infrastructure has allowed me to peek behind the curtain at the inner workings of how email works at scale.

And look, I get it. Email is not cool. Email is not cutting edge. But it is the metaphorical tortoise. It has been around forever, it remains a critical part of nearly every product, and it takes real work to set up and operate well. It is also, quietly, a surprisingly hand-wavy, sketchy, cloak-and-dagger industry. So let’s take a dive into the wild and wonderful reality of how email works on the modern internet.

SMTP Crash Course

Emails are sent via Simple Mail Transfer Protocol (SMTP), an old school internet standard that was originally defined in the 1980s and has since seen a few revisions. The current spec is in RFC 5321, if you are into that kind of thing.

It's a bit like sending a letter in real life. Here's a simplified interaction between two Mail Transfer Agents (MTA):

Sending Server: MAIL FROM:<alice@example.com>
Receiving Server: 250 OK

Sending Server: RCPT TO:<bob@receiver.com>
Receiving Server: 250 OK

Sending Server: DATA
Receiving Server: 354 End data with <CR><LF>.<CR><LF>

Sending Server:
From: Alice <alice@example.com>
To: Bob <bob@receiver.com>
Subject: Hello
Date: Wed, 14 Jan 2026 10:00:00 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="boundary123"

--boundary123
Content-Type: text/plain; charset="UTF-8"

Hey Bob,
Subscribe to devnulldigest.com.

Cheers,
Alice

--boundary123
Content-Type: text/html; charset="UTF-8"

<p>Hey Bob,<br>Subscribe to <a href="https://devnulldigest.com">devnulldigest.com.</a></p>
<p>Cheers,<br>Alice</p>

--boundary123--
Sending Server: .
Receiving Server: 250 OK

If you’re familiar with other protocols like HTTP, then this kind of interaction isn’t surprising. The sender specifies the to/from addresses in MAIL FROM and RCPT TO—together called the “SMTP envelope,” like the envelope of a physical letter.

After those messages, the sender transmits the content of the email. The example above is Multipurpose Internet Mail Extensions (MIME)-formatted, which is an IETF standard that was created to extend the flexibility of types of messages and attachments that could be sent through SMTP.

After the receiving MTA gets the email message, lots of things can happen:

• Delivery: Placed the message in the recipient’s mailbox so that the user's mail client can retrieve it using IMAP or POP.
• Bounce: If the message violates a server policy (oversized messages, invalid recipient, failing security checks, etc.) then the server can reject it and send a message back to the envelope sender specified in the MAIL FROM header.
• Filter: Messages flagged by spam filters, content restrictions, or security scanners can be moved to a quarantine folder or marked as spam in the user's inbox.
• Reroute: Messages may be routed through aliases, mailing lists, or forwarded to another address. These processes can rewrite headers in the email content (such as the subject header) or may also change the envelope information. These modifications can often interfere with the security mechanisms that we will discuss later.

So that’s basically how mail servers work. Easy, right?

Trouble in Email Paradise

The original SMTP protocol was designed in the 1980s at a time when only researchers, universities, and big companies ran email servers. There wasn't a lot of tomfoolery. Most servers were configured as "open mail relays". That means any unauthenticated user could send mail through them, destined for anywhere, and the server would dutifully forward it anywhere without asking questions.

As the popularity of email grew into the 1990s, it didn't take long for spammers to start abusing the open relay system. They would send a spam email to an open relay SMTP server, sometimes with huge BCC lists, and let the legitimate SMTP servers forward their spam message to large numbers of users. One infamous case is this guy, who abused open relays at such scale that multiple major ISPs sued him. He even went to jail.

Nowadays open relays are pretty universally frowned upon, and most MTAs will flatly refuse to accept traffic from an open relay server. A "closed" relay means your server only forwards messages for local mailboxes or forwards to external addresses if the traffic came from a local source or is authenticated with SMTP Authentication. A closed relay prevents random, unknown users from piggybacking on your SMTP server to send emails to arbitrary destinations.

So we can see right from the start that SMTP was not exactly bulletproof. And the problems didn't end there.

You might wonder, "Hey, what is stopping me from just claiming my email is 'tax-refunds@irs.gov' and initiating an SMTP message to ask people for their bank account information?" Well, nothing. Nothing was stopping you from doing that. In fact, in 2005, that exact scenario happened. Emails claiming to be from 'tax-refunds@irs.gov' were sent to large numbers of users, collecting personal and financial information under the pretense of issuing tax refunds. It worked. People fell for it, and the IRS had to issue public warnings.

This is called email spoofing, and it was another major problem with the email ecosystem. SMTP does not verify that you actually own the domain you claim to be sending from. You could put anything you wanted in the MAIL FROM header of the email and the receiving server would shrug and pass it along.

A lot of this hand-waviness makes sense when you realize SMTP was designed in the 1980s for a very different internet then the one we see today. Back then, networks were small, and mostly trusted. The threat model was “someone misconfigured something,” not “some guy is trying to steal credit card information by sending 300 million emails.” SMTP assumed servers are honest, users are well intentioned, and abuse is rare. There was no built-in authentication (though SMTP Authentication was added later), and no cryptographic trust (though digital signatures such as OpenPGP and S/MIME were introduced later). These weren't a panacea, though. SMTP Authentication only verified who is allowed to initiate mail through a server and does not address delivery, forwarding, or other spoofing issues. And OpenPGP and S/MIME are mostly used for targeted, high-security messages between individuals or within enterprises, not for mass email.

The Big 3: DKIM, SPF, DMARC

By the mid 2000s, it became clear that some of these vulnerabilities needed fixing if the protocol was going to survive at internet scale. Spoofing and spam were out of control. It even attracted national attention with the CAN-SPAM Act of 2003, which essentially said, in technical terms, "do not do a spam please."

After much back-and-forth in the IETF and major email industry players, three authentication methods were adopted as add-ons to SMTP and are widely used today.

The first is Sender Policy Framework (SPF). SPF addressed the problem that anyone could put whatever they wanted in the MAIL FROM header when initiating an SMTP connection. With SPF, the receiving server can check that an email claiming to come from a particular domain actually originated from an IP address authorized by that domain’s administrators. Domain owners publish DNS records listing these authorized sending IPs, letting receivers verify the envelope sender.

The second is DomainKeys Identified Mail (DKIM). DKIM addressed the problem that messages could be modified by intermediate relays after leaving the original sender. DKIM uses a public/private key pair—with the public key being published as a DNS record. The sending server signs the email content (like From and Subject headers, and body content) with its private key, and includes that signature in a DKIM-Signature header in the email content. The recipient can retrieve the public key from DNS and verify that the signed parts of the message haven’t changed since signing. This preserves message integrity and proves the domain authorized the content.

The third is Domain-based Message Authentication, Reporting, and Conformance (DMARC). DMARC builds on SPF and DKIM and lets domain owners publish a policy in DNS specifying how to handle messages that fail authentication: deliver, quarantine, or reject. DMARC also supports reporting, allowing domain owners to receive feedback on authentication failures, helping them detect abuse and misconfigurations.

A related standard, Authenticated Received Chain (ARC), was introduced later to help preserve authentication results across forwarding, mailing lists, and other intermediate hops. Forwarders often break SPF or DKIM by modifying the message or rerouting it. ARC lets each server in the chain attest to the authentication results it saw, so the final recipient can verify the original sender even if the message was legitimately modified—such as when expanding a mailing list or sending to an alias.

Together, these standards form the backbone of email authentication today. Adoption among bulk senders has grown rapidly, driven largely by major providers like Google and Yahoo, which require proper DKIM, SPF, and DMARC configuration for high-volume senders.

So... All Good?

So with SPF, DKIM, and DMARC in place, we’re all good, right? Not exactly. These standards only work if people actually use them. That means senders have to configure them correctly and receivers have to enforce them. Not everyone does. Reserch shows that as of 2025, less than half "top domains" had adopted these methods. And even when SPF/DKIM/DMARC are used correctly, there are still vulnerabilities that these protocols do not address.

One such vulnerability is DKIM Replay Attacks. DKIM verifies that certain headers and the body of a message have not been modified since the original sender signed them. What it does not do is bind that signature to a specific recipient. And how could it? Forwarding, aliases, and mailing lists make recipient rewriting a normal and necessary part of how email works. A message sent to 'team@company.com' might fan out to fifty people. A message sent to 'alice@example.com' might be forwarded to 'alice@gmail.com'. In both cases, the recipient information has to change.

So, if an attacker can obtain a legitimately signed email, they can reuse it. In practice, this looks like capturing a real email from a trusted bulk sender, say, sharing a file with yourself that comes with an email notification, then taking that email and re-sending it to thousands of other recipients. The attacker does not touch the signed headers or body, so the DKIM signature remains valid. The forwarding server rewrites the SMTP envelope to use a domain it controls, so SPF passes. DMARC passes because DKIM passed. To the receiving server, the message looks perfectly authenticated. Variants of this attack have successfully spoofed even the big guys, like Google.

And DKIM Replay isn't the only skeleton in the closet. There’s also Display Name Spoofing (where you set your email display name to “Steve Jobs, CEO” while sending from 'bob@example.com'), Lookalike Domains (emails from 'rnicrosoft.com' instead of 'microsoft.com'), SMTP Smuggling (where careful CRLF sequences can trick MTAs into injecting headers or splitting messages), and a long tail of other problems or techniques that attackers can use.

Receiver Beware

When it comes down to it, a huge amount of responsibility falls on the receiver’s email service provider (ESP). They are the ones responsible for validating SPF/DKIM/DMARC, staying on top of CVEs like SMTP Smuggling, and critically, running filtering logic and analysis to decide whether a message even deserves to reach a user’s inbox.

Most ESPs worth their salt do far more than basic authentication checks. They analyze content, links, attachments, sending patterns, complaint rates, and historical behavior to decide whether a message is legitimate or spam. Based on this analysis, a message could either be delivered to a user's inbox, delivered but put in a user's spam folder, or outright rejected.

All of this feeds into a concept called sender reputation. Bulk senders are continuously scored based on the "quality" of the email coming from their address. Things like high complaint rates, low engagement, or big volume spikes hurt your reputation, and a bad reputation means more scrutiny is placed on filtering and inbox placement. While there is some public information for managing "email deliverability," most factors that go into a reputation calculation are kept deliberately opaque by ESPs to avoid bad actors designing ways around them.

For bulk senders, managing reputation is existential. There's a whole industry of email deliverability that has grown up around this cat-and-mouse game, where senders try to stay in the inbox while receivers try to protect users, fight spammers, and maintain a good experience for their users.

Managing reputation can feel a bit like throwing darts in the dark. Reputation is measured mostly indirectly through customer engagement signals or third-party services, ESPs rarely report reputation scores directly, and they almost never explain exactly why a specific message was filtered or blocked.

To make things more fun, other people can damage your reputation without your involvement. For example, DKIM replay attacks have been used to impersonate legitimate senders at scale, tanking their reputation with providers like Gmail to the point where mail from the real sender was refused entirely.

Conclusion

When it comes down to it, email and physical mail have a lot in common. There is nothing stopping somebody from stuffing a fake letter from the IRS into your mailbox and claiming you owe them money. If you got such a letter, you would probably rely on context, pattern recognition, and a general sense of trust to decide whether it is legitimate. If you get a few sketchy letters in a row, you start to distrust everything from that sender. We could of course use exclusively certified mail (PGP or S/MIME, in this metaphor), but that's not really feasible at scale for bulk mail.

The adoption of SPF, DKIM, and DMARC, along with ESPs running advanced filters and maintaining reputation scores, has made real progress in cleaning up the ecosystem. But these measures do not eliminate spoofing, abuse, or other silliness. They primarily act as detection mechanisms and damage control, reducing the impact when things go wrong rather than preventing them outright. None of our standards today are airtight, which feels surprisingly hand-wavy for a technology responsible for account recovery, authentication, billing, alerts, and countless other essential workflows.

Despite its flaws, email is not broken enough for people to abandon it. Its adoption is entrenched—like my grandmother’s email account from a defunct telecom provider that she refuses to give up. Email has been “just barely good enough” for decades, and that’s somehow been enough to keep it as a critical cornerstone of the modern internet. And just like the tortoise, it doesn't seem like it's going away anytime soon.