How Email Actually Works

Every email starts with a lie — or at least a convenient illusion. The compose window shows you simple fields: To, From, Subject, Body. But underneath that friendly UI, your email client is building a structured document with dozens of headers, MIME encoding, and an envelope that's completely separate from the message itself.

This distinction between the envelope and the content is fundamental. The envelope (MAIL FROM and RCPT TO) tells servers where to route the message. The content (the From: and To: headers) is what you see in your inbox. They don't have to match — and that mismatch is exactly how email spoofing works.

Try editing the compose form below and watch the raw SMTP message update in real-time. Notice how the same information appears in two different formats — human-readable and machine-readable.

SMTP is a surprisingly conversational protocol. Your server doesn't just blast a message at the recipient — it has a structured back-and-forth dialogue, like two people on a phone call. The server introduces itself, the recipient confirms it's listening, then they negotiate how to transfer the message.

The conversation starts with a TCP connection to port 25 (server-to-server) or port 587 (client submission with auth). The receiving server responds with a 220 greeting — its way of saying "I'm here and ready." Your server then says EHLO (Extended Hello), and the conversation begins.

Every SMTP response starts with a three-digit code. 2xx means success. 3xx means "keep going" (like 354 after DATA). 4xx is a temporary error (try again). 5xx is permanent failure (don't retry). The entire protocol runs on this simple numbering system defined in 1982.

Try it yourself. The terminal below simulates a real SMTP session — type each command and watch the server respond.

Before your server can deliver the message, it needs to find out where to send it. The recipient's address says alice@example.com, but what IP address actually handles mail for example.com?

This is where MX records come in. Your server queries DNS for the MX (Mail Exchange) records of the recipient domain. These records list one or more mail servers, each with a priority number. Lower priority = tried first. If the primary server is down, email falls back to the next one.

The DNS resolution path goes: root servers → TLD servers (.com, .org) → authoritative nameserver for the domain → MX records. This usually takes 20-100ms. The result is cached, so subsequent emails to the same domain skip the lookup.

Try looking up the MX records for any domain below. You'll see exactly which servers accept mail for that domain and in what priority order.

Email rarely goes directly from sender to recipient. It hops through multiple servers — your outbound mail server, possibly a relay service (like AWS SES or Google's SMTP relay), the recipient's inbound MX server, and finally the IMAP store where the message lands.

Each server that touches the email adds a Received: header — a stamp showing where the message came from, which server processed it, and when. These headers stack in reverse order: the top Received header is the last hop, and the bottom one is the first.

This chain of Received headers is how you trace an email's journey across the internet. It's also how receiving servers detect suspicious routing — if an email claims to be from Google but the Received chain shows it originated from an unknown server in a different country, that's a red flag.

SMTP was designed in 1982 — before spam, before phishing, before anyone imagined email would carry financial transactions. The protocol has zero built-in authentication. Any server can claim to be sending from any domain. It's like a postal system where anyone can write any return address on an envelope.

Three protocols were added later to fix this: SPF (2006), DKIM (2007), and DMARC (2012). Together, they form the authentication chain that modern email depends on. When the recipient's server receives your message, it runs all three checks before deciding whether to deliver, quarantine, or reject.

After passing authentication, the email lands in the recipient's mail store. The recipient's email client retrieves it using IMAP (Internet Message Access Protocol) or the older POP3. IMAP keeps messages on the server and syncs across devices; POP3 downloads and (traditionally) deletes from the server.

The full circle is complete. From compose window to SMTP handshake, through DNS resolution and server relays, past authentication checks, and into the inbox. The entire journey typically takes 1-5 seconds — though queuing, greylisting, or retry logic can extend it to minutes or hours.

Below is the complete Received header chain from our email's journey. Each header was added by a different server at a different step — read bottom to top to trace the path.