RFC 5321 · October 2008 · Draft Standard

The protocol that actually delivers your email.

The official title is "Simple Mail Transfer Protocol." What it actually decides: how a mail server hands a message to the next one, the envelope, the MAIL FROM and RCPT TO, the short conversation that moves email across the internet. Not what the message says, that is RFC 5322, but how it gets there.

Status: ✓ Still current
Replaces: RFC 2821

Written by Noel Lang · IT trainer

TL;DR

RFC 5321 is SMTP, the protocol that moves email between servers. It defines the envelope (the MAIL FROM and RCPT TO commands) and the short conversation, EHLO, MAIL, RCPT, DATA, QUIT, that delivers a message. It deliberately says nothing about what the message contains; that is RFC 5322 . The envelope, not the visible From header, is what actually decides where mail goes.

The problem it solves

A message format like RFC 5322 tells you what an email looks like once written. It says nothing about how that email crosses the internet from your outbox to someone else’s inbox, possibly through several servers along the way. Something has to define the actual handoff: how one server offers a message, how the next accepts or refuses it, how failures are reported.

That is SMTP. RFC 5321 is the conversation two mail servers have to move a message one hop closer to its destination. It is deliberately simple, a handful of commands and numeric replies, and it is deliberately separate from the message itself, so the delivery mechanism and the letter can evolve independently.

The envelope and the letter

Think of physical post. You write a letter, and inside it you might begin “Dear Sam” and sign off “Jane”. Then you put it in an envelope and write an address on the outside. The postal service never reads your letter; it delivers entirely by what is written on the envelope.

Email works exactly the same way, and this is the single most important thing to understand about SMTP. RFC 5322 is the letter: the From, To, Subject and body you see in your mail client. RFC 5321 is the envelope: the MAIL FROM and RCPT TO given during the SMTP conversation. The mail servers deliver by the envelope, not the letter. The two usually match, but they do not have to, and every interesting thing about email delivery lives in that gap.

Why the gap matters

Because the envelope and the visible headers are separate, three everyday things become possible. A mailing list sets the envelope return path to itself, so bounces come back to the list and not to you, even though the From still shows the original author. BCC works because a recipient can be on the envelope (RCPT TO) without appearing in any header. And forged spam works because nothing in base SMTP stops a sender from writing any From they like, since the server only ever needed the envelope to deliver.

That last one is why an entire security stack, SPF, DKIM and DMARC, was later added on top of SMTP: to check, after the fact, whether the envelope and the From line have any right to claim each other. RFC 5321 is candid that plain SMTP offers no such guarantee.

The envelope wraps the message

SMTP delivers by the outer envelope, MAIL FROM and RCPT TO. The From and To you read are inside the message, defined by RFC 5322 , and can differ. The servers only ever act on the envelope.

Note the mismatch: the envelope return path is the mailing list, but the From says Jane. A bounce goes to the list, not to Jane. That is the envelope doing its job.

What the RFC actually says

Longer than the message-format RFCs, but the delivery core is small. The map, if you go to the source:

Section	In plain words
2 · Model	The picture: clients, servers and relays passing a message along, each hop a fresh SMTP conversation.
3 · Procedures	The heart of it: the EHLO, MAIL, RCPT, DATA, QUIT sequence, step by step, with what each side says.
3.3 · Mail transactions	How the envelope is built: MAIL FROM sets the return path, each RCPT TO adds a recipient, DATA sends the message.
4.2 · Reply codes	The numeric answers, 250 ok, 550 rejected, 421 try later, that let servers talk without prose.
7 · Security	The honest part: base SMTP has no authentication, which is why the envelope sender can be forged and why later add-ons exist.

Things people get wrong

"The From address is where mail comes from."

Not for delivery. The From header is text inside the message, written for you to read. SMTP routes and bounces by the envelope: the MAIL FROM return path and the RCPT TO recipients, set separately during the conversation. The visible From can say anything, which is the whole mechanism behind forged spam and why 's From is not a security guarantee.
"SMTP defines what an email looks like."

It does not. SMTP defines only how a message is carried between servers. What the message contains, its From, To, Subject and body, is . A useful rule: if it is a command in a conversation (MAIL FROM, RCPT TO, DATA), it is 5321; if it is a line inside the message, it is 5322.
"SMTP is secure because I use TLS."

TLS encrypts the connection between two hops, which is real but partial. Base SMTP still has no built-in way to prove the envelope sender is genuine, so anyone can claim to be anyone. That gap is why SPF, DKIM and DMARC exist as separate layers on top. RFC 5321 says as much in its own security section.

Where you'll meet RFC 5321

Every email you send starts an SMTP conversation you never see. Its traces, though, are everywhere:

You see	What it means
`550 5.1.1 User unknown`	An SMTP reply code rejecting a RCPT TO. The recipient does not exist on that server; the envelope failed, not the message.
A bounce to an address you never see in From	The bounce went to the envelope return path (MAIL FROM), which mailing lists set differently from the visible From header.
Your mail client sending on port 587	Message submission with STARTTLS. End users no longer use port 25, which is reserved for server-to-server relay and often blocked.
Spam "from" a name you trust	The visible From header is just text. SMTP's envelope sender can be anything, which is why SPF, DKIM and DMARC were bolted on to check it.
`EHLO mail.example.com` in a mail log	The opening line of an SMTP conversation, where the sending server introduces itself and asks what extensions the receiver supports.

Questions people actually ask

What is RFC 5321? +

RFC 5321 is the current specification of SMTP, the Simple Mail Transfer Protocol, which moves email from one mail server to the next. It defines the envelope (the MAIL FROM and RCPT TO commands) and the short command conversation that delivers a message. It does not define what the message contains; that is RFC 5322. RFC 5321 is about transport, not format.

What is the difference between the SMTP envelope and the message headers? +

The envelope is what SMTP uses to route and deliver mail: the MAIL FROM (return path) and RCPT TO (actual recipients) given during the SMTP conversation. The From and To headers are text inside the message, written for humans. They often differ, which is exactly how mailing lists, BCC and forged spam work: the envelope decides where mail really goes, the headers decide what you see.

What is the difference between RFC 5321 and RFC 5322? +

They are the two halves of email. RFC 5321 (SMTP) is the transport: how a message travels between servers. RFC 5322 is the format: what the message itself looks like, its headers and body. A message is written to RFC 5322 and carried by RFC 5321. Confusing the two is the most common email misunderstanding.

What are the main SMTP commands? +

The core sequence is EHLO (or HELO) to greet the server, MAIL FROM to name the return path, RCPT TO to name each recipient, DATA to send the message itself, and QUIT to end. The receiving server answers each with a numeric status code, such as 250 for success or 550 for a rejected recipient. That short exchange is the whole of a basic mail handoff.

What port does SMTP use? +

Server-to-server SMTP relay runs on port 25, the port RFC 5321 assumes. Mail programs submitting outgoing mail use port 587 (submission, usually with STARTTLS), and port 465 is implicit-TLS submission. Port 25 is increasingly blocked for end users to curb spam, which is why your mail client sends on 587, not 25.

Referenced by

Other explainers on this site that point back to this RFC:

How RFC 5321 connects

What came before

RFC 821 (1982) defined SMTP in the ARPANET era. Its command verbs, MAIL FROM and RCPT TO, survive almost unchanged in RFC 5321 today.
RFC 2821 (2001) was the previous SMTP specification, which RFC 5321 obsoletes and refines. The intermediate step between the original and today.

What it works with

Part of a guided cluster: The email RFCs, explained