DeliverabilityDNS

SMTP: what RFC 5321 actually defines

Q: What's the difference between the SMTP envelope and the message headers?

The envelope (MAIL FROM, RCPT TO) is what SMTP itself uses for routing and what SPF checks. The From:/To: headers are part of the message content (RFC 5322), inside DATA, and can differ from the envelope.

Q: Is EHLO required, or is HELO enough?

HELO is the original RFC 821 greeting. EHLO (Extended HELO) also negotiates ESMTP extensions like SIZE, 8BITMIME, and STARTTLS, and almost every modern server sends EHLO.

A standards-first look at SMTP: the command sequence that moves mail between servers, its reply codes, and what it deliberately leaves to other standards.

Olivier Bazoud

August 9, 2026

5 min read

Moving a message from one mail server to another needs a shared, unambiguous command sequence, and a shared vocabulary for success and failure. Without that, two mail servers built by different vendors have no reliable way to talk to each other. The protocol was first standardized as RFC 821 in 1982, revised as RFC 2821 in 2001, and stands today as RFC 5321, published in 2008.

What RFC 5321 defines

RFC 5321 defines the command sequence a sending server uses to hand a message to a receiving server, the numeric reply code system that reports success, temporary failure, or permanent failure, and the envelope: the MAIL FROM and RCPT TO values SMTP itself uses for routing. The envelope is distinct from the From: and To: headers RFC 5322 defines. Routing and SPF check the envelope, not the visible headers a recipient sees.

"This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete."

How it works

EHLO opens the session. It announces the sending server's identity and negotiates which extensions both sides support, ESMTP. MAIL FROM declares the envelope sender.

RCPT TO declares one recipient, repeated once per additional recipient. DATA signals that the message content follows, terminated by a line containing only .. QUIT closes the session.

Anatomy

Command sequence:

Command	Purpose
`EHLO`	Opens the session, announces identity, negotiates ESMTP extensions
`MAIL FROM`	Declares the envelope sender
`RCPT TO`	Declares one recipient, repeated for each additional recipient
`DATA`	Signals that message content follows, ended by a line containing only `.`
`QUIT`	Closes the session

Reply code categories:

Range	Meaning
`2xx`	Success
`3xx`	Intermediate, e.g. `354` after `DATA`, waiting for message content
`4xx`	Temporary failure, the sender should retry
`5xx`	Permanent failure, retrying with the same request won't help

A full session, traced

A client delivers one message, with the server's reply code shown after each step:

220 mx.example.com ESMTP ready
EHLO mail.acme.com
250 mx.example.com Hello mail.acme.com
MAIL FROM:<hello@acme.com>
250 OK
RCPT TO:<user@example.com>
250 OK
DATA
354 Start mail input, end with <CRLF>.<CRLF>
From: hello@acme.com
To: user@example.com
Subject: Your invoice

Your invoice is attached.
.
250 OK: queued
QUIT
221 Bye

The 220 greeting and every 250 confirm success at that step. 354 is the intermediate code that tells the client to start sending the message body. The final 250 after the lone . confirms the whole message was accepted, and 221 closes the session cleanly.

Where this doesn't reach

SMTP has no sender authentication of its own. Any server can claim any MAIL FROM, which is the gap SPF, DKIM, and DMARC close. It has no encryption by default either, the gap transport security closes.

It places no message size limit on its own: that's negotiated per connection through the separate SIZE extension, RFC 1870, advertised in the EHLO response. It says nothing about spam or abuse classification either, a filtering-layer concern that sits on top of SMTP, not inside RFC 5321.

Check it yourself

Connect to a mail server directly and watch the reply codes as you type each command:

Shell

openssl s_client -starttls smtp -connect yourdomain.com:25

Type EHLO, MAIL FROM, RCPT TO, and DATA by hand, in order, and read the numeric code the server sends back after each one.

Where it fits

This page covers the transport protocol underneath everything else in this section. For what actually rides inside DATA, see message format. For the client-side entry point that hands a message off to this protocol in the first place, see message submission. For how a body carries more than plain text, see MIME. For sender authentication, see SPF, DKIM, and DMARC. For encryption in transit, see transport security. For the full standards landscape, see the reference hub.

FAQ

What's the difference between the SMTP envelope and the message headers?

The envelope (MAIL FROM, RCPT TO) is what SMTP itself uses for routing and what SPF checks. The From:/To: headers are part of the message content (RFC 5322), inside DATA, and can differ from the envelope.

Does SMTP require encryption?

No. STARTTLS (RFC 3207) is an optional extension; a session can complete entirely in plaintext unless something else, like MTA-STS, requires otherwise.

What does a 4xx reply code mean?

A temporary failure. The sending server is expected to retry later, unlike a 5xx permanent failure, which means don't retry with the same request.

Is EHLO required, or is HELO enough?

HELO is the original RFC 821 greeting. EHLO (Extended HELO) also negotiates ESMTP extensions like SIZE, 8BITMIME, and STARTTLS, and almost every modern server sends EHLO.

RFC reference

RFCs covered: RFC 5321. Superseded / updated by: obsoletes RFC 821 and RFC 2821.