How email works

The Problem Statement

Interviewer: "How does email actually work? Not just 'the sender sends a message and the recipient receives it,' but the actual protocol chain. When I send an email from Gmail to someone at a company using their own mail server, what happens technically? And why is spam so hard to stop?"

This question tests two things. First, whether you understand that email is a store-and-forward system built on top of TCP, not a real-time protocol. Second, whether you understand why the lack of built-in authentication in SMTP's original design created a structural spam problem that took thirty years and three separate protocols to partially address.

The follow-up questions include: "What stops anyone from sending email pretending to be from google.com? What is the difference between SPF, DKIM, and DMARC? How does a receiving mail server decide to put an email in spam versus inbox?"

---

Clarifying the Scenario

You: "Great question. Let me make sure I am covering what you find most interesting. Would you prefer I go deep on the SMTP protocol mechanics, the DNS components that make routing and authentication work, or the spam-fighting authentication protocols (SPF, DKIM, DMARC)?"

Interviewer: "All three. Start with a high-level architectural view of the actors, then walk through the actual SMTP handshake, then explain the authentication stack."

You: "Perfect. I will structure this in four parts. First, the four actors in the email architecture. Second, the full SMTP delivery flow from pressing send to arrival. Third, the MX record lookup that routes email to the right server. Fourth, the SPF, DKIM, DMARC authentication stack and how it addresses the structural spam problem."

You: "One question: should I cover IMAP and POP3 as well, for the retrieval side?"

Interviewer: "Yes, briefly. The delivery side is more interesting but cover retrieval too."

You: "Good. And one more clarification: should I assume this is Gmail sending to a custom domain company, or are we treating both sides as custom mail server configurations?"

Interviewer: "Gmail to a custom domain is a good framing. It covers the common case."

You: "Perfect. Gmail is a good example because it uses Google's own MTAs for server-to-server delivery, which makes the relay chain concrete. I can show exactly which DNS records get queried and in what order."

---

My Approach

I think about email as two separate problems that people frequently conflate. The first is delivery: getting a message from the sender's mail server to the recipient's mail server using SMTP. The second is retrieval: the recipient's mail client fetching the message from their mail server using IMAP or POP3.

This distinction solves a common interview confusion: people often ask "why does email sometimes arrive instantly and sometimes take minutes?" The answer is multi-hop. Delivery from sender MTA to receiver MTA is one independent operation. Retrieval from receiver MTA to the client is another. IMAP polling frequency and push notification setup on the client side determine the perceived arrival time, not just the SMTP delivery time.

SMTP is a push protocol. IMAP and POP3 are pull protocols. When you press "send" in Gmail, Gmail pushes the message to your company's mail server using SMTP. You later fetch your incoming messages by pulling from Gmail's mail server using IMAP.

This push/pull split is fundamental. It means a single email involves at minimum two separate protocol sessions: one SMTP push from sender's MTA to receiver's MTA, and one IMAP pull from the recipient's email client to their own mail server. Each hop has its own authentication, queuing, and failure mode.

The email architecture has four distinct actors:

1. MUA (Mail User Agent): The email client. Gmail web, Outlook, Thunderbird, Apple Mail. The MUA is responsible for composing messages, displaying received messages, managing folders, and communicating with the MTA over SMTP submission (for sending) and IMAP or POP3 (for retrieving).
2. MTA (Mail Transfer Agent): The mail server that accepts messages from clients and routes them between servers. Postfix, Sendmail, Microsoft Exchange. An MTA can act as both a submission endpoint (receiving from clients on port 587) and a relay (sending to other MTAs on port 25).
3. Relay: An intermediate MTA that passes the message along the route when the sender and recipient are on different networks. Large email providers use relay chains internally across data centers. Commercial email relay services (SendGrid, Amazon SES, Mailgun) function as managed relays that handle delivery, bounce tracking, and reputation management.
4. MDA (Mail Delivery Agent): The final delivery component that places the message in the recipient's mailbox. Dovecot, Procmail. The MDA runs on the same server as the receiving MTA and handles final sorting into folders, vacation auto-replies, and spam folder routing based on filter decisions.

---

The Architecture

The diagram below shows the full email delivery flow from sender to recipient. Each subgraph represents a distinct domain of control, and every arrow shows an actual network operation with its protocol and port.

Notice that the sender side and receiver side have completely separate concerns. The sender's MUA does not communicate directly with the recipient's MTA. It communicates with the sender's own MTA (submission), which then communicates with the recipient's MTA (relay/delivery). This indirection is what enables store-and-forward queuing and centralized spam filtering on both ends.

When you press send in Gmail, your browser sends the message to Gmail's MTA over HTTPS. This is the submission path. Gmail's MTA enqueues the message in its outbound queue with a store-and-forward guarantee: if delivery fails, Gmail will retry with exponential backoff for up to five days before returning a bounce.

To deliver the message, Gmail's MTA performs an MX record lookup: it queries DNS for the MX records of the recipient's domain. The DNS response contains one or more mail exchanger hostnames with priority values. The MTA picks the lowest-priority value (lowest number = highest priority in MX semantics), resolves it to an IP address, and opens a TCP connection to port 25 on the receiving mail server.

The receiving mail server checks three authentication protocols in sequence and uses the results to decide whether to deliver, quarantine, or reject the message. I will cover each protocol in depth in the deep dives.

The Real-Time Illusion

Email feels instant, but it is not a real-time protocol. The sequence has multiple asynchronous hops, each with its own queuing and retry layer.

When you press send at 10:00:00, your MUA sends to your MTA over HTTPS (10:00:01). The MTA enqueues the message with a 5-day guarantee and begins delivery immediately (10:00:02). The MTA performs an MX DNS lookup, typically with a 1-5 second TTL cache (10:00:02). The MTA opens a TCP connection and completes the SMTP handshake (10:00:03-4). The receiving MTA accepts the message, runs spam filters, and delivers to the mailbox (10:00:05-10). The recipient's MUA polls the mailbox via IMAP every 1-5 minutes by default, or receives a push notification if the provider supports it (up to 10:05:00).

Total latency under normal conditions: 5-30 seconds end-to-end. Under degraded conditions (temporary failures, retry queues, spam filter delays): minutes to hours. This is fundamentally different from real-time messaging systems like SMS or push notifications.

---

The Full SMTP Delivery Flow

SMTP is a text-based protocol from 1982. The core command set has barely changed. Understanding the actual exchange explains both how email works and why it is structurally vulnerable to forgery.

After the TLS handshake, every subsequent SMTP command is encrypted. Before TLS, the server announces capabilities in response to EHLO (Extended HELO). The capabilities list includes STARTTLS, which signals the session can be upgraded. If both sides support TLS, the upgrade happens before MAIL FROM.

The MAIL FROM: command specifies the envelope sender (the return-path). The From: header in the message body is the display sender. These can be different addresses. Spam exploits this: MAIL FROM: might be a throwaway address, but From: shows a trusted name. SPF validates MAIL FROM:, not the From: header.

Store-and-Forward Queuing