SMTP Explained: How Email Gets Delivered (2026)

Email delivery is a surprisingly fragile dance between servers, and the protocol orchestrating it all, SMTP, is older than you might think.

Let’s watch a real email travel. Imagine Alice at alice@example.com sends an email to Bob at bob@anotherdomain.org.

Alice’s mail client (e.g., Outlook, Gmail web interface) talks to her outgoing mail server, mail.example.com. This part isn’t SMTP, it’s usually IMAP or POP3 for retrieval, or a proprietary API for sending. The key is, it gets handed off to the outgoing SMTP server.
mail.example.com needs to find bob@anotherdomain.org’s mail server. It consults DNS. Specifically, it looks up the MX (Mail Exchanger) record for anotherdomain.org.
```
$ dig MX anotherdomain.org
; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> MX anotherdomain.org
;; QUESTION SECTION:
;anotherdomain.org.		IN	MX

;; ANSWER SECTION:
anotherdomain.org.	3600	IN	MX	10 mail.anotherdomain.org.
```
This tells mail.example.com that mail.anotherdomain.org is the mail server for anotherdomain.org, with a preference of 10 (lower numbers are preferred).

mail.example.com then establishes a TCP connection to mail.anotherdomain.org on port 25, the standard SMTP port.

$ telnet mail.anotherdomain.org 25
Trying 192.168.1.100...
Connected to mail.anotherdomain.org.
Escape character is '^]'.
220 mail.anotherdomain.org ESMTP Postfix

The two servers then conduct a conversation using SMTP commands. This is the core of the delivery.
- EHLO (or HELO): The client (Alice’s server) introduces itself.
```
EHLO mail.example.com
250-mail.anotherdomain.org
250-PIPELINING
250-SIZE 52428800
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250 CHUNKING
```
  The server lists its capabilities. SIZE is important; it tells Alice’s server the maximum email size it accepts.
- MAIL FROM:: Alice’s server tells the recipient server who the email is from. This is the envelope sender, not necessarily the From: header.
```
MAIL FROM:<alice@example.com>
250 2.1.0 Ok
```
- RCPT TO:: Alice’s server tells the recipient server who the email is to.
```
RCPT TO:<bob@anotherdomain.org>
250 2.1.5 Ok
```
  If the recipient doesn’t exist, the server would typically respond with 550 5.1.1 <bob@anotherdomain.org>: Recipient address rejected: User unknown in virtual mailbox table.
- DATA: Alice’s server signals it’s ready to send the actual email content.
```
DATA
354 End data with <CR><LF>.<CR><LF>
```
- Email Content: Alice’s server sends the headers and body, ending with a single period on a line by itself.
```
From: Alice <alice@example.com>
To: Bob <bob@anotherdomain.org>
Subject: Meeting Tomorrow

Hi Bob,

Just confirming our meeting tomorrow at 10 AM.

Best,
Alice
.
250 2.0.0 Ok: queued as ABCDEF12345
```
- QUIT: The connection is closed.
```
QUIT
221 2.0.0 Bye
```

The problem this solves is establishing a standardized, server-to-server protocol for transferring email messages. It handles everything from initial connection and authentication to message content transfer and error reporting. The core levers you control are your server’s configuration: how it advertises capabilities (SIZE, AUTH), how it handles incoming connections (port 25, 587, 465), and its spam/security filters.

The most surprising true thing about SMTP is that the entire message content, including all headers and the body, is transmitted as plain text over the wire unless explicitly encrypted using STARTTLS. This means anyone sniffing the network traffic between the two mail servers could read the email in cleartext if the connection isn’t secured.

Once the message is accepted by mail.anotherdomain.org, it’s typically stored in Bob’s mailbox, and Bob’s email client will then use IMAP or POP3 to retrieve it.

The next problem you’ll likely encounter is understanding how DMARC, DKIM, and SPF work together to prevent spoofing.