How the history of email works

01The mailbox metaphor

The first email was not sent across a network. It was left on a single computer. In the early 1970s, users on the same mainframe took turns logging in. If you wanted to send a message to another user, you wrote it in a file and placed it in a directory the other person could see. The other user would log in later, find the message, and read it. There was no real-time delivery because there was no network. The mailbox metaphor came from this physical arrangement: messages were left in a place, and the recipient would come to collect them.

This mailbox model turned out to be remarkably durable. Even as email evolved into a real-time global system, the underlying architecture never abandoned the store-and-forward principle. A message is composed, handed to a server, stored, forwarded to another server, stored again, and eventually delivered to a mailbox where the recipient retrieves it at their convenience. The metaphor of leaving a letter in a box shaped every protocol that followed. Ray Tomlinson, who sent the first network email in 1971, chose the @ symbol to separate the user from the machine because it was a preposition that made grammatical sense: a user at a host. That single decision created an addressing convention that has survived unchanged for over fifty years.

02SMTP: the protocol that made email universal

The Simple Mail Transfer Protocol, defined in RFC 821 in 1982, is what made email universal. Before SMTP, there were many incompatible email systems. IBM had its own system, Digital Equipment had its own, and universities had theirs. Messages could not travel between them. SMTP solved this by defining a simple, universal language for exchanging mail between servers. A sending server would connect to a receiving server, announce itself, specify the sender and recipient, transmit the message body, and disconnect. The protocol was intentionally minimal. It did not define how mail was stored, how it was displayed, or how it was read. It only defined how mail moved from one server to another.

This minimalism was the key to its success. Because SMTP only handled transmission, any system could implement it. A Unix server, a Windows machine, a mainframe, and a personal computer could all exchange mail as long as they spoke SMTP. The protocol did not care what happened before the message was sent or after it was received. It only cared about the transfer. This separation of concerns, between the transport layer and everything else, is why email outlasted every proprietary messaging system that tried to compete with it. By 1995, SMTP was the standard, and proprietary mail systems were either adapting to it or disappearing.

03How a message actually moves

When you send an email today, the process involves multiple servers and multiple protocols working together. Your email client (the Mail User Agent) connects to your outgoing mail server using SMTP or a variant called SMTP Submission on port 587. The server checks who you are, accepts the message, and then looks up the recipient domain in the Domain Name System. DNS returns Mail Exchange records that tell your server where to send the message. Your server then connects to the recipient mail server, also using SMTP, and delivers the message. The recipient server stores the message in a mailbox. When the recipient checks their mail, their client retrieves it using either POP3 or IMAP. The message has traveled through at least two servers, used three protocols, and consulted DNS, all in a fraction of a second.

The genius of this architecture is that each step is independent. The client that composes the message does not need to know how the server delivers it. The server that receives the message does not need to know what the recipient does with it. The protocol that retrieves the message does not need to know how it was sent. This modularity means that any component can be replaced without breaking the system. Webmail replaced desktop clients. IMAP replaced POP3. TLS encryption was added to every step. Spam filters were inserted at the server level. None of these changes required a new email system. They all fit into the existing architecture because the architecture was designed to be extensible from the start.

04Store and forward: the architecture of patience

Email was designed for a world where connections were intermittent and unreliable. The store-and-forward architecture reflects this. When a server receives a message, it stores it immediately. If it cannot deliver the message to the next server, it holds it and retries. The first email systems would dial up a phone line, attempt to connect, and if the line was busy, queue the message and try again later. This was not a limitation; it was a feature. In a world where computers were not always on and networks were not always available, store-and-forward guaranteed that messages would eventually arrive, even if the infrastructure was unreliable.

Modern email still uses store-and-forward, even though the infrastructure is now reliable. Your message is stored on your outgoing server, forwarded to the recipient server, stored there, and retrieved by the recipient. The architecture has not changed because the principle is still sound. Store-and-forward means that the sender and receiver do not need to be online at the same time. This is what makes email different from instant messaging, phone calls, and video chats. Those systems require both parties to be present simultaneously. Email does not. It is asynchronous by design, and that asynchrony is one of the reasons it remains the most used communication tool in the world.

05Headers: the hidden metadata of every message

Every email carries a hidden layer of metadata called headers. These headers are not visible in the normal message view, but they are present in every email ever sent. They record the path the message took through the network: which server received it, when, from which server, and what authentication checks were performed. A typical email has a Received header for each server it passed through, creating a traceable route from sender to recipient. It has a Message-ID that uniquely identifies the message worldwide. It has a Date header, a From header, a To header, and a Subject header. It may have authentication headers like SPF, DKIM, and DMARC results that verify the sender identity.

The header system is one of the most important and least understood parts of email. It is what makes email traceable, debuggable, and securable. When a message goes to spam, the headers explain why. When a message is delayed, the timestamps in the headers show where the delay occurred. When a message is forged, the authentication headers reveal the forgery. The headers are the audit trail of email, and they exist because the original designers understood that a communication system without traceability is a communication system without accountability. The headers are not a feature added later; they were part of the design from the beginning.

06Why email survived everything

Email has survived the rise and fall of many communication technologies. It survived the fax machine, which was supposed to replace it for business communication. It survived instant messaging, which was supposed to make it obsolete for quick exchanges. It survived social media, which was supposed to replace it for personal communication. It survived Slack, Teams, and every workplace chat tool that was supposed to replace it for internal collaboration. It has survived because it does something none of those tools do: it provides a universal, asynchronous, interoperable communication channel that anyone can use to reach anyone else, regardless of what system they are on.

The interoperability is the crucial point. You can send an email from a Gmail account to an Outlook account to a self-hosted server to a Yahoo account to a corporate Exchange server. They all speak the same protocol. There is no Gmail-to-Outlook barrier, no Yahoo-to-corporate barrier. This is not true of any other communication tool. You cannot send a Slack message to a Teams user. You cannot send a WhatsApp message to a Telegram user. You cannot send a Signal message to an iMessage user. These systems are walled gardens. Email is the open field. The protocol is the standard, and the standard is the reason email is still here.

07The cost of openness

The same openness that makes email universal also makes it vulnerable. Because anyone can send email to anyone, anyone does. Spam, phishing, scams, and malware have been part of email since the early 1990s. The first large-scale spam was sent in 1994 when a law firm advertised its immigration services to thousands of Usenet users. By the 2000s, spam accounted for over 90 percent of all email traffic. The email community responded with a layered defense: SPF to verify that the sending server was authorized, DKIM to cryptographically sign messages, DMARC to tell receiving servers what to do with messages that failed authentication, and increasingly sophisticated spam filters that use machine learning to classify messages.

The battle against spam is ongoing and will never end, because the openness that enables spam is the same openness that makes email valuable. You cannot close email to unauthorized senders without also closing it to legitimate senders. Every spam filter that blocks a malicious message also risks blocking a legitimate one. Every authentication check that rejects a forged email also risks rejecting a real one. The email community has accepted this tradeoff as the cost of openness. The system is not perfect, and it will never be perfect, but the alternative, a closed, controlled, permission-based system, would not be email. It would be something else entirely, and it would not have the reach, the universality, or the resilience of email.