SMTP works through a TCP connection where the sender issues text commands and the server responds with numeric status codes. The basic sequence: EHLO greeting, optional STARTTLS upgrade, optional AUTH, MAIL FROM (envelope sender), RCPT TO (envelope recipient), DATA (message body), then QUIT. Each step must succeed before the next.

Which protocol is used for sending emails?

SMTP (Simple Mail Transfer Protocol), defined by RFC 5321. SMTP handles both server-to-server relay (between mail servers) and client submission (apps sending to a relay). For receiving mail, IMAP or POP3 is used — SMTP is sending-only.

What is an SMTP connection?

An SMTP connection is a TCP session between an SMTP client (mail sender) and an SMTP server (relay or recipient MX). The connection persists through a sequence of commands and responses, then closes with QUIT. Connections typically last seconds for a single message but can stay open for pipelined batches.

How does an email actually get delivered?

Five steps: the sending app submits the message via SMTP to a relay; the relay performs an MX DNS lookup for the recipient's domain; it opens an SMTP connection to that MX server; it issues SMTP commands to deliver the message; the recipient's server accepts the message and stores it in the mailbox. Mailbox providers then route to inbox or spam based on filters.

What is the difference between SMTP and IMAP?

SMTP sends mail. IMAP retrieves mail from a mailbox server. They're independent protocols that work together — your email client uses SMTP to send and IMAP to read. SMTP is stateless once the message is accepted; IMAP maintains synchronized folder state across devices.

How Does SMTP Work? A Technical Walkthrough

SMTP is one of the older protocols still in heavy daily use — the core spec dates to 1982, with the current revision in RFC 5321 from 2008. Understanding how it works at the wire level is essential for debugging deliverability issues, configuring infrastructure, and writing mail-handling code that doesn't break on edge cases.

This is a technical walkthrough of an SMTP session from start to finish.

What SMTP does

SMTP (Simple Mail Transfer Protocol) is the application-layer protocol used to transfer email between systems. It does two distinct things depending on context:

Server-to-server relay — your sending server delivers mail to the recipient's MX server. Port 25.
Client submission — a mail client or application submits mail to an SMTP relay for forward delivery. Ports 587 or 465.

The protocol commands are the same in both cases; the operational context differs. See SMTP port numbers explained for which port to use when.

The high-level flow

When you send an email, here's what happens:

Your mail client or application opens a TCP connection to an SMTP server
The client and server exchange a handshake (EHLO/HELO)
Optional: connection is upgraded to TLS via STARTTLS
Optional: client authenticates with credentials (AUTH)
Client declares the sender (MAIL FROM)
Client declares one or more recipients (RCPT TO)
Client sends the message body (DATA)
Server accepts and queues the message
Client disconnects (QUIT)

If this is server-to-server relay, the sending server then opens its own SMTP connection to the recipient's MX and repeats the flow.

A real SMTP session

Here's an actual SMTP session you can observe with openssl s_client or the swaks tool. The > lines are client output; < lines are server responses.

< 220 mx.example.com ESMTP

> EHLO sender.example.com
< 250-mx.example.com
< 250-PIPELINING
< 250-SIZE 35882577
< 250-STARTTLS
< 250-AUTH LOGIN PLAIN
< 250 8BITMIME

> STARTTLS
< 220 2.0.0 Ready to start TLS

[TLS handshake completes]

> EHLO sender.example.com
< 250-mx.example.com
< 250-PIPELINING
< 250-SIZE 35882577
< 250-AUTH LOGIN PLAIN
< 250 8BITMIME

> AUTH PLAIN <base64-encoded-credentials>
< 235 2.7.0 Authentication successful

> MAIL FROM:<[email protected]>
< 250 2.1.0 OK

> RCPT TO:<[email protected]>
< 250 2.1.5 OK

> DATA
< 354 End data with <CR><LF>.<CR><LF>

> From: [email protected]
> To: [email protected]
> Subject: Test message
>
> This is the body.
> .

< 250 2.0.0 OK: queued as ABC123XYZ

> QUIT
< 221 2.0.0 Bye

Each command line ends with CRLF (carriage return + line feed). The message body terminates with a line containing only a period (.).

SMTP commands

The core verbs:

Command	Purpose
`EHLO <hostname>`	Extended hello — replaces older HELO. Initiates session and lists server capabilities.
`STARTTLS`	Upgrade plaintext connection to TLS.
`AUTH <method>`	Authenticate with credentials (LOGIN, PLAIN, CRAM-MD5, OAUTH2).
`MAIL FROM:<addr>`	Declare envelope sender.
`RCPT TO:<addr>`	Declare envelope recipient. Repeated for multiple recipients.
`DATA`	Begin message body transmission.
`RSET`	Reset session state without disconnecting.
`VRFY <addr>`	Verify an address exists (most servers disable this).
`QUIT`	End session and disconnect.
`NOOP`	No-op, used for keepalive.

SMTP response codes

Every server response starts with a three-digit numeric code:

First digit	Meaning
2xx	Success
3xx	Intermediate (e.g., DATA expecting body)
4xx	Temporary failure — retry later
5xx	Permanent failure — do not retry

Common codes you'll see:

Code	Meaning
220	Service ready
221	Service closing
235	Authentication succeeded
250	Action completed
354	Start mail input
421	Service not available, try again later (often rate limiting)
450	Mailbox temporarily unavailable
451	Local error in processing
452	Insufficient system storage
550	Mailbox unavailable / message rejected
552	Message size exceeded
553	Mailbox name not allowed
554	Transaction failed (catch-all permanent error)

Many servers extend these with enhanced status codes per RFC 3463 — for example, 550 5.1.1 User unknown or 421 4.7.0 Temporary block. See common SMTP rejections for what these mean operationally.

The envelope vs the headers

SMTP separates two concepts that look similar but are distinct:

Envelope — what's negotiated in MAIL FROM / RCPT TO. This is what the server uses for routing and bounce handling.
Headers — the From:, To:, Subject:, etc. fields inside the DATA payload. This is what the recipient sees.

The envelope MAIL FROM (also called Return-Path) and the visible From: header can be different. This is common with mailing lists and ESPs — your ESP might set MAIL FROM to a bounce address ([email protected]) while the visible From: is yours.

SPF authenticates against the MAIL FROM domain. DKIM authenticates against the d= signing domain. DMARC alignment requires the authenticated identity to match the From: header. This three-way relationship is the source of most authentication confusion.

Practitioner note: When debugging delivery, always inspect both envelope and headers. The envelope shows you what SMTP did; the headers show you what the recipient sees. They tell different stories about the same message and you need both to diagnose anything non-trivial.

DNS dependency

For server-to-server SMTP relay, the sending server must look up the recipient's MX records:

dig MX example.com
;; ANSWER SECTION:
example.com.    3600    IN    MX    10  mx1.example.com.
example.com.    3600    IN    MX    20  mx2.example.com.

The sender connects to the lowest-priority MX first (lower number = higher preference). If no MX records exist, the sender falls back to an A/AAAA record on the domain itself (rare in modern setups).

The MX servers may themselves resolve to multiple A records for load balancing. See DNS records for email for the broader DNS picture.

TLS in SMTP

SMTP can run plaintext or encrypted. The two paths:

STARTTLS — connection starts plain, then issues STARTTLS to upgrade. Ports 25 (server-to-server, opportunistic), 587 (submission).
Implicit TLS — connection is encrypted from the first byte. Port 465 (submission).

Server-to-server STARTTLS is opportunistic — if the recipient server doesn't offer it, the sender falls back to plaintext. MTA-STS (RFC 8461) makes STARTTLS mandatory by publishing a policy via DNS and HTTPS. See MTA-STS setup.

Practitioner note: STARTTLS on port 25 between servers fails silently more often than people realize — a bad certificate, expired CA chain, or TLS version mismatch causes the sender to fall back to plaintext without any user-visible signal. Subscribe to TLS-RPT reports if you want visibility into how often this happens to mail addressed to your domain.

Why SMTP gets blocked

Mail can fail at any step:

TCP refused — firewall, port blocked at network level
TLS failure — invalid cert, version mismatch
AUTH failure — wrong credentials or rate-limited authentication attempts
MAIL FROM rejected — sender domain banned or SPF failure (in some configurations)
RCPT TO rejected — recipient unknown, mailbox full, or sender blocked
DATA rejected — content filtering, message too large, bad headers

Most production deliverability issues happen at MAIL FROM, RCPT TO, or after DATA — not at the connection layer.

Tools for working with SMTP

For debugging:

swaks — Swiss Army Knife for SMTP, the most useful CLI tool for sending test mail
openssl s_client — connect with TLS, see the handshake
dig — verify MX records
Wireshark — packet-level inspection (rare in practice)

For implementation:

Postfix (most popular open-source MTA)
Sendmail, Exim, OpenSMTPD (alternatives)
ESPs via SMTP submission (SendGrid, Mailgun, Postmark, Amazon SES)

See SMTP settings reference for configuration parameters across major platforms.

If you're standing up an SMTP server, debugging delivery issues, or trying to understand what your ESP is doing under the hood, book a consultation. SMTP-layer debugging is one of the more common reasons clients reach out.

Sources

v1.0 · May 2026