Email’s near-miss
Email is the federated peer-to-peer system that survived. The Simple Mail Transfer Protocol Jon Postel specified in RFC 821 in August 1982 still runs the world’s email. The architecture has not changed: any host on the internet can run an SMTP server, accept incoming mail from any other SMTP server, send outgoing mail to any other SMTP server, and participate as a peer in a network in which there is no central authority and no central administrator. Email addresses are still under the domain owner’s control. Mail still propagates through DNS-mediated host-to-host transfer. The protocol still works. By the structural criteria this book has been applying — federation, peer status, lack of central control, user choice of provider — email is the great success story of the pre-web internet, the one piece of federated infrastructure that did not fall to the consolidation that ate the others.
This story is half right. Email survived. It survived in compromised form. The protocol is still federated; the actual sending and receiving of email, however, is in 2026 controlled by an oligopoly of three or four providers who collectively host most of the world’s mailboxes and who collectively decide what mail flows through the network and what does not. Setting up your own SMTP server is technically possible and effectively impractical, in a way that is structurally different from anything Postel intended. The system worked, then was overwhelmed by spam, then was rescued by an anti-spam regime that incidentally centralized control of the network into the hands of the operators who could afford to participate in it. The chapter is about how this happened, what was preserved, what was lost, and what it would mean to fix email at this point.
The protocol that worked
Email predates SMTP. Ray Tomlinson at Bolt, Beranek and Newman sent the first network email message between two computers on the ARPANET in 1971, using a program called SNDMSG running on the host’s existing operating system mailbox. Tomlinson chose the @ symbol to separate the user from the host, a choice that has survived through every subsequent revision of email addressing. Through the 1970s, email proliferated on the ARPANET with various ad-hoc transport mechanisms; by the late 1970s the ad-hoc mechanisms were producing interoperability problems serious enough to motivate a standardization effort. SMTP, published as RFC 821 in August 1982, was the result. The companion specification RFC 822, by Dave Crocker the same month, defined the message format — the headers, the body, the addressing — that has remained substantially unchanged since. RFC 974, in 1986, defined MX records, which let DNS resolve a domain name to the appropriate mail-receiving host.
The architecture had several properties that gave email its character. Mail addresses had two parts: the local part (the user) and the domain (the host or the organization). The domain was a DNS name, resolved through the federated DNS hierarchy. The MX record told the sending host which actual server to deliver to. Mail traveled in clear text across the network, with no encryption at the transport layer (TLS for SMTP would arrive later, as RFC 3207 in 2002). Mail was best-effort: SMTP servers retried failed deliveries for several days before giving up, and bounced messages back to the sender if delivery was not possible. The protocol was simple enough that an experienced programmer could implement an SMTP server in a weekend; many did.
The federation was the design’s central commitment. There was no central mail authority. There was no required intermediary. A host with SMTP, an MX record in DNS, and a connection to the internet was, structurally, an email peer. Anyone with such a host could send and receive mail from anyone else with such a host. The promise of email in the 1980s was the promise of a global mail network in which any organization, large or small, could participate on equal terms with any other. This promise was kept for the first two decades of email’s mass use. It is not kept now.
How mail propagated
The flow of an email message in the 1980s and through most of the 1990s was simple. A user composed a message on their host. The host’s mail submission daemon received the message and queued it for delivery. The mail transport daemon read the recipient address, looked up the recipient’s domain in DNS, found the MX record pointing to the recipient’s mail server, opened an SMTP connection to that server, and delivered the message. The recipient’s mail server stored the message in the recipient’s mailbox. The recipient’s mail client — running on the same machine, or accessing the mailbox remotely through POP3 or IMAP — read the message.
This flow assumed several things that are no longer assumed. It assumed that the sender’s host was a real internet host with a routable IP address. It assumed that the recipient’s host was a real internet host with a routable IP address. It assumed that the sender’s host’s IP was not on any blocklist. It assumed that any host receiving mail would attempt to deliver it. It assumed that the sender was identified by their address in the From: header, accurately. None of these assumptions held by the late 1990s. The deviation from them is the substance of what happened to email.
POP3 and IMAP, the protocols for accessing remote mailboxes, were added in the mid-1980s and refined through the 1990s. POP3 (RFC 1939 in its 1996 form, earlier in earlier versions) let a user retrieve mail from a remote server to their local machine. IMAP (RFC 1730 in 1994, refined in subsequent RFCs) let a user manipulate their mailbox on the server without downloading the entire contents. These protocols separated the role of the mail server (which received and stored mail) from the role of the mail client (which let the user read and compose). The separation made it possible for a user to access their mail from multiple devices and from multiple locations, and it laid the groundwork for the later separation of mail hosting from mail reading.
MIME — Multipurpose Internet Mail Extensions, specified by Nathaniel Borenstein and Ned Freed in RFCs 1521, 1522, and later updated in 2045-2049 between 1992 and 1996 — added the ability to send non-ASCII content, structured messages with multiple parts, and attachments. MIME extended email substantially beyond the plain-text design of the early protocol. The extensions have proven durable; modern email is still MIME at the wire format level, with the elaborations that have accumulated since.
The arrival of spam
The first widely cited piece of internet spam was sent on May 3, 1978, by Gary Thuerk, a marketer at Digital Equipment Corporation, to several hundred ARPANET users, advertising a DEC product demonstration. The message was met with disapproval and was discussed extensively at the time; it did not, however, establish a pattern. Spam in any volume did not become a serious problem on the network for another decade and a half, because the network was small enough and the participants culturally similar enough that the social cost of sending unwanted mass mail was greater than the benefit.
This changed in the mid-1990s, for the same reasons everything else in this book changed: the internet became commercially significant, the participants became more numerous and more diverse, and the social mechanisms that had previously constrained unwanted behavior stopped scaling. The Canter and Siegel Green Card spam in 1994, discussed in the previous chapter as a Usenet event, was also delivered to email mailing lists, and was followed by a steady increase in the volume of unsolicited commercial email through the late 1990s.
By the early 2000s, the situation was severe. Studies estimated that spam constituted more than half of all email traffic by 2003 and more than 70% by 2005. Mailbox operators were spending substantial resources on filtering. Users were drowning in unwanted mail. The protocol had no built-in defense against spam — it had been designed in an era when the cost of sending mail was real (you needed a machine on the internet) and the social cost of misbehaving was high (your peers would refuse to peer with you). Both conditions had eroded. Sending spam was effectively free, and the spammers’ peers, paid to provide internet access regardless of what was sent, had no incentive to police them.
The response was an arms race. Filtering at the receiving end developed quickly: heuristic filters that looked for spam-like patterns, Bayesian filters that learned from labeled examples (Paul Graham’s 2002 essay “A Plan for Spam” was widely influential in popularizing Bayesian approaches), reputation systems that scored senders by their past behavior, and blocklists that aggregated bad-actor IP addresses for sharing across operators. The DNSBL — DNS-based blacklist — became a standard way for receivers to query whether a sending IP was known to send spam. By the mid-2000s, the major receivers were running aggressive multi-layered filtering pipelines.
The arms race also pushed authentication. SPF (Sender Policy Framework, RFC 4408 in 2006) let a domain owner specify which IP addresses were authorized to send mail for that domain. DKIM (DomainKeys Identified Mail, RFC 4871 in 2007) let a sender cryptographically sign their outgoing mail with a key published in DNS. DMARC (RFC 7489 in 2015) combined SPF and DKIM with a policy framework that let domains specify how receivers should treat messages that failed authentication. By the late 2010s, SPF, DKIM, and DMARC were considered table stakes for serious mail senders; mail without all three was treated with suspicion.
The deliverability problem
The cumulative effect of the anti-spam arms race was that sending email reliably became hard. Receivers — particularly the major receiving providers, by then a small number of companies handling most of the world’s inboxes — had developed elaborate criteria for what to accept and what to filter. An organization sending email at any volume had to satisfy these criteria. SPF, DKIM, and DMARC had to be configured correctly. The sending IP had to have a clean reputation. The sending domain had to have a history of sending legitimate mail. The mail had to pass content filters. The pattern of sending had to look normal. The recipient list had to be clean of invalid addresses, complaint-generators, and known spam traps. None of this was negotiable. Mail that did not satisfy the criteria was filtered, often silently, with no notification to the sender.
The criteria are reasonable defenses against spam. They are also, structurally, a barrier to entry. A new domain, with no sending history, has a difficult path to deliverability. A small organization sending mail from its own server has to navigate the deliverability requirements without the benefit of professional anti-abuse staff. An individual self-hosting their email faces a meaningfully different problem from what self-hosting email was in 1995. The cost of joining the federation has gone up, and the cost is paid in skilled-time-and-attention to satisfy the major receivers’ criteria.
The major receivers have, in turn, become a small set. Gmail, launched by Google on April 1, 2004 (the famously skeptical reception, given the date, did not last), grew rapidly through the 2000s and by the mid-2010s was hosting hundreds of millions of mailboxes. Microsoft’s Outlook/Hotmail/Live family of services hosts comparable numbers. Yahoo Mail, Apple’s iCloud Mail, the various ISP-provided mail services, and the enterprise-focused providers (Google Workspace, Microsoft 365) collectively account for the great majority of the world’s mailboxes. Estimates vary, but the rough numbers in 2026 are that Gmail and Outlook between them serve over half of consumer mailboxes globally, and that the top five providers serve a clear majority.
This concentration changes the practical meaning of email’s federation. The protocol is still federated; anyone with a domain and a server can in principle send and receive mail. The actual receiving of mail, however, happens at a small number of operators. To send mail that reaches users in 2026, you mostly have to satisfy the criteria of Gmail and Outlook. Their criteria are not transparent. Their judgment is final. Their reasons for filtering particular messages are typically not given. A self-hosted email sender who finds their mail going to Gmail’s spam folder has limited recourse. The federation has become a federation in name and an oligopoly in practice.
The encryption that did not happen
A parallel story runs alongside the deliverability story. Email was designed in clear text. Anyone with access to the network between the sender and receiver could, in principle, read the message. As email became important for sensitive personal and commercial communication, this property became uncomfortable. The protocol-level fix — encrypting the connections between mail servers — arrived in 2002 with RFC 3207 (STARTTLS for SMTP). By the mid-2010s most major mail providers were using TLS for inter-server transport, encrypting mail in transit, with cooperation campaigns by Google and others to push the remaining holdouts toward encrypted transport.
End-to-end encryption — encryption of the message content such that only the sender and the recipient can read it, with no possibility of reading by intermediate servers — is a different problem. The most prominent attempt was PGP, Pretty Good Privacy, written by Phil Zimmermann and released in 1991. PGP let users encrypt messages with their recipients’ public keys, so that only the holder of the corresponding private key could decrypt them. PGP was, technically, a serious piece of cryptographic software. It was also, in its key-management requirements and user-interface complexity, prohibitive for most users. The slogan “PGP is unusable” became a recurring conclusion of usability studies.
PGP did not become widely adopted. Its successor projects — GnuPG, various GUI integrations, the WebKey Directory standard, Autocrypt — have not made it widely adopted either. S/MIME, the X.509-based alternative, has had some uptake in corporate settings but is similarly invisible to most users. The result is that the great majority of email in 2026 is not end-to-end encrypted. The major providers can read the contents of the mail they handle, and they use this access for various purposes (spam filtering, search indexing, advertising in some cases, machine-learning training in others). The trade-off between encryption and the various server-side features users want — search, filtering, classification — has been resolved, structurally, in favor of the server-side features and against end-to-end encryption.
Self-hosting in 2026
It is worth being specific about what self-hosting email looks like in 2026. The technical components are easier to assemble than they have ever been: containerized mail servers, automation tools, modern TLS, automatic DKIM key generation, integrated SPF/DKIM/DMARC configuration. A motivated individual can have a self-hosted email setup running in a few hours. What they cannot easily achieve is reliable deliverability to Gmail and Outlook.
The reasons are well documented in the running commentary of the self-hosting community. New IPs get blocked. Cloud-provider IPs are often pre-blocked by major receivers because spammers use them. Even with SPF/DKIM/DMARC correctly configured, new sending domains have to slowly build reputation by sending small volumes of high-quality mail and gradually increasing volume. The reputation can be lost easily; a few users marking messages as spam can put a domain on a receiver’s bad list, and getting off the list is difficult. The major receivers do not generally explain their decisions or provide remediation paths beyond their general-purpose appeal forms.
The cumulative practical effect is that the federated peer model email was designed around is, in 2026, available only to operators who can afford to maintain serious anti-abuse practice. Most individuals and small organizations who try to self-host email find that they need to relay through a commercial mail-sending service (Mailgun, SendGrid, Postmark, Amazon SES) to achieve acceptable deliverability. The relay services have their own reputations and their own infrastructure to satisfy the major receivers. The structure has, in a generation, become hierarchical: receivers at the top, large senders and relay services in the middle, smaller senders depending on the relay services, individual users at the bottom. The peer-to-peer federation has been preserved in name and replaced in practice with a layered system in which the top of the layer is held by a small number of operators.
What has been recovered, attempted, and remains
There are recovery efforts. The smaller mail providers — Fastmail, ProtonMail, Mailbox.org, Tutanota, and a handful of others — operate as alternatives to the major receivers, with various positioning around privacy, encryption, or independence from the advertising-driven mail providers. ProtonMail, founded in 2014, has been particularly visible for its end-to-end encryption when both parties are on ProtonMail. Fastmail has been operating as an independent paid email provider since 1999. The smaller providers maintain deliverability with the major receivers through investment in anti-abuse practice and through their reputations as cooperative members of the mail community; they do not, however, change the structural problem.
JMAP (JSON Meta Application Protocol), specified in RFC 8620 in 2019, is a modern replacement for IMAP designed for better performance and easier client implementation. JMAP is structurally analogous to IMAP — it specifies how clients talk to their mailbox provider — and so does not by itself change the federation story. It does, however, make it easier for new mail clients to participate in the ecosystem, which has some indirect benefits for the broader mail community.
Various decentralization proposals exist for email. Federated identity systems, distributed mail servers, blockchain-based replacements, post-quantum encryption — there is a steady trickle of research and small-scale experiment. None of these has approached mainstream adoption. The cost of email’s deliverability problem is high enough, and the alternative protocols are immature enough, that the practical alternative for most users is to stay with the major providers and accept the structural concentration.
What email keeps and what email lost
What email kept is the protocol-level federation: the architecture by which any domain owner can in principle participate as a peer, the addressing scheme that does not depend on a platform, the message format that is the same across all participants, and the basic operations (send, receive, forward, reply) that work the same way regardless of provider. These are real and they matter. A user whose email is provided by Gmail can correspond with a user whose email is provided by Fastmail without either party knowing or caring which providers the other is using. The choice of provider is a user-side choice in a way that platform choices on social media are not. A user who wants to leave Gmail can take their mail with them and continue using their existing address (if they own the domain) or change their address (if they were using @gmail.com) without changing how email works.
What email lost is the practical equality of participation. The federated structure that the protocol describes is not the structure email actually has. A user setting up email from scratch in 2026 has dramatically fewer practical options than a user doing the same in 1996. The path to running your own mail server, achieving deliverability, and being a fully participating peer in the email network is narrower than it was. The major receivers have, through the necessity of fighting spam, accumulated the practical power to decide who participates in the network on what terms. The power is exercised reasonably most of the time and unreasonably some of the time, and the affected parties have limited recourse in either case.
The thing email is, then, is the federated system that survived in deteriorated form. It is the case study for what the other federated systems would have looked like if they had survived. The fact that email survived at all — that it was not absorbed into walled-garden replacements the way Usenet was — is the encouraging part of the story. The fact that surviving has not been free of compromise is the cautionary part. The federated peer system Postel specified in 1982 still exists. The kind of mass participation in it that the design implied is harder to come by than it was, and the structural reasons for the difficulty are not going to go away.
The next chapter takes the strangest and most ambitious of the pre-web alternative architectures. Plan 9 from Bell Labs was the operating system the Unix team built when they decided that Unix had not been ambitious enough. It treated the network as native, every resource as a file, every file as accessible from anywhere on the network, and every operation as a file operation. It did not win. It was not supposed to win, in the commercial sense. But what it proposed about how computing should look has been quietly adopted, in pieces, by almost every system that has come since, and the parts that have not been adopted are the parts most worth looking at.