The journey of an email

Module 1: How email works · Reading time: 9 minutes

Learning objective: After this lesson, you can describe step by step how an email gets from the sender to the recipient, and say which program or server does the work at each step.

Key concepts: mail program (MUA), sending server (MSA, submission), mail server (MTA), MX record, queue, delivery (MDA), mailbox, retrieving (IMAP/POP3), envelope, headers

Email is post, not a chat message

When you send a chat message, it goes through a single company: the sender's app and the recipient's app talk to the same servers. Email works differently. The sender and the recipient can each be with a different provider: one with a hosting company, another with Gmail, a third with Microsoft 365 or their own company server. Yet the email still arrives. That works because every mail server in the world follows the same agreements.

You can compare email to the postal system. You write a letter (the message), put it in an envelope with an address (the envelope), take it to the postbox (the sending server), the postal company works out where the address is (the MX lookup), transports the letter to the right sorting centre (the receiving mail server), which puts it in the recipient's letterbox (the mailbox). The recipient picks it up there whenever suits them.

The stations in order

Say Anna sends a mail from anna@example.com to jan@example.net. Here's what happens:

With small providers, the MSA, the MTA and the MDA are often one and the same program on one server. With large providers, they're separate clusters. It makes little difference to you: these are roles, not boxes.

Notice the difference between step 1 and step 4. Both use SMTP, the Simple Mail Transfer Protocol (RFC 5321). But in step 1 you log in and use port 587 or 465; that's called submission (RFC 6409). In step 4, two servers talk to each other on port 25, without logging in: the receiving server accepts mail for its own domains from anyone. In lesson 1.4 you'll see why this separation exists.

Step 3 up close: the MX lookup

The sending server doesn't automatically know where example.net receives its mail. It asks the DNS:

example.net.   3600  IN  MX  10 mx1.mailprovider.example.
example.net.   3600  IN  MX  20 mx2.mailprovider.example.

The lowest number takes priority. The server first tries mx1, and if that doesn't respond, mx2. It then looks up the IP address of that name (A or AAAA record) and connects.

Two special cases you'll come across in practice:

• No MX record. Then the sender tries the A or AAAA record of the domain itself (the "implicit MX" from RFC 5321, section 5.1). This is a leftover from the past and doesn't work reliably; every domain that receives mail should have an MX.
• A null MX: 0 . This means: "this domain never receives mail" (RFC 7505). The domain example.com has one like this. A sender gives up immediately and sends back an error message, instead of continuing to try for days.

You can read exactly how MX records and priorities work in lesson 4.1 of the DNS course.

The queue: email is allowed to take its time

A mail doesn't always arrive within a second. If the receiving server doesn't respond, or says "try again later" (a code starting with 4), the mail stays in the sending server's queue. It tries again later, with increasing time between attempts. RFC 5321 (section 4.5.4.1) recommends at least 30 minutes between attempts and only giving up after 4 to 5 days. Many servers send a warning after a few hours ("delayed", not yet delivered) and the final error message after a few days.

This is one of email's great strengths: if a mail server is down for an hour, no mail gets lost. It's also why a mail sometimes arrives only hours later. In module 6 you'll see how to recognise such a delay.

Envelope and headers: two addresses

Just like with the post, an email has two kinds of addresses:

• The envelope. These are the addresses the servers use between themselves in the SMTP conversation: MAIL FROM (the sender for error messages, later visible as Return-Path) and RCPT TO (the recipient). Servers deliver based on the envelope.
• The headers. This is what's in the letter itself: From:, To:, Cc:, Subject:, Date:. Your mail program shows these.

Usually they match, but not always. A BCC recipient is in the envelope, but not in the headers; that's why others don't see them. A newsletter service puts its own address as the envelope sender, so error messages go to the service, while your address appears in From:. And a scammer can put whatever they like in From:.

Why this matters: SPF checks the envelope sender, the user sees the From:. That's why DMARC exists, to link the two together (module 4).

Where it can go wrong

With this picture in mind, you can ask for any problem: at which station does it go wrong?

• Sending fails (error message straight away in your program): step 1 or 2. Almost always settings: port, login, password (module 2).
• You get a bounce back: step 4 or 5. The receiving server rejected the mail, or the address doesn't exist (module 6).
• The mail arrives, but in the spam folder: step 5. The recipient doesn't trust the mail (modules 4 and 5).
• The recipient sees nothing, and you get no error message: the mail may still be in a queue, or has been silently filtered at the recipient's end. The sending server's logs help here (module 6).
• No mail arrives for your domain at all: step 3. The MX records are wrong, for example after a move (module 8).

In practice: what this looks like with a hosting package

With a WebOké hosting package, a single server per package handles all the roles: your mail program delivers the mail to that server (step 1 and 2), the server sends it out (step 3 and 4) and receives mail for your domain (step 5). In DirectAdmin you can use E-mail Tracking to see per message whether it was delivered. With other providers it works in a similar way; there such a feature might be called "message tracking" or "mail log".

Summary

• A mail travels from your mail program (MUA) via the sending server (MSA/MTA) to the receiving server (MTA/MDA) and from there to the recipient's mail program.
• Sending from your program is SMTP submission with login (587/465); servers talk SMTP to each other on port 25; retrieving is done with IMAP or POP3.
• The sending server looks up the MX records of the domain after the @. A null MX (0 .) means: this domain doesn't receive mail.
• A mail that can't be delivered immediately stays in the queue and is retried for days.
• Envelope (Return-Path) and headers (From) are two different senders. SPF looks at the first, the user at the second.

Quiz

Exercise

Exercise Z1.1: Finding the first mail server. Look up the MX records of gmail.com (or your own domain). Fill in which server is tried first, with its priority number, and one IP address (IPv4 or IPv6) of that server. The program looks up the same data live and checks it.

Further reading

The steps in these articles apply to WebOké's panels; with other providers it works in a similar way.

• How sending email works / SMTP
• DirectAdmin guide 8.7: IMAP or POP3: what's the difference?
• Free DNS course 4.1: MX records and priority
• RFC 5321 (SMTP), section 5.1 (MX and implicit MX) and 4.5.4.1 (retrying); RFC 7505 (null MX)