How email actually works: the journey of one message

You press Send, and a second later the message is on the other side of the world. It feels like a single action. In reality, your email makes a small journey through at least two companies' computers, is inspected several times, and is copied rather than moved at every step.

You don't need to know any of this to use email. But once you do, a lot of everyday mysteries make sense: why some emails arrive late, why spam exists at all, why "unsend" doesn't really work, and what those confusing SMTP and IMAP settings in your phone actually mean.

Let's follow one message. Aisha, who uses Gmail, emails her friend Omar, who has an address at his company, omar@example.com.

Stop 1: Aisha's app hands the message to her provider

When Aisha presses Send, her email app doesn't deliver anything itself. It hands the message to Gmail's outgoing mail server, a bit like dropping a letter at your local post office instead of walking it to your friend's house.

The language used for this handover is called SMTP, the Simple Mail Transfer Protocol. It's been the standard way to send email since 1982, and it's still how nearly every email in the world is sent. If you've ever set up an email account in an app manually, the "outgoing server" or "SMTP server" setting is this post office.

Before accepting the message, Gmail checks that Aisha is really logged in. This matters: an outgoing server that accepts mail from anyone is called an open relay, and spammers love them. Today, providers almost all require a login and use port 587 (or 465) with encryption for this step.

Stop 2: Finding where Omar's mail lives

Gmail now needs to know where to deliver mail for example.com. It asks the internet's address book, the DNS, a specific question: "What is the MX record for example.com?"

MX stands for Mail Exchanger. It's a line in a domain's settings that says "email for this domain should be delivered to this server". A domain can list several, with priorities, so if the main mail server is down, senders try the backup.

This is why you can change email providers without changing your address. If Omar's company moves from one provider to another, it updates its MX record, and within hours the whole world starts delivering its mail to the new place.

Stop 3: Two servers have a conversation

Gmail's server now connects to Omar's company mail server (on port 25, the traditional server-to-server port) and the two have a short, very formal conversation in SMTP. It looks roughly like this:

Server: 220 mx.example.com ready
Gmail:  EHLO mail-sor-f41.google.com
Server: 250 Hello, pleased to meet you
Gmail:  MAIL FROM:<aisha@gmail.com>
Server: 250 OK
Gmail:  RCPT TO:<omar@example.com>
Server: 250 OK
Gmail:  DATA
Server: 354 Go ahead
Gmail:  (the email itself: headers, text, attachments)
        .
Server: 250 Message accepted
Gmail:  QUIT

Two details here explain a lot about email.

First, the numbers. Every server reply starts with a three-digit code. Codes starting with 2 mean "fine", 4 means "temporary problem, try again later" and 5 means "permanent failure". When you get a bounce message saying 550 User unknown or 552 Mailbox full, you're reading a line from exactly this kind of conversation.

Second, notice that the sender is stated twice: once in MAIL FROM (the "envelope", used for delivery and bounces) and again inside the message itself, in the From: line you see in your inbox. Originally, nothing checked that these matched, or that either was true. That design decision, made when email connected a few trusting universities, is the root of spoofing and phishing. Modern checks called SPF, DKIM and DMARC were added decades later to close the gap. We explain them in SPF, DKIM and DMARC, explained simply.

These days, most big providers also say STARTTLS early in the conversation, which switches the connection to an encrypted one. That's why most mail is protected while travelling between servers, even though it isn't end-to-end encrypted.

Stop 4: The receiving server decides whether to trust it

Accepting a message isn't the same as delivering it to the inbox. Before Omar sees anything, his mail server runs a series of checks:

• Is the sending server allowed to send for gmail.com? (SPF)
• Is the message's digital signature valid? (DKIM)
• What does gmail.com say to do with failures? (DMARC)
• What's the reputation of the sending server and domain?
• Does the content look like spam, phishing or malware?

Based on the results, the message goes to the inbox, the spam folder or, occasionally, is quietly dropped. Some servers also use greylisting: they temporarily reject mail from an unfamiliar server with a 4xx code and wait to see if it tries again. Real mail servers always retry; many spam tools don't. The cost is that some first-time emails arrive a few minutes late, one of the reasons a verification email can be delayed.

Stop 5: Omar reads it (IMAP, POP3 and webmail)

The email now sits in Omar's mailbox on the server. SMTP's job is done; SMTP only sends and delivers. To read the mail, Omar's apps use a different protocol.

IMAP: the mailbox stays on the server

With IMAP (port 993 with encryption), your apps show you a live view of the mailbox on the server. Read an email on your phone and it shows as read on your laptop. Move it to a folder on one device and it moves everywhere. This is what almost everyone should use today.

POP3: download and (usually) delete

POP3 (port 995 with encryption) is older. It downloads messages to one device and, by default, removes them from the server. That made sense when server storage was expensive and people had one computer. Today it mostly causes confusion: "the email is on my laptop but not my phone".

Webmail and apps

When you use Gmail in a browser or the Gmail app, you're not using IMAP at all. You're looking at the mailbox directly through Google's own systems. IMAP and POP3 matter mainly when you connect an account to a different app, like Outlook, Apple Mail or Thunderbird.

What this journey explains

Why you can't unsend an email

At Stop 3, a copy of the message was handed to a completely different organisation's server. There's no step in SMTP for asking for it back. "Undo send" features work by waiting a few seconds before Stop 1 even begins.

Why spam exists

SMTP was designed so that any server could deliver mail to any other server, with no central authority and no cost per message. That openness is what made email universal, and it's also what makes spam cheap. Nearly all modern anti-spam technology is an attempt to add trust to a system that started without any.

Why emails are sometimes late

Any server along the way can be busy, can defer the message with a 4xx code, or can be retrying after a temporary failure. Senders typically keep retrying for up to several days before giving up and sending you a bounce.

Why temporary email works at all

A temporary email service like Mailfornet is simply a mail server with MX records for its domains that accepts mail for any address on them. When you generate k7fq2m@ one of those domains, the server was already willing to receive mail for it; the site just shows you what arrives. That's also why these services are receive-only: they run Stop 5 for you, but not Stop 1.

Quick reference: the settings your phone asks for

Your provider's help pages list the exact server names. When in doubt, choose IMAP for incoming mail and port 587 for outgoing.

The short version

Your app gives the message to your provider (SMTP). Your provider looks up where the recipient's mail lives (MX record) and delivers it there (SMTP again). The receiving server checks whether to trust it (SPF, DKIM, DMARC and spam filters). The recipient's apps then read it from their mailbox (IMAP, POP3 or webmail). Every email you've ever sent has made that journey, usually in less time than it takes to read this sentence.