On May 3, 1978, a Digital Equipment Corporation marketer named Gary Thuerk sent a message to 393 ARPANET users advertising a new computer system. The message generated $13 million in sales. It also created a permanent problem that would plague the internet for the next four decades: Thuerk had sent the first spam email.
What made this possible wasn’t clever hacking or sophisticated exploitation. It was a fundamental design decision built into email itself—a protocol that assumed everyone on the network could be trusted. When Jonathan Postel published RFC 821 in August 1982, defining the Simple Mail Transfer Protocol (SMTP), he created a system where the sender’s identity was entirely self-declared. Any mail server could claim to be sending from any address, and receiving servers had no way to verify it.
Today, approximately 376 billion emails traverse the internet every single day. Each message passes through a hidden infrastructure of mail agents, DNS lookups, and authentication checks that most users never see. The journey from “send” to “inbox” involves multiple protocols, cryptographic signatures, and policy decisions that determine whether your message reaches its destination or disappears into a spam folder.
The Architecture No One Sees
Email operates through a chain of specialized agents, each handling a specific phase of message delivery. This architecture, documented in RFC 5598, separates concerns in ways that made sense in 1982 but created security challenges that persist today.
When you compose a message in your email client—the Mail User Agent (MUA)—and press send, the message travels first to a Mail Submission Agent (MSA). The MSA validates that you’re authorized to send from your address and performs initial error checking. It then passes the message to a Mail Transfer Agent (MTA), which is responsible for routing the message toward its destination.
The MTA queries DNS to find where the recipient’s mail should be delivered, then establishes an SMTP connection with the recipient’s mail server. That server’s MTA accepts the message and hands it to a Mail Delivery Agent (MDA), which stores it in the recipient’s mailbox. When the recipient checks their email, their MUA connects via IMAP or POP3 to retrieve the message.
This separation of duties means that at each hop, different software makes different decisions about trust, authentication, and policy. The original design assumed all these agents were operated by trustworthy parties on a cooperative network. The reality of the commercial internet would prove dramatically different.
The Envelope Within the Envelope
One of the most misunderstood aspects of email is the distinction between the SMTP envelope and the message headers. This dual addressing system exists because email needs to satisfy two different audiences: mail servers that route messages, and humans who read them.
The SMTP envelope is created during the protocol conversation between mail servers. It consists of the addresses specified in the MAIL FROM and RCPT TO commands—the envelope sender and envelope recipient. These addresses determine where bounces are sent and which server receives the message. They’re called “envelope” addresses because, like a paper envelope, they’re used only for delivery and aren’t part of the message content.
Inside the envelope, the message contains headers like From:, To:, and Subject:. These are what the recipient sees in their email client. Crucially, nothing in SMTP requires these headers to match the envelope addresses. You can send a message with an envelope sender of [email protected] while the visible From: header shows [email protected].
This design flexibility was intentional—it allowed for legitimate use cases like mailing lists, where the envelope sender is the list management system while the From: header shows the original author. But it also enabled spoofing on an industrial scale. For decades, anyone could send email claiming to be from any address, and the receiving server had no reliable way to detect the deception.
flowchart TB
subgraph Envelope["SMTP Envelope (Server-to-Server)"]
MF["MAIL FROM: [email protected]"]
RT["RCPT TO: [email protected]"]
end
subgraph Headers["Message Headers (User-Visible)"]
FH["From: [email protected]"]
TH["To: [email protected]"]
SUB["Subject: Important Update"]
end
subgraph Body["Message Body"]
CONTENT["Email content..."]
end
Envelope --> Headers
Headers --> Body
NOTE["Note: Envelope addresses can differ from headers<br/>This design enables both mailing lists and spoofing"]
How Mail Servers Find Each Other
When an MTA needs to deliver mail to [email protected], it must discover which server handles incoming mail for example.com. This is where DNS MX records come into play.
An MX (Mail Exchange) record is a DNS entry that specifies the mail servers responsible for a domain, along with priority values that determine delivery order. A typical MX configuration might look like:
example.com. IN MX 10 mail1.example.com.
example.com. IN MX 20 mail2.example.com.
The priority numbers work counterintuitively: lower values indicate higher preference. Mail is first attempted at mail1.example.com (priority 10), with mail2.example.com (priority 20) serving as a backup. If both have the same priority, traffic is distributed between them—a technique called load balancing.
The receiving MTA performs this DNS lookup for every outgoing message. Once it has the destination mail servers, it establishes a TCP connection—traditionally on port 25, though modern submission typically uses port 587 with STARTTLS encryption.
The SMTP Conversation
SMTP is a text-based protocol where the client sends commands and the server responds with three-digit status codes. A typical delivery conversation looks like this:
S: 220 mail.example.com ESMTP Postfix
C: EHLO sender.domain.com
S: 250-mail.example.com
S: 250-PIPELINING
S: 250-SIZE 10240000
S: 250-STARTTLS
S: 250-AUTH LOGIN PLAIN
S: 250-ENHANCEDSTATUSCODES
S: 250-8BITMIME
S: 250 DSN
C: MAIL FROM:<[email protected]>
S: 250 2.1.0 Ok
C: RCPT TO:<[email protected]>
S: 250 2.1.5 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: [email protected]
C: To: [email protected]
C: Subject: Test message
C:
C: This is the message body.
C: .
S: 250 2.0.0 Ok: queued as ABC123
C: QUIT
S: 221 2.0.0 Bye
The EHLO command (Extended Hello) initiates the session and requests the server’s capabilities. MAIL FROM and RCPT TO define the envelope. DATA signals the start of message content, terminated by a line containing only a period. Each response code beginning with 2 indicates success; 3 signals “continue”; 4 indicates a temporary failure; 5 indicates a permanent failure.
The elegance of this design is also its weakness. Nowhere in this conversation does the server verify that [email protected] is actually authorized to send from that address. The protocol accepts the sender’s claim at face value.
The Open Relay Era
In the early 1990s, the internet’s exponential growth collided with SMTP’s trust-based design. A new problem emerged: open mail relays—servers configured to accept and forward mail from anyone, to anyone, regardless of the sender’s relationship to the server.
Open relays weren’t malicious; they were helpful. In the original internet, connectivity was unreliable, and relay servers helped ensure mail reached its destination even when direct paths were unavailable. RFC 821 explicitly encouraged this behavior, stating that mail should be forwarded “toward its ultimate destination.”
But as email volume exploded and commercial interests discovered the medium’s reach, open relays became the backbone of spam operations. A single compromised server could forward millions of messages, obscuring the true origin and overwhelming recipients’ inboxes. By the late 1990s, spam accounted for the majority of all email traffic.
The counterattack came through reputation systems and blocklists. Organizations like MAPS (Mail Abuse Prevention System) and later Spamhaus published lists of known open relays and spam sources. Mail servers configured to reject mail from listed addresses suddenly stopped accepting traffic from open relays. The incentive was clear: secure your server or become unreachable.
Modern MTAs now default to refusing relay for unauthorized senders. They accept mail only for local destinations or from authenticated users. But this created a new problem: how do you authenticate users who connect from arbitrary locations on the internet?
Enter SPF: The IP Address Whitelist
In 2003, Meng Weng Wong proposed a solution called Sender Policy Framework (SPF). The idea was elegant: publish a DNS record listing which IP addresses are authorized to send mail from your domain.
An SPF record is stored as a TXT record in DNS and follows a specific syntax:
v=spf1 ip4:192.0.2.0/24 include:_spf.google.com ~all
This record states that mail from this domain may be sent from any IP in the 192.0.2.0/24 range, plus any IPs authorized by Google’s SPF record (useful for domains that send through Gmail). The ~all mechanism means “soft fail”—unauthorized senders should be treated with suspicion but not outright rejected.
When a receiving server gets an incoming message, it queries the SPF record of the domain in the envelope sender address. It then checks whether the connecting IP address matches any authorized sources. The result is one of four outcomes:
- Pass: The IP is explicitly authorized
- Fail: The IP is explicitly not authorized
- Soft Fail: The IP is not authorized, but the policy suggests caution rather than rejection
- Neutral: The domain publishes no policy or the policy doesn’t apply
SPF significantly raised the bar for domain spoofing. Attackers could no longer freely impersonate domains that published SPF records. But SPF had limitations: it only validated the envelope sender, not the visible From: header that users see. And it couldn’t survive forwarding scenarios where mail passes through intermediate servers.
DKIM: Cryptographic Signatures for Email
DomainKeys Identified Mail (DKIM), published as an internet standard in 2007, took a different approach. Instead of checking IP addresses, DKIM uses public-key cryptography to sign messages, proving they haven’t been altered in transit.
When a mail server sends a DKIM-signed message, it computes a cryptographic hash of selected headers and the message body. This hash is then signed with a private key and included as a DKIM-Signature header. The corresponding public key is published in DNS.
A DKIM signature header looks like this:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.com; s=selector1;
h=from:to:subject:date:message-id;
bh=2jUSOH9NhtP/GQW6LfaM0ZJSrc0=;
b=aQZ8mZ...[signature bytes]...
The d= tag specifies the signing domain, s= identifies the selector (allowing multiple keys per domain), and h= lists the headers included in the signature. The bh= tag contains a hash of the body, and b= contains the cryptographic signature.
The receiving server retrieves the public key from DNS at selector1._domainkey.example.com, verifies the signature, and confirms the message’s integrity. If the signature validates, the server knows the message genuinely originated from the claimed domain and hasn’t been tampered with.
DKIM solved several problems that SPF couldn’t. It works regardless of the sending IP address, making it compatible with cloud email services and forwarding scenarios. It also protects message integrity—a DKIM-signed message that’s modified in transit will fail verification.
But DKIM has its own weaknesses. A message can have multiple signatures from different domains, which can be confusing. More problematically, DKIM only validates that some domain signed the message—it doesn’t require that domain to match the visible From: header.
DMARC: Connecting the Pieces
Domain-based Message Authentication, Reporting, and Conformance (DMARC), published as RFC 7489 in 2015, finally tied SPF and DKIM together with a coherent policy framework. DMARC addresses the fundamental question that neither SPF nor DKIM answered alone: should this message be delivered?
DMARC works by requiring “alignment” between the authenticated domain and the visible From: header. For SPF alignment, the domain in the envelope sender must match the From: header domain. For DKIM alignment, the signing domain (d= tag) must match the From: header domain. Either one passing is sufficient for DMARC to pass.
A DMARC policy is published as a DNS TXT record at _dmarc.example.com:
v=DMARC1; p=reject; rua=mailto:[email protected]
The p= tag specifies the policy:
- p=none: Monitor only; send reports but don’t affect delivery
- p=quarantine: Treat failing messages with suspicion (typically deliver to spam)
- p=reject: Refuse failing messages entirely
The rua= tag specifies where aggregate reports should be sent, allowing domain owners to monitor authentication failures and detect abuse attempts.
DMARC also introduced forensic reporting (ruf=), which sends detailed information about individual authentication failures. However, this feature raises privacy concerns and is less commonly used.
The adoption of DMARC has transformed email security. Major email providers now require DMARC for domains that send high volumes of mail. In 2017, the U.S. Department of Homeland Security issued a directive requiring all federal agencies to implement DMARC with p=reject policies. Today, DMARC enforcement is considered essential for any organization that cares about protecting its brand from phishing.
Retrieving Messages: IMAP vs POP3
While SMTP handles sending, two protocols compete for message retrieval: IMAP (Internet Message Access Protocol) and POP3 (Post Office Protocol version 3). Their differences reflect fundamentally different philosophies about email.
POP3, defined in RFC 1939, treats the mail server as a temporary holding area. The typical workflow is straightforward: connect to the server, download all new messages, delete them from the server, disconnect. Email lives on your local device.
This approach made sense when internet connectivity was expensive and unreliable. Download once, read offline, never worry about server quotas. But POP3’s simplicity becomes a liability in the smartphone era. If you download messages to your laptop, they won’t appear on your phone. There’s no synchronization; each device has its own isolated copy.
IMAP, defined in RFC 3501 and updated by RFC 9051, takes the opposite approach. Messages remain on the server, and your email client maintains a synchronized view of your mailbox. Read a message on your phone, and it’s marked as read on your laptop. File it into a folder, and that organization is reflected everywhere.
IMAP achieves this through a stateful connection where the client can search, fetch, flag, and organize messages without downloading them entirely. Commands like SELECT INBOX, FETCH 1:* (FLAGS BODY[]), and STORE 1 +FLAGS \Seen operate on the server’s copy while presenting a local view to the user.
| Feature | POP3 | IMAP |
|---|---|---|
| Message storage | Downloaded locally | Stored on server |
| Multi-device access | Not supported | Fully supported |
| Folder management | Not supported | Full support |
| Offline access | Complete messages | Cached portions only |
| Server storage | Minimal (messages deleted) | Higher (all messages retained) |
| Protocol complexity | Simple (7 commands) | Complex (many commands and extensions) |
The modern preference for IMAP reflects how email has evolved from occasional correspondence to continuous communication. We expect our email to be available everywhere, synchronized instantly, with search capabilities that work across years of archived messages.
The Headers That Tell the Story
Every email carries a detailed log of its journey through the mail system. The Received: headers, added by each MTA that handles the message, create a chain showing the path from sender to recipient.
Received: from mail.example.com (mail.example.com [203.0.113.50])
by mx.google.com with ESMTPS id abc123
for <[email protected]>
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256);
Sat, 01 Mar 2025 10:15:30 -0800 (PST)
Received: from [192.0.2.100] (unknown [192.0.2.100])
by mail.example.com (Postfix) with ESMTPSA id def456
for <[email protected]>;
Sat, 01 Mar 2025 13:15:28 -0500 (EST)
Reading these headers from bottom to top reveals the message’s path. The bottommost Received: header shows the original submission—the client connecting from IP 192.0.2.100 to mail.example.com using authenticated SMTP (ESMTPSA). The top header shows the transfer to Google’s mail server, with TLS encryption details.
This trail of evidence is invaluable for diagnosing delivery problems and investigating spam. But it also reveals how much information leaks with every message. Your IP address, mail client, sending server, and timing are all recorded and passed along.
The Ongoing Arms Race
Despite SPF, DKIM, and DMARC, email security remains an ongoing battle. Business Email Compromise (BEC) attacks—where scammers impersonate executives or vendors to authorize fraudulent payments—cost organizations $55 billion between 2013 and 2023, according to FBI data. These attacks often use legitimate email addresses that have been compromised, bypassing authentication entirely.
New challenges continue to emerge. Artificial intelligence enables more convincing phishing messages. Domain lookalike attacks use slight misspellings (examp1e.com instead of example.com) that pass authentication but deceive users. The rise of email filtering as a service creates new trust boundaries that attackers can exploit.
The protocols themselves continue to evolve. BIMI (Brand Indicators for Message Identification) allows organizations to display logos next to authenticated messages in supporting clients. ARC (Authenticated Received Chain) addresses the authentication breakage that occurs when mail passes through forwarding services that modify messages.
SMTP, now over 40 years old, carries more traffic than ever. The protocol’s original design—simple, extensible, trust-based—proved both its greatest strength and its most persistent weakness. Every modern email security measure is, in some sense, a patch applied to a foundation that assumed a world of honest actors.
When you press send on your next email, pause to consider the journey. Your message will pass through multiple servers, each making decisions about trust and policy. DNS lookups will identify routes. Cryptographic signatures will be verified. Policies will be consulted. And if all goes well, 376 billion times a day, a message will find its way from one inbox to another—a process that’s simultaneously simple enough for anyone to use and complex enough to fill entire books.
References
- Postel, J. (1982). RFC 821: Simple Mail Transfer Protocol. IETF.
- Klensin, J. (2008). RFC 5321: Simple Mail Transfer Protocol. IETF.
- Wong, M. & Schlitt, W. (2014). RFC 7208: Sender Policy Framework (SPF). IETF.
- Crocker, D. et al. (2007). RFC 4871: DomainKeys Identified Mail (DKIM). IETF.
- Kucherawy, M. & Zwicky, E. (2015). RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC). IETF.
- Crispin, M. (2003). RFC 3501: INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1. IETF.
- Crocker, D. (2009). RFC 5598: Internet Mail Architecture. IETF.
- Computer History Museum. (1978). May 3: Earliest Known Case of Spam.
- FBI Internet Crime Complaint Center. (2024). Business Email Compromise: The $55 Billion Scam.
- Statista. (2025). Number of e-mails per day worldwide 2018-2028.