How Does Email Work? A Protocol From 1982 Holding Up Remarkably Well

The journey has more stages than most people expect and each has a name:

• •Your client hands the message to your provider's submission server, authenticated with your credentials, which is the one point where identity is checked properly
• •That server looks up the recipient domain's mail exchanger records in the domain name system, which is how it finds where to deliver
• •It opens a connection to the receiving server and conducts a conversation in the Simple Mail Transfer Protocol, a text exchange of commands and numeric replies readable by a person
• •The receiving server accepts or rejects, and if it accepts it becomes responsible for the message and must either deliver it or generate a bounce
• •The message sits in a mailbox until the recipient's client retrieves it, historically with POP, which downloads and deletes, and now almost always with IMAP, which keeps the message on the server and synchronises state across devices
• •The message itself is plain text with headers, and everything else, attachments, formatting, images and non-Latin characters, is encoded into that text by a standard called MIME, which is why attachments inflate by about a third

The original protocol has no way to verify that a sender is who they claim to be. The address in the From header is supplied by the sending server and is never checked, which means anyone can send a message appearing to come from anyone, a fact that is obvious once stated and that underlies most of email's security problems. There is also an envelope sender, used for bounces, which is separate from the From header the user sees and can be different, which is legitimate for mailing lists and useful for forgers. The reason none of this was addressed is historical: the network the protocol was built for connected a small number of institutional machines operated by identifiable people, and adding authentication would have been solving a problem nobody had. The consequence is that every anti-forgery measure since has been bolted on as an additional check that receiving servers may or may not perform.

Modern deliverability depends on three published standards that let a domain owner state who may send on their behalf and prove it. SPF, the Sender Policy Framework, is a record in the domain name system listing which servers are authorised to send mail for the domain, so a receiver can check whether the connecting server is on the list. DKIM, DomainKeys Identified Mail, attaches a cryptographic signature to the message using a private key held by the sender, with the public key published in the domain's records, which lets a receiver verify that the message came from the domain and has not been altered in transit. DMARC ties the two together, letting a domain owner publish a policy saying what a receiver should do when a message fails both checks, whether to accept, quarantine or reject, and requesting reports about failures. The three are not optional in practice: the major providers now effectively require them from bulk senders, and a domain without them will find its legitimate mail filtered.

Deliverability is a system nobody designed and everybody must satisfy. A receiving provider decides whether to deliver a message to the inbox, to the spam folder or not at all, using reputation scores for the sending domain and address, authentication results, content analysis, the proportion of recipients who mark the sender as spam, whether the recipients engage, and whether the sending address has ever contacted a spam trap address that no legitimate sender should hold. A new sending domain has no reputation and must build one gradually, which is why bulk senders warm up an address by increasing volume slowly. The result is an opaque and consequential system in which a small business can find its invoices silently filtered with no notification and little recourse, and in which the practical advice is to authenticate properly, keep lists clean, honour unsubscribes immediately and avoid the formatting patterns that filters associate with bulk marketing.

Ordinary email is not private in the way most people assume. Transport encryption between servers is now common and opportunistic, meaning it is used when both ends support it and is not guaranteed, and it protects the message in transit and not at rest, so the provider on each side can read everything. Several major providers have processed message content for advertising, and legal access varies by jurisdiction. End-to-end encryption using standards such as PGP or S/MIME has existed for decades, encrypts the body so that only the recipient can read it, leaves the headers exposed so that who wrote to whom and when remains visible, and has never achieved general adoption because the key management is difficult for ordinary users. Tracking pixels, single transparent images loaded from a server when a message is opened, report that a message was read, when, and from what address, which is why blocking remote image loading is the single most effective privacy measure available in a mail client.

Email moves through a submission server, a lookup of the recipient domain's mail exchanger records, a text conversation between servers using a protocol standardised in 1982, and a mailbox the recipient's client synchronises. The protocol never verifies the sender's identity, which is why every anti-forgery measure is an added check, with SPF listing authorised servers, DKIM signing messages cryptographically and DMARC setting the policy on failure. Deliverability depends on an opaque reputation system, and ordinary email is readable by both providers.