How Email Actually Works: From Click to Inbox, Step by Step
Email is one of those technologies that feels completely mundane until you start thinking about how it actually works. Then it becomes fascinating. Think about what happens when you hit "Send" on an email: a message you composed on your phone in Tokyo lands in someone's inbox in Toronto within seconds. It crosses oceans, passes through multiple servers, avoids spam filters, and arrives formatted exactly right.
Behind that seamless experience is a surprisingly elegant system of multiple protocols, servers, and standards that have evolved over 50 years. Let's trace the complete journey of an email from the moment you hit Send to the moment it lands in someone's inbox.
The Key Protocols: SMTP, IMAP, POP3
Email is built on three main protocols, each handling a different part of the process:
SMTP (Simple Mail Transfer Protocol): Used for *sending* email — from your email client to your mail server, and from server to server. Think of it as the postal truck that moves mail between post offices.
IMAP (Internet Message Access Protocol): Used for *reading* email stored on a server. Your email client connects to the mail server and synchronizes with it. Mail lives on the server; your client just views it. This is what most people use today.
POP3 (Post Office Protocol version 3): An older protocol for *downloading* email from a server to your device. Unlike IMAP, POP3 typically downloads and deletes messages from the server. Less common now because it doesn't support accessing email from multiple devices.
The Journey of an Email
Let's say you're using Gmail and you send an email to someone at Outlook (Microsoft's email service). Here's exactly what happens:
Step 1: You hit Send
Your email client (the Gmail web interface, or the Gmail app) takes your composed message and formats it according to the email message standard (RFC 5322). This standard defines how email headers (From, To, Subject, Date, etc.) and body are structured.
The formatted message is then submitted to Gmail's mail servers using SMTP, typically over port 587 (with authentication) or port 465 (SMTPS, SMTP over TLS). Your client authenticates with Gmail's server using your username and password. Without authentication, anyone could submit email claiming to be from anyone — which is exactly what spammers try to do.
Step 2: Gmail's Server Takes Over
Gmail's mail submission server receives your message and passes it internally to Gmail's outbound SMTP relay — the server responsible for actually sending mail to external services.
Before sending, Gmail performs several checks and adds information:
Step 3: DNS MX Record Lookup
The Gmail relay needs to figure out where to deliver the email. The "To" address is `someone@outlook.com`. The part before the @ is the user (`someone`), and the part after is the domain (`outlook.com`).
Gmail's server performs a DNS lookup for the MX records of `outlook.com`. MX records (Mail Exchange records) specify which servers accept email for a domain. The lookup returns something like:
```
outlook.com. 3600 IN MX 10 outlook-com.olc.protection.outlook.com.
```
This tells Gmail: to deliver email to `outlook.com`, send it to `outlook-com.olc.protection.outlook.com`.
Step 4: Gmail Connects to Microsoft's Mail Server
Gmail's server initiates a TCP connection to Microsoft's mail server on port 25 (the standard SMTP port for server-to-server communication). A TLS encrypted session is negotiated (using STARTTLS) to protect the email in transit.
Then the two servers have a short conversation using SMTP commands:
```
Gmail: EHLO gmail.com
Microsoft: 250 Hello
Gmail: MAIL FROM: <you@gmail.com>
Microsoft: 250 OK
Gmail: RCPT TO: <someone@outlook.com>
Microsoft: 250 OK
Gmail: DATA
Microsoft: 354 Send message content
Gmail: [sends the full email message]
Gmail: .
Microsoft: 250 OK, message accepted
Gmail: QUIT
```
It looks almost old-fashioned in its simplicity. But this protocol has been running the world's email for over 40 years.
Step 5: Microsoft's Server Accepts and Processes the Email
Microsoft's server receives the message. But it doesn't just store it immediately — it performs a series of checks:
SPF (Sender Policy Framework): SPF allows domain owners to publish (via DNS TXT records) a list of which mail servers are authorized to send email on behalf of their domain. Microsoft's server checks whether the Gmail server that just connected to it is on Gmail's authorized sender list. This helps detect spoofed "From" addresses.
DKIM (DomainKeys Identified Mail): Gmail adds a cryptographic signature to outgoing emails using a private key. Microsoft's server looks up Gmail's public key (published in Gmail's DNS records) and verifies that the signature is valid. This proves the email really did come from Gmail and hasn't been modified in transit.
DMARC (Domain-based Message Authentication, Reporting, and Conformance): DMARC lets domain owners specify what to do when SPF and DKIM checks fail — reject the message, quarantine it (send to spam), or just report it. Microsoft checks whether Gmail's domain has a DMARC policy and follows it.
Spam and malware filtering: Microsoft runs the message through its spam detection systems (machine learning models, reputation databases, content analysis). If it looks like spam, it might be rejected or sent to the junk folder.
Step 6: Delivery to the Recipient's Mailbox
If the message passes all checks, Microsoft's server stores it in the recipient's mailbox on their mail storage servers.
Step 7: The Recipient Checks Their Email
When `someone@outlook.com` opens their Outlook app or web interface, their client connects to Microsoft's mail server using IMAP (over port 993, encrypted with TLS). The client synchronizes with the server — downloading new message headers, then full message content when the user opens a message.
The email appears in the inbox. The user reads it. The whole journey, from your click to their inbox, took a few seconds.
What "Email Headers" Really Are
Every email has a visible part (the body and the basic headers like From, To, Subject) and a much more detailed set of message headers that most email clients hide by default. These headers are the full audit trail of an email's journey.
In Gmail, you can view them by clicking the three-dot menu on an email and selecting "Show original." You'll see something like:
```
Received: from mail-lj1-x231.google.com (EHLO mail-lj1-x231.google.com)
by mx.microsoft.com with ESMTPS
for <someone@outlook.com>; Wed, 22 May 2024 10:23:15 +0000
Received: from [192.168.1.100] (pool-71-174-16-25.bstnma.fios.verizon.net)
by smtp.gmail.com with ESMTPSA;
Wed, 22 May 2024 10:23:14 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; h=from:to:subject:date:message-id;
bh=...
From: you@gmail.com
To: someone@outlook.com
Subject: Hello
Date: Wed, 22 May 2024 10:23:10 +0000
Message-ID: <CABvEnBq...@mail.gmail.com>
```
The `Received:` headers are added by each server the email passes through, recording the server name, IP address, and timestamp. Reading them from bottom to top traces the email's journey from origin to destination.
These headers are incredibly useful for diagnosing email delivery problems. Security researchers also use them to trace spam and phishing emails back to their sources.
Why Email Spam Is Hard to Eliminate
Email spam has been a problem since nearly the beginning of email. The original SMTP protocol had no authentication — anyone could claim to be anyone. The email equivalent of sending an anonymous letter.
SPF, DKIM, and DMARC were developed to address this, and they've helped significantly. But spam persists because:
Modern spam filters use machine learning, behavioral analysis, sender reputation systems, and content analysis to catch spam. Gmail reportedly blocks 99.9% of spam before it reaches users. And still, spam makes up a majority of all email traffic on the internet — estimates range from 45% to 85% depending on how it's measured.
Email Security Beyond Spam Filtering
End-to-end encryption: The email journey we described above protects email *in transit* between servers (with TLS). But the email servers themselves can read the messages — they have to, to deliver them. For true privacy, you need end-to-end encryption, where only the sender and recipient can read the message.
PGP (Pretty Good Privacy) and S/MIME are standards for end-to-end email encryption. They're technically sound but have seen limited adoption because they're complex to set up and use. Most people don't use end-to-end encrypted email.
ProtonMail and Tutanota are email services that offer end-to-end encryption by default within their systems, but messages sent to regular email accounts (like Gmail or Outlook) still only have transport encryption.
The MIME Standard: Making Email Rich
The original email format only supported plain ASCII text. No attachments, no HTML formatting, no images.
MIME (Multipurpose Internet Mail Extensions) extended the email format to support:
When you send an email with a PDF attachment, MIME encodes the PDF as base64 (a way to represent binary data as text) and includes it as a separate part of the email message. The recipient's email client decodes it and presents it as a downloadable attachment.
Modern HTML emails — with images, styled text, buttons, and layouts — are essentially small web pages embedded in an email message using MIME multipart format. Which is why some email clients show ugly HTML code when things go wrong, and why marketing emails sometimes look very different in different email clients.
Why Email Still Matters
Despite predictions that email would be replaced by messaging apps, social media, or collaboration tools, email continues to be foundational to digital communication. It's the one communication channel that's genuinely universal and interoperable — you can email anyone with an email address, regardless of what email service they use, without any special setup or both parties being on the same platform.
Messages, Slack, Teams, WhatsApp — each is a walled garden. Email is the open standard that everyone uses. That's a remarkably durable advantage, and it's why email — now over 50 years old — shows no sign of going away.
The system isn't perfect. Spam is a nuisance. Security could be better. The protocols show their age. But as a piece of decentralized, open-standard communication infrastructure, email remains one of the internet's great success stories.