How email works

Email is older than the web, and in some ways older than the internet itself. In 1971, Ray Tomlinson of BBN wrote a program that sent messages between computers across the ARPANET (RFC 2235). The protocol that carries email today, the Simple Mail Transfer Protocol (SMTP), was first specified in RFC 821 in 1982, and its current version, RFC 5321, still builds on the commands of the original.

Unlike most of the protocols in this series, email is store and forward. Sender and receiver never connect to each other. A message is handed from server to server, stored at each step, until it reaches the recipient’s mailbox, where it waits until they read it. This article follows a message on that journey and explains the checks that decide whether it is trusted.

The journey of a message

Alice, at example.com, writes to Bob, at example.org. Several programs with distinct jobs are involved:

1. Submission. Alice’s mail app, the mail user agent, sends the message to her provider’s submission server. It must log in first, and the connection is encrypted. Submission uses port 587, or port 465 with TLS from the start, which RFC 8314 recommends.
2. Finding the destination. Alice’s provider looks up the MX (mail exchanger) records of example.org in DNS. Each MX record names a mail server and a preference number; lower numbers are tried first. If a domain has no MX record, its address records are used instead. A domain can also publish a “null MX” record (RFC 7505) to say that it accepts no mail at all.
3. Transfer. The outgoing server connects to Bob’s mail server on port 25 and hands over the message with SMTP. Large providers often pass a message through several of their own servers on the way, each one using SMTP.
4. Delivery. Bob’s provider checks the message, filters spam, and stores it in Bob’s mailbox.
5. Access. Bob’s mail app reads the mailbox, usually with IMAP (RFC 9051) on port 993, which keeps the messages on the server and synchronizes them across all of Bob’s devices. The older POP3 (RFC 1939) downloads messages to one device instead. Webmail interfaces access the mailbox directly.

If Bob’s server cannot be reached, Alice’s server does not give up. It keeps the message in a queue and retries at increasing intervals, typically for several days, before it returns a failure notice, a bounce, to the sender.

The SMTP conversation

SMTP is a text protocol of commands and numbered replies, much like HTTP/1.1. A simplified exchange between Alice’s and Bob’s servers (S is the receiving server, C the sending one):

S: 220 mx.example.org ESMTP ready
C: EHLO mail.example.com
S: 250-mx.example.org
S: 250-SIZE 52428800
S: 250 STARTTLS
C: STARTTLS
S: 220 Ready to start TLS
   … TLS handshake; then the client greets the server again over the encrypted connection …
C: MAIL FROM:<alice@example.com>
S: 250 OK
C: RCPT TO:<bob@example.org>
S: 250 OK
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: Alice <alice@example.com>
C: To: Bob <bob@example.org>
C: Subject: Lunch on Friday?
C: Date: Tue, 6 Oct 2026 09:30:00 +0200
C: Message-ID: <20261006093000.4f2a@example.com>
C:
C: Shall we meet at noon?
C: .
S: 250 OK: queued
C: QUIT
S: 221 Bye

• EHLO opens the session and asks the server which extensions it supports, such as the maximum message size and STARTTLS (RFC 3207), which upgrades the connection to TLS.
• MAIL FROM gives the sender’s address and RCPT TO one recipient; it can be repeated for several recipients.
• DATA transfers the message itself, ended by a line containing a single dot.

Replies start with a three-digit code, and the first digit is what matters: 2 means success, 3 means “go on”, 4 means a temporary failure (try again later), and 5 means a permanent failure (do not retry). A 550 reply, for example, often means that the mailbox does not exist.

Envelope and header

The example shows Alice’s address twice, once in MAIL FROM and once in the From: line. They belong to two different layers, like the envelope of a letter and the letterhead inside it.

• The envelope consists of the MAIL FROM and RCPT TO addresses of the SMTP conversation. Servers use it to route the message. MAIL FROM is also the address that receives bounces; it is recorded in the delivered message as the Return-Path.
• The header is part of the message itself, defined in RFC 5322. Its From:, To:, Cc:, Subject: and Date: lines are what mail apps show.

Nothing in SMTP itself requires the two to match. This is what makes blind copies work: a Bcc recipient is added to the envelope only, so the other recipients never see the address. It is also what made forgery easy: anyone could write any From: line. The checks described below were created to close that gap.

Each server that handles a message adds a Received: line at the top of the header, with its name, the time and where the message came from. Read from the bottom up, these lines trace the message’s path, which makes them the first thing to look at when a message goes astray.

MIME: more than plain text

The original message format allowed only short lines of plain ASCII text. MIME (Multipurpose Internet Mail Extensions, RFC 2045 and the following RFCs) added everything else while keeping the old format valid:

• A Content-Type header names the kind of content, such as text/plain; charset=utf-8 or image/png.
• Multipart messages contain several parts, each with its own headers, separated by a boundary string.
• Encodings such as base64 turn binary data, like an attachment, into plain text that any server can carry.
• Non-ASCII text in headers, such as a subject in another script, is written as encoded words (RFC 2047). Today, the SMTPUTF8 extension (RFC 6531) also allows UTF-8 directly, even in addresses.

A typical message from a modern mail app is a tree: a multipart/mixed message holding the text and the attachments, where the text itself is a multipart/alternative with a plain version and an HTML version. The receiving app chooses the richest version it can display.

Fighting forgery: SPF, DKIM and DMARC

Because SMTP lets anyone claim any sender, spam and phishing have long relied on forged addresses. Three standards, all published in DNS by the domain owner, let a receiving server check where a message really comes from.

SPF: which servers may send

The Sender Policy Framework (RFC 7208) lets a domain list the servers allowed to send mail for it, in a TXT record:

example.com.  TXT  "v=spf1 ip4:192.0.2.0/24 include:_spf.mail.example.net -all"

This record says: the addresses in 192.0.2.0/24 may send, so may the servers listed by _spf.mail.example.net, and everyone else fails (-all). The receiving server checks the connecting server’s IP address against the policy of the envelope sender’s domain. SPF breaks when a message is forwarded, because the forwarding server is not on the original sender’s list.

DKIM: a signature on the message

DomainKeys Identified Mail (RFC 6376) adds a digital signature. The sending server signs selected header fields and the body with a private key and adds a DKIM-Signature header that names the signing domain (d=) and a selector (s=). The receiver fetches the matching public key from DNS, at selector._domainkey.domain, and verifies the signature. A valid signature shows that the signing domain vouched for the message and that the signed parts were not changed on the way. Because the signature travels with the message, it survives forwarding as long as the message is not modified.

DMARC: tying it to what the reader sees

SPF and DKIM each check a domain, but not necessarily the one in the From: line, which is the only address a reader sees. DMARC closes this gap with alignment: a message passes DMARC only if SPF or DKIM passed for a domain that matches the From: domain. The domain owner publishes a policy in DNS. DMARC was first published in 2015 as an informational document (RFC 7489); since May 2026, it is a standard, defined in RFC 9989, with its reports in RFC 9990 and RFC 9991.

_dmarc.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

The policy p= expresses what the domain owner would like receivers to do with messages that fail: none (no preference, only collect reports), quarantine (treat them as suspicious, typically by putting them in the spam folder) or reject. With rua=, the owner asks receivers for aggregate reports, usually daily, about the messages they saw in its name, which reveal both misconfigured legitimate servers and forgery attempts.

Receivers record the results of all three checks in an Authentication-Results header (RFC 8601), which most mail apps can display with the original message.

Encryption

Email has two separate kinds of protection, and they are easy to confuse.

Encryption in transit protects the connection between two servers, or between an app and its server. Submission and mailbox access are encrypted by default today. Between servers, STARTTLS is used whenever both sides support it, but it is opportunistic: an attacker on the path could remove the server’s STARTTLS offer, and the sender would fall back to plain text. Two standards let a receiving domain demand encryption: MTA-STS (RFC 8461), which publishes a policy over HTTPS, and DANE (RFC 7672), which publishes the server’s certificate information in DNS, protected by DNSSEC.

End-to-end encryption protects the message itself, so that even the mail providers cannot read it. Two standards exist, OpenPGP (RFC 9580) and S/MIME (RFC 8551), both based on public-key cryptography. Both require sender and recipient to manage keys, and header fields such as the subject usually remain readable.

Key points

• Email is store and forward: servers pass a message along with SMTP, and the recipient reads it later from their mailbox with IMAP or POP3.
• MX records in DNS tell a sending server where to deliver mail for a domain.
• The envelope (MAIL FROM, RCPT TO) routes a message; the header (From:, To:) is what people see. They can differ, which allows blind copies and, without checks, forgery.
• MIME adds attachments, formatted text and international characters to plain-text email.
• SPF authorizes sending servers, DKIM signs messages, and DMARC ties both to the visible From: address and tells receivers what to do with failures.