Updated 10 hours ago
When you click Send, your message doesn't teleport to its destination. It embarks on a journey through a chain of servers, each one receiving it, examining the address, and passing it forward—like a letter handed from postmaster to postmaster across a network of digital post offices.
This system has worked since the 1970s. Understanding how it works reveals something surprising: email is built on machines being polite to each other.
The Cast of Characters
Four types of software make email work:
Mail User Agents are what you see—Gmail, Outlook, Apple Mail. They compose and display messages but don't deliver them. When you hit Send, your client hands the message to a server and says "take it from here."
Mail Transfer Agents are the delivery trucks. These servers accept outgoing mail and route it across the Internet, hopping from server to server until they reach the destination. They speak SMTP—Simple Mail Transfer Protocol.
Mail Delivery Agents receive incoming mail from the transfer agents and file it into the right mailbox. They're the last stop before your message reaches the recipient's inbox.
Mail Retrieval Agents let you read what's been delivered. When your email client checks for new messages, it's talking to a retrieval system using IMAP or POP3.
These four components—compose, transfer, deliver, retrieve—form a relay chain that spans the globe.
The Journey
You compose an email to friend@example.com and click Send. Here's what happens:
Your email client connects to your outgoing mail server on port 587 or 465. It authenticates with your username and password, then uploads the message: recipient addresses, subject line, body, attachments.
Your server looks at friend@example.com and extracts the domain: example.com. It queries DNS for MX records—special DNS entries that say "mail for this domain goes to these servers." DNS might return:
The numbers are priorities. Your server tries mail1 first; if that fails, mail2.
Now comes the interesting part.
The Conversation
Every email you've ever sent began with one server saying hello to another, stating its name, and waiting for permission to speak.
SMTP isn't a data dump—it's a dialogue. Your server connects to the recipient's server and they have a conversation:
Look at that exchange. The sender introduces itself (EHLO). The receiver acknowledges. The sender says who the mail is from, who it's for, and waits for permission at each step. Only after receiving "250 OK" does it proceed. A single period on its own line signals "I'm done speaking."
This is a social protocol encoded in software. Servers are polite because the protocol requires it.
If the receiver accepts the message, it hands off to the Mail Delivery Agent, which drops the message into your friend's mailbox. It sits there until your friend's email client retrieves it.
Message Anatomy
Email messages follow a format defined by RFC 5322: headers, a blank line, then body.
Headers carry metadata—who sent it, who receives it, subject, date, a unique message ID. As the message passes through servers, each one stamps it with a Received header. These headers stack up, creating a breadcrumb trail of the message's journey. Reading them bottom-to-top shows you exactly which servers handled your email and when.
The body is the content. Plain text for simple messages, or MIME (Multipurpose Internet Mail Extensions) for HTML formatting, attachments, and international characters.
Getting Your Mail
SMTP delivers mail to servers. Separate protocols let you retrieve it:
IMAP treats the server as the source of truth. Your email client shows you messages that live on the server. Delete something on your phone, it's gone on your laptop too. This is how multi-device email works—every client is a window into the same mailbox.
POP3 downloads messages to your device, typically deleting the server copy. Simpler, but breaks multi-device sync. It's mostly a legacy protocol now.
Webmail (Gmail's interface, Outlook.com) works the same way as IMAP—you're viewing messages stored on the server.
Security Layers
Email predates the modern Internet's security concerns. Messages originally traveled as plain text, readable by anyone along the path.
Today, three layers address this:
Transport encryption with TLS protects messages between servers. When servers connect, they can upgrade to encrypted communication using STARTTLS. This encrypts the conversation but not the message itself—each server in the chain can read it.
Authentication (SMTP AUTH) ensures only authorized users send through a server. Your server requires your password before accepting outgoing mail.
End-to-end encryption with S/MIME or PGP encrypts the message content itself. Only the intended recipient can decrypt it. But these technologies are complex to set up and see limited use outside security-conscious contexts.
DNS: The Address Book
Email depends on DNS more than you might expect.
MX records tell senders where to deliver mail for a domain. But DNS also enables authentication. SPF records list which servers are authorized to send mail for a domain. DKIM uses DNS to publish cryptographic keys for verifying message signatures. DMARC ties these together with policies for handling failures.
When a server receives mail claiming to be from example.com, it can check DNS to verify the claim. This is how email fights spoofing and phishing—though imperfectly, since not all domains implement these protections.
Why Email Survives
Email has outlasted countless communication technologies because it's not owned by anyone.
Gmail can talk to Outlook can talk to a mail server running on a Raspberry Pi in someone's closet. No company controls the protocol. Anyone can implement it, extend it, or build on it.
This interoperability is rare. Most messaging platforms are walled gardens—you can't send a WhatsApp message to Signal. Email is the exception: an open protocol that anyone can join.
That's why email became the universal digital identity. It's the account you need for everything else. Five decades in, the system of servers passing messages and politely asking permission continues to work.
Frequently Asked Questions About Email
Was this page helpful?