Every malformed header, every bounce with a cryptic code, every authentication failure a mail admin has ever squinted at, all of it traces back to decisions made by small working groups in the 1970s and 1980s. The history of email standards, from ARPANET to SMTP and the layers built on top of it, isn't trivia. It's the reason a message sent this afternoon still carries a From: field and a Subject: line formatted almost exactly as they were more than forty years ago. Understanding that lineage turns header-reading from memorization into diagnosis.

Before SMTP: ARPANET Email and the Improvised Origins of Messaging

ARPANET wasn't built to carry mail. It was built to let researchers share files and run remote jobs across a handful of university and defense computers. Email arrived as a side effect. Engineers realized the same file-transfer machinery could drop a text file into someone else's account, and from there, informal messaging habits spread faster than anyone had planned for.

There was no committee overseeing this. It was closer to an unauthorized weekend side project that happened to work well enough to stick.

RFC 524 and the First Attempt at a Mail Standard

By 1973, enough sites were exchanging messages informally that someone tried to write down the rules. J.E. White published RFC 524, "A Proposed Mail Protocol", on 13 June 1973. It was one of the earliest attempts to propose a standard for message transmission across the network. It didn't achieve lasting adoption. Implementations diverged, and the document was superseded as the network's needs grew. But it marked the first serious acknowledgment that ad hoc messaging needed a shared format if it was going to scale beyond a handful of sites.

SNDMSG, Tomlinson, and the @ Symbol's Accidental Permanence

The more consequential development came from a local, unglamorous program called SNDMSG, used to append text messages to a user's file on a shared machine. It worked fine for people on the same computer. The problem was reaching someone on a different machine entirely.

Ray Tomlinson solved that in 1971. He combined SNDMSG with an experimental file-transfer program and picked a separator character to distinguish "user" from "which machine." He chose @, a symbol doing nothing useful on a Teletype keyboard until that moment, because it was unlikely to appear in a person's name. It is one of the most cited origin stories in computing. Practitioners rarely connect it to a practical fact: address parsing still treats everything before and after that character as structurally distinct fields. That's exactly why malformed addresses fail in such predictable, specific ways.

RFC 821 and RFC 822: Splitting Transport From Content

The defining architectural decision in email's history came in August 1982. Two documents appeared instead of one. Jon Postel wrote RFC 821, which defined how messages moved between machines. David Crocker wrote RFC 822, which defined how messages were structured once they arrived. The IETF did not exist yet — it first met in January 1986 — so this was the ARPA research community setting its own conventions. That split, transport versus content, envelope versus header, is still the reason header analysis and SMTP delivery tracing are treated as two distinct disciplines today.

What RFC 821 Standardized in the SMTP Command Set

RFC 821 gave the network a shared vocabulary for transport: HELO to announce yourself, MAIL FROM to declare a sender, RCPT TO to name a recipient, and DATA to hand over the message body. These commands, defined in RFC 821 in 1982, remain the literal command set visible in a raw SMTP transcript today. They've been extended repeatedly since but never replaced outright. Anyone tracing the SMTP delivery path is, in effect, watching a 1982 conversation still happening in real time.

How RFC 822 Defined the Header Fields Still Used Today

RFC 822 picked up where an earlier document, RFC 733 from November 1977, left off. It formalized header syntax: To, From, Subject, Date, and the folding and parsing rules that govern them. That header syntax still appears, largely unchanged, in the header block of a message sent this afternoon. The practical result of the 821/822 split: reading email headers to diagnose failures and tracing the SMTP delivery path are genuinely separate skills. One is about what the message says. The other is about how it got there.

MIME and RFC 2045: Solving SMTP's Text-Only Problem

SMTP as designed in 1982 assumed 7-bit ASCII text. That was a reasonable assumption for a network of English-speaking research institutions passing short messages. It became a serious limitation the moment people wanted to send anything else.

Why 7-bit ASCII Couldn't Carry Attachments or International Text

Binary files, images, documents, executables, don't fit cleanly into 7-bit ASCII without corruption somewhere along the path. Neither do accented characters, non-Latin alphabets, or anything outside the narrow character set SMTP assumed. Through the late 1980s, as email spread beyond its original research-network audience, this became impossible to ignore. Various ad hoc encoding schemes emerged to work around it. None of them were standardized. All of them were fragile. By the start of the 1990s the pressure was enough to force a real standard.

How MIME Encoding Introduced Content-Type and Multipart Messages

MIME solved this without touching the transport layer. Nathaniel Borenstein and Ned Freed published the first version as RFC 1341 in June 1992. A revision followed as RFC 1521 in September 1993. The set in force today is RFC 2045 through RFC 2049, published in November 1996. The version number in the MIME-Version: 1.0 header has never moved off 1.0. MIME let a message declare a Content-Type. It let binary data travel safely through encodings like base64. And it let one message hold several parts at once — text, attachments, embedded images — inside a single envelope. Baseline SMTP still only had to move 7-bit text. MIME just made that text describe what it actually contained. For the mechanics of how that encoding and structure actually work, MIME encoding explained from first principles covers the technical breakdown in depth.

ESMTP: Extending SMTP Without Breaking It

By the early 1990s, SMTP needed more than MIME could offer at the transport level. It needed a way for servers to advertise what they could do, without breaking compatibility with older systems still running the original command set.

The EHLO Handshake and Capability Negotiation

The answer was ESMTP. The extension framework first appeared as RFC 1425 in February 1993. It was revised as RFC 1651 in July 1994, then again as RFC 1869 in November 1995, which is the version that became an Internet Standard. A client opens with EHLO instead of HELO, and the server responds with a list of extensions it supports: larger message sizes, authentication, encrypted transport, and more added over time. Servers that only understood HELO still worked exactly as before. This capability-negotiation pattern is why SMTP could absorb decades of new features, including AUTH and STARTTLS, without a single flag day forcing every mail server on the internet to upgrade at once.

RFC 5321 and RFC 5322: Modernizing the Rules Without Rewriting Them

By the 2000s, the original 1982 documents had accumulated two decades of clarifications, errata and extensions. All of it sat scattered across dozens of follow-on RFCs. A first consolidation landed in April 2001, as RFC 2821 and RFC 2822. Seven years later the IETF did the job again, and did it more thoroughly. In October 2008 the two documents that still govern email appeared: RFC 5321 and RFC 5322.

What Changed in the 2008 Updates

RFC 5321 obsoleted RFC 2821, and with it RFC 821, RFC 974 and RFC 1869. It folded in ESMTP, clarified error handling, and absorbed years of operational experience. RFC 5322 obsoleted RFC 2822, the 2001 revision of RFC 822. It tightened ambiguous grammar and folded in years of errata. What it did not do was internationalize the header block. Header fields stayed US-ASCII. Non-ASCII text still had to travel as MIME encoded-words, the mechanism defined in RFC 2047 in November 1996. Native UTF-8 inside header field values arrived much later, in RFC 6532 in February 2012. That one needs the SMTPUTF8 extension supported end to end, and header field names must still be ASCII. Neither 2008 document reinvented the model. The envelope-versus-header split, the core SMTP verbs, the essential header fields, all of it carried forward intact.

Why Practitioners Still Cite the Original RFC Numbers

Despite the 2008 update, working engineers still say "RFC 822 headers" and "RFC 821 commands" out of habit, and because the core semantics genuinely haven't changed. The numbers function as shorthand for a concept, not a strict citation of the current governing document. That's worth knowing before you go digging through older documentation or vendor specs. You'll see both number sets used interchangeably to mean the same thing.

From Protocol History to Modern Authentication and Diagnostics

None of the original standards, not RFC 821, not RFC 822, not even ESMTP, included any way to verify that a sender actually was who the From header claimed. SMTP was designed for a small, trusted research network. Trust wasn't a problem the original architects needed to solve, so they didn't.

How SPF, DKIM, and DMARC Extend a Trust Model SMTP Never Had

Decades later, as email became the default vector for phishing and spoofing, the industry bolted a trust layer onto a protocol that never had one. SPF checks whether a sending server is authorized for a domain. DKIM cryptographically signs message content. DMARC ties the two together and tells receiving servers what to do when checks fail. None of this required rewriting SMTP or the header format. It was layered on, extension by extension, the same way ESMTP itself was. For the mechanics of that layer, how SPF, DKIM, and DMARC actually work walks through each mechanism in detail.

That layering never stopped. DMARC's original specification was RFC 7489, published in March 2015 as an Informational document. It was obsoleted in May 2026 by DMARCbis: RFC 9989, alongside RFC 9990 and RFC 9991. RFC 9989 is a Proposed Standard, which is more standing than DMARC itself ever had. The signature layer is moving too. DKIM2 is in active development at the IETF, and it folds the chain-of-custody idea directly into the signature. So the timeline doesn't stop in 2015. It runs to this year.

Reading History Into a Modern Header Block

Every modern header block is a stratified record of this whole history. The From and Subject fields are RFC 822/5322 syntax, largely unchanged since 1982. The routing trail underneath reflects RFC 821/5321 transport decisions. An Authentication-Results header, if present, reflects trust mechanisms invented decades after the rest of the message format was already settled, a detail covered directly in the Authentication-Results header explained. Reading a header correctly means recognizing which era each field belongs to. The full delivery path and forged fields in a header is where that forensic reading gets applied to real, messy examples.

Practitioners tracing a bounce or a malformed header are, whether they realize it or not, debugging decisions made by working groups from the 1980s to the present. That's why this history isn't background reading. It's diagnostic context. Email Decoded structures its reference material as 15 chapters. They trace email from ARPANET-era message conventions all the way to DMARCbis and the DKIM2 drafts, treating protocol history as operational knowledge rather than trivia. Chapter 1 is titled "The History of Email — From ARPANET to DMARCbis" for exactly that reason. For anyone who wants the chapter-by-chapter version of this timeline, along with the practical guides it connects to, that's where the fuller technical reference lives.