What Happens When You Send an Email

Sending an email feels instantaneous. You click Send, and within seconds — sometimes less — the message appears in someone’s inbox on the other side of the planet. That speed is real, but the journey an email takes to get there is surprisingly long: it passes through your own device, your email provider’s servers, the public internet, a series of checks for spam and fraud, and finally into the recipient’s mail system. Understanding each step makes the whole thing feel less like magic and more like an impressive feat of distributed engineering.

Step One: Your Mail Client Prepares the Message

When you hit Send in Gmail, Outlook, Apple Mail, or any other email client, the first thing that happens is entirely local. Your client assembles the raw message according to a standard called RFC 5322, which defines how email messages should be formatted: the From, To, Subject, and Date headers go at the top, separated from the message body by a blank line. If you have attached a file, the client encodes it using MIME (Multipurpose Internet Mail Extensions), which allows non-text content — images, PDFs, Word documents — to be embedded in what is fundamentally a text-based format.

Once formatted, the message is handed off over an encrypted connection to your outgoing mail server.

Step Two: SMTP — The Protocol That Moves Mail

The protocol that email servers use to send messages to each other is called SMTP (Simple Mail Transfer Protocol), and it has been around in recognisable form since 1982. SMTP is a text-based, command-and-response protocol: the sending server connects to the receiving server on TCP port 25 (or port 587 for client-to-server submission), they exchange a brief greeting, and then the sender delivers the message line by line.

Your email provider’s outbound server accepts your message via SMTP (with authentication, so only you can send from your account) and then takes responsibility for delivering it to the recipient’s server. If the recipient is using the same provider as you — say, both of you are on Gmail — the whole journey might stay within Google’s infrastructure. If you are sending to a different provider, the message must travel across the public internet.

Step Three: DNS and the MX Record

Before your provider’s mail server can deliver the message, it needs to know the address of the recipient’s mail server. It cannot just look up the recipient’s email address directly — that is not how the internet’s directory system works.

Instead, the server performs a DNS lookup for the MX record (Mail Exchanger record) of the recipient’s domain. If the recipient’s address is someone@example.com, the sending server queries DNS: “What are the mail servers responsible for example.com?” DNS returns one or more MX records, each with a priority number. The sending server tries the highest-priority server first; if that one is unavailable, it moves to the next.

This lookup is invisible and typically takes only a few milliseconds. It is also why you can own a custom domain and still use any major email provider to handle your mail — you just update your domain’s MX records to point at the provider’s servers.

Step Four: Delivery and the Spam Gauntlet

The recipient’s mail server does not simply accept every incoming message. Before the message is stored in anyone’s mailbox, it passes through a series of automated checks designed to detect spam, phishing, and malware.

SPF (Sender Policy Framework) lets domain owners publish a list of IP addresses that are authorised to send email on their behalf. If a message arrives claiming to be from @example.com but comes from an IP not on the SPF list, that is a strong signal of spoofing.

DKIM (DomainKeys Identified Mail) takes a different approach. The sending server cryptographically signs the message headers and body using a private key. The recipient’s server can then look up the corresponding public key in DNS and verify that the message has not been tampered with in transit and genuinely originated from the claimed domain.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) sits on top of SPF and DKIM, allowing domain owners to publish a policy — in DNS again — that tells receiving servers what to do if a message fails authentication: deliver it, quarantine it (send to spam), or reject it outright.

Beyond these technical checks, spam filters apply machine learning models trained on millions of examples of known spam and legitimate mail. They look at the message’s content, the sender’s reputation, whether similar messages have been flagged recently, and dozens of other signals. A message that passes SPF, DKIM, and DMARC can still end up in the spam folder if its content triggers these behavioural filters.

Step Five: Stored in the Mailbox

Once the incoming server has accepted the message and passed it through the spam pipeline, it is stored in the recipient’s mailbox — typically in a format like Maildir on disk or in a database on the provider’s infrastructure. The message now sits waiting, taking up a small amount of storage.

The recipient’s server also handles aliasing at this point: if the address info@company.com is an alias that forwards to jane@company.com, that routing happens on the server before the message reaches permanent storage.

Step Six: Retrieval — IMAP and POP3

The final step is retrieval. When the recipient opens their email client, that client connects to the incoming mail server using one of two protocols.

POP3 (Post Office Protocol 3) is the older option. It downloads messages from the server to the local device and, in its default configuration, deletes them from the server. This works fine if you access email from a single device but causes problems if you check the same account on a phone, laptop, and tablet.

IMAP (Internet Message Access Protocol) is the modern choice. Instead of downloading messages, IMAP synchronises them: the messages stay on the server, and every device you use sees the same inbox, the same folder structure, and the same read/unread status. When you archive a message on your phone, it disappears from your laptop’s inbox too — because both are viewing the same mailbox on the server.

A Journey That Takes Milliseconds

From Send to delivered, the whole process typically takes less than a second for a message between well-configured providers. The parts that introduce delay are usually the spam filtering pipeline, temporary unavailability of the recipient’s server (the sending server will keep trying for up to 72 hours before giving up), or a slow DNS lookup. Considering the number of independent systems involved — your client, your provider, DNS, the public internet, the recipient’s provider, and their spam filters — the speed at which email reliably works is a remarkable achievement.