How does email work? What happens when you hit send

Email works like a relay of post offices, where each server does one leg of the trip. When you hit send, your app hands the message to your provider's mail server, which looks up the recipient's mail server in the internet's address book, DNS, and passes the message across using a protocol called SMTP. The recipient's server checks it, files it in their mailbox, and their app fetches it. The whole trip usually takes seconds.

In short

• Sending and receiving are separate jobs: SMTP moves mail between servers, and IMAP or POP lets your app read the mailbox.
• DNS tells a sending server where a domain's mail goes, the same way it tells a browser where a website is.
• Email was designed without any check on who the sender is, which is why spam filters and SPF, DKIM and DMARC were added later.

Where did email come from?

Email is older than the internet itself. People could already leave messages for each other on a single shared computer in the 1960s. The leap came in 1971, when Ray Tomlinson, an engineer at the firm BBN, combined a messaging program with a file-transfer program so that a message could travel to a user on a different computer on the ARPANET, the US research network that grew into the internet. According to the Lemelson-MIT Program, he picked the @ sign to separate the user from the machine, and user@host is still the shape of every address.

Year	What changed
1971	Ray Tomlinson sends the first network email on the ARPANET and chooses the @ sign.
1982	SMTP, the Simple Mail Transfer Protocol, is published as RFC 821, the rulebook servers still follow.
1980s	POP and IMAP appear, letting people read mail held on a server from their own computer.
1996	Free web-based email spreads, and anyone with a browser can have an address.
2006–2015	SPF, DKIM and DMARC are first published as RFCs, the internet's technical rulebooks, to fight forged senders.
February 2024	Google starts requiring authentication from everyone who sends to Gmail, and all three from bulk senders.
May 2026	An updated DMARC standard, RFC 9989, replaces the 2015 version.

What happens when you hit send?

Follow one message. Ana, whose address is ana@example.org, writes to Ben at ben@example.net.

1. Ana's app submits the message. Her email app connects to her provider's outgoing server, signs in with her account and uploads the message over an encrypted connection.
2. The server looks up Ben's domain. It needs to know which machine takes mail for example.net, so it asks DNS, the internet's naming system, for that domain's MX (mail exchanger) record. The answer is a server name, such as mx.example.net, which DNS then turns into an IP address.
3. The two servers talk SMTP. Ana's server connects to Ben's on the standard mail port, 25, and they hold a short, scripted conversation in plain text. Stripped down, it looks like this:

S: 220 mx.example.net ready
C: EHLO mail.example.org
S: 250 mx.example.net
C: MAIL FROM:<ana@example.org>
S: 250 OK
C: RCPT TO:<ben@example.net>
S: 250 OK
C: DATA
S: 354 Send the message, end with a single dot
C: (the headers and body of the message)
C: .
S: 250 Queued for delivery

4. Ben's server checks it. Before accepting, it asks whether the sending server is allowed to send for example.org, whether the message carries a valid signature, and whether its content looks like spam. It may accept it, file it as junk, or refuse it.
5. The message waits in Ben's mailbox. It sits on Ben's provider's server, not on his phone.
6. Ben's app fetches it. His app connects to his provider with IMAP or POP and downloads or displays the new message.

SMTP's job ends at the recipient's server; fetching mail is a different protocol. If Ben's server is down, Ana's server doesn't give up: it keeps the message in a queue and retries for hours or days before sending Ana a bounce message saying it couldn't be delivered.

What's actually inside an email?

An email is plain text with two parts: headers and a body. Headers are lines such as From, To, Subject and Date, plus a trail of Received lines that each server adds as the message passes through, which is how anyone can trace the route an email took. The body is the message itself.

Plain text was all early email could carry, so attachments and formatting are fitted in with a standard called MIME, which turns files into text. The common encoding, base64, writes every 3 bytes of a file as 4 text characters, so attachments grow by about a third in transit. A 15 MB video becomes about 20 MB of email, which is one reason providers' size limits bite sooner than people expect.

IMAP or POP: what's the difference?

Both let an app read a mailbox, but they treat the server differently.

	IMAP	POP
Where the mail lives	Stays on the server; the app shows a copy	Usually downloaded to one device, then deleted from the server
Several devices	Yes, read and sorted mail matches everywhere	Poorly; each device sees its own copy
Folders	Kept on the server	Kept only on the device
Current standard	RFC 9051, IMAP4rev2, 2021	POP3, RFC 1939, 1996

Most people now use IMAP or a provider's own web and phone apps, which work the same way: the mailbox lives on the provider's servers, a form of cloud computing, and every device is a window onto it.

Why does email need spam filters and authentication?

Because SMTP trusts what it's told. The 1982 design let any server claim to send from any address, just as anyone can write any return address on an envelope. That openness made email easy to join, and easy to abuse: a large share of all email sent is spam, and forged senders are the raw material of phishing. Three standards were added on top to let a receiving server check a sender's claim:

Standard	What it checks	How
SPF (RFC 7208)	Is this server allowed to send for this domain?	The domain publishes, in DNS, a list of servers that may send its mail.
DKIM (RFC 6376)	Was this message really sent by the domain, and unchanged?	The sending server signs the message with a private key; the public key is in DNS.
DMARC (RFC 9989)	Does the visible From address match what SPF or DKIM checked, and what should happen if not?	The domain publishes a policy: deliver anyway, send to junk, or reject.

Big providers now push these hard. Since 1 February 2024, Google's sender guidelines require everyone sending to Gmail to use SPF or DKIM, and anyone sending more than 5,000 messages a day to use SPF, DKIM and DMARC and keep reported spam below 0.3%. On top of authentication, filters score each message on its content, links, sending history and how recipients have treated similar mail.

A common misconception is that a passed check means a message is safe. Authentication proves which domain sent a message, not that the domain is honest: a scammer can register a lookalike domain and set up SPF, DKIM and DMARC perfectly.

Is email private?

Partly. Most providers now encrypt the connection between servers and between server and app, so someone on the same café network can't read the message in transit. But the message is stored readable on both providers' servers, and copies may sit in backups. End-to-end encryption, where only sender and recipient hold the keys, exists through tools such as PGP and S/MIME but is rarely used for everyday mail. A useful rule: write email as if it could one day be forwarded.

Check yourself

• Without looking back: what does an MX record tell a sending server, and why is DNS needed at all?
• Which protocol carries a message between servers, and which ones let you read it?
• Why can a message pass SPF, DKIM and DMARC and still be a scam?

Sources

• Simple Mail Transfer Protocol, RFC 5321 — Internet Engineering Task Force, 2008
• Simple Mail Transfer Protocol, RFC 821 — Jonathan B. Postel, IETF, 1982
• Internet Message Access Protocol version 4rev2, RFC 9051 — Internet Engineering Task Force, 2021
• Domain-based Message Authentication, Reporting, and Conformance, RFC 9989 — Internet Engineering Task Force, 2026
• Email sender guidelines — Google Workspace Admin Help
• Ray Tomlinson — Lemelson-MIT Program