We Never Think About It

Email is one of those things you use every single day without ever wondering how it works. So how does it work?

The Actors

The actors involved in email are:

All of these agents, protocols, and infrastructure are completely invisible to you if you use an email provider like Google or Microsoft. If you want to avoid this, you have two main routes:

  1. You just buy the domain (for instance alexgherghe.com), choose a company that can host the email infrastructure for you (Proton, Fastmail, etc.) and you point your domain's MX (Mail Exchange) records to your chosen host.
  2. Alternatively, you just buy (or rent) a server (or use a VPS) and you set up the entire email infrastructure yourself, including buying the domain, setting up the MX records, configuring the MTA, MDA, and MRA, and managing the server. This requires a lot of time (both for setup and maintenance) and you really need to know what you're doing, so almost nobody does it. If you're wondering what large enterprises do, then we can check what Adidas (it's just the first name that came to mind) does. A simple DNS lookup via dig MX adidas.com on Mac reveals that they're using Microsoft to host their corporate email infrastructure: adidas.com. 28800 IN MX 10 adidas-com.mail.protection.outlook.com.

The Road Your Email Takes

Now that we know who all the actors are, let's trace the journey your message takes from your keyboard all the way to the other person's screen.

Step 1: MUA to MSA (Hitting Send)

When you click Send in Gmail, Outlook, Apple Mail, or Thunderbird, your MUA (Mail User Agent) packages up your message with the sender address, recipient address, subject, headers, body, and attachments.

Your MUA then connects to your provider's MSA using SMTP. SMTP has been the backbone of email since 1982 (RFC 821, later updated by RFC 5321). This submission connection almost always happens on port 587 with TLS encryption.

The MSA requires you to authenticate first (using your username/password or OAuth credentials). Once authenticated, the MSA checks the message for formatting issues, stamps submission headers, and hands it off to your sending MTA (Mail Transmission Agent). In practice, email providers usually run the MSA and MTA bundled together on the same server.

Step 2: The Sender's MTA Finds the Destination (DNS MX Lookup)

Your provider's MTA now has the job of getting the message to the recipient. It inspects the recipient address and needs to find out which other machine is responsible for handling mail for that recipient.

The MTA runs a DNS MX (Mail Exchange) lookup for the recipient's domain.

The response returns one or more MX records, each containing a mail server hostname along with a priority number. Lower priority numbers mean higher preference:

example.com.  MX  10  mail1.example.com.
example.com.  MX  20  mail2.example.com.

The sender's MTA picks the server with the lowest priority number (highest preference), resolves its IP address, and initiates the transfer. If that server is unreachable, it falls back to the next one.

Step 3: MTA to MTA (The SMTP Relay)

Once the sender's MTA resolves the recipient mail server's IP address, it opens a direct connection to the recipient's MTA on port 25. Modern MTAs will then use STARTTLS to opportunistically upgrade this connection to TLS, encrypting the message in transit (just like the MUA-to-MSA hop uses TLS on port 587).

The two MTAs have a short, structured conversation over SMTP:

  1. EHLO: The sending MTA introduces itself (for example, EHLO mail.yourprovider.com).
  2. MAIL FROM: "I have a message from you@yourprovider.com."
  3. RCPT TO: "It's addressed to someone@example.com."
  4. DATA: The sending MTA transmits the actual headers and message body.
  5. QUIT: The transfer completes and the connection closes.

Depending on the network setup, your email might also pass through intermediate relay MTAs along the way. Each MTA that touches the message adds a Received: header to the top, creating a traceable audit trail of the route.

If something goes wrong (the inbox doesn't exist, the mailbox is full, or the server rejects the connection), the recipient's MTA responds with an error code. The sending MTA will queue the message and retry delivery for a while (typically up to 4-5 days, per RFC 5321) before giving up and sending you a bounce-back email.

Step 4: MTA to MDA (Delivery to Storage)

Once the recipient's MTA accepts the message, it doesn't store it long-term. Its only job is transmission.

It immediately hands the email over to the MDA (Mail Delivery Agent), typically via LMTP (Local Mail Transfer Protocol) or by piping the message directly to a local process.

The MDA is the component that actually writes the email into the recipient's storage mailbox (such as a Maildir directory on a Linux server, a database, or cloud object storage). The MDA is also where server-side delivery rules run: it sorts mail into folders, checks spam filter tags, and handles any user-defined inbox rules.

Step 5: MRA to Recipient MUA (Retrieving the Email)

The message is now stored on the recipient's mail server, but the recipient hasn't seen it yet. When they open their phone, laptop, or desktop client, their MUA needs to retrieve it from storage.

This is where the MRA (Mail Retrieval Agent) comes into play. The recipient's MUA talks to the MRA using one of two classic protocols:

What About Spam?

You might be wondering: if any server can just connect to another server and say "here's an email from ceo@google.com," couldn't anyone fake that? The answer is yes, absolutely, and that's exactly why email spam was such a nightmare for decades.

To fight this, three mechanisms were developed:

Some Takeaways

The whole system is honestly a bit of a patchwork of protocols from different eras, held together by backwards compatibility and good-enough security extensions. But it works, and it's the backbone of how billions of people communicate every day.