What this RFC defines
RFC 5321 is the current SMTP standard. It defines the complete protocol for transferring email between servers: the TCP session lifecycle, the EHLO greeting, the MAIL FROM and RCPT TO envelope commands, the DATA transaction, and the QUIT teardown. Every mail server on the internet, whether Postfix, Exchange, or SendGrid, implements this document.
Where you see it in practice
The three-digit reply codes in your bounce messages (220, 250, 421, 450, 550, 554) are defined here. When a receiving server rejects your message with “550 5.1.1 User unknown”, that code structure traces back to RFC 5321 section 4.2. The requirement that your EHLO hostname match a valid PTR record (section 2.3.5) is why missing reverse DNS causes deliverability issues with strict MTAs.
How it connects to other RFCs
RFC 5321 supersedes RFC 2821 (2001) and RFC 821 (1982). It works alongside RFC 5322 (message format), RFC 4954 (SMTP AUTH), RFC 3207 (STARTTLS), and RFC 6409 (port 587 submission). These five documents form the core SMTP stack. Extension RFCs like RFC 6531 (internationalization) and RFC 1870 (SIZE) build on top of RFC 5321 without replacing it.
Current status
RFC 5321 is the current standard, published October 2008 and maintained by the IETF. No successor is planned. Extensions to SMTP are defined as separate RFCs that add new capabilities to RFC 5321’s base, rather than replacing the document itself.
Implementation across major MTAs
Every production mail transfer agent implements RFC 5321. Postfix, Exim, Sendmail, and Microsoft Exchange are the four dominant open-source and enterprise MTAs, and each conforms to the base protocol described in the document, with minor policy differences in areas the RFC leaves as SHOULD or MAY. Cloud services like Amazon SES, SendGrid, Mailgun, Postmark, and SparkPost also speak RFC 5321 on their outbound relays and accept it on their inbound MX endpoints. The universality of RFC 5321 conformance is why interoperability at the SMTP layer is essentially a solved problem in 2026.
Common misconceptions
Three misconceptions recur frequently. First, RFC 5321 does not mandate authentication; SMTP AUTH is defined in RFC 4954 as an extension. A vanilla RFC 5321 conversation does not require the sender to authenticate, which is why open relays existed for decades before operational best practice mandated closing them. Second, RFC 5321 does not require TLS; STARTTLS is defined in RFC 3207 as an optional extension. RFC 8314 later declared cleartext obsolete for submission, but RFC 5321 itself remains protocol-agnostic on transport security. Third, the SIZE line in an EHLO response is a hint, not a hard commitment; a receiving server can accept a message larger or smaller than the advertised limit depending on per-recipient policy.
Testing conformance
The classic conformance check is a telnet session to port 25 (or 587 for submission), where you type each command manually and verify that the responses follow the reply-code grammar. Automated conformance is typically done with tools like swaks, smtpm, or the Postfix smtp-source utility. For inbound conformance, the receiving MTA logs should show your EHLO greeting, MAIL FROM and RCPT TO exchanges, and the final DATA acceptance. Any of these steps rejecting valid input, or accepting clearly invalid input, indicates a conformance issue.
RFC 5321 (October 2008) is the current Simple Mail Transfer Protocol standard. It defines the complete server-to-server email transfer protocol: TCP session, EHLO handshake, MAIL FROM and RCPT TO envelope, DATA transaction, three-digit reply codes, and QUIT teardown. Obsoletes RFC 2821 (2001) and RFC 821 (1982). Works alongside RFC 5322 (message format), RFC 3207 (STARTTLS), RFC 4954 (SMTP AUTH), and RFC 6409 (message submission on port 587). No successor planned; extensions are separate RFCs that build on this base.
RFC 5321 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Server-to-server email transfer protocol |
| Transport | TCP, typically port 25 (server-to-server) or 587 (client submission per RFC 6409) |
| Session model | Stateful command/response with three-digit reply codes |
| Core commands | EHLO, MAIL FROM, RCPT TO, DATA, QUIT (plus RSET, NOOP, VRFY, EXPN, HELP) |
| Reply code structure | 3-digit numeric: first digit is severity class, remaining digits refine |
| Extension mechanism | EHLO response advertises supported extensions per RFC 1869 |
| Published | October 2008 (obsoletes RFC 2821, RFC 821) |
| Status | Current standard; no successor planned |
Complete SMTP command reference
RFC 5321 defines a small set of commands that flow between client (sending MTA) and server (receiving MTA). Every SMTP conversation follows the same pattern: server greeting, EHLO exchange, envelope commands, DATA, and QUIT.
| Command | Purpose | Example | Section |
|---|---|---|---|
HELO | Legacy greeting (RFC 821), rarely used today | HELO mail.example.com | 4.1.1.1 |
EHLO | Extended greeting, triggers capability advertisement | EHLO mail.example.com | 4.1.1.1 |
MAIL FROM | Envelope sender (Return-Path) | MAIL FROM:<sender@example.com> | 4.1.1.2 |
RCPT TO | Envelope recipient (one per command) | RCPT TO:<user@example.com> | 4.1.1.3 |
DATA | Begin message body transfer, ends with . on line alone | DATA | 4.1.1.4 |
RSET | Abort current transaction, keep connection | RSET | 4.1.1.5 |
VRFY | Verify address exists (often disabled for anti-harvesting) | VRFY user@example.com | 4.1.1.6 |
EXPN | Expand mailing list (usually disabled) | EXPN list@example.com | 4.1.1.7 |
HELP | Request server-side help text | HELP | 4.1.1.8 |
NOOP | No operation, keep-alive | NOOP | 4.1.1.9 |
QUIT | End session | QUIT | 4.1.1.10 |
SMTP reply code structure
Every SMTP command produces a three-digit reply code. The first digit indicates the severity class; the second digit categorizes the source; the third digit adds specificity. Modern deployments extend this with enhanced status codes per RFC 3463 (see also DSN parsing guide for practical parsing).
| First digit | Class | Meaning | Common examples |
|---|---|---|---|
| 2xx | Success | Command accepted and completed | 220 Ready, 221 Bye, 250 OK, 251 User forwarded |
| 3xx | Intermediate | Awaiting more input from client | 354 Start mail input (after DATA) |
| 4xx | Transient failure | Retry later, may succeed | 421 Service unavailable, 450 Mailbox busy, 451 Local error |
| 5xx | Permanent failure | Do not retry, address the underlying issue | 550 Mailbox unavailable, 551 User not local, 552 Storage full, 553 Bad address, 554 Transaction failed |
A complete SMTP dialogue
Common ESMTP extensions
The EHLO response advertises server capabilities as extensions per RFC 1869. Modern SMTP servers implement dozens of extensions; the essentials are listed below.
| Extension | Advertised as | Defined in | Purpose |
|---|---|---|---|
| SIZE | SIZE 52428800 | RFC 1870 | Advertise maximum message size in bytes |
| 8BITMIME | 8BITMIME | RFC 6152 | Accept 8-bit MIME content without encoding |
| STARTTLS | STARTTLS | RFC 3207 | Upgrade cleartext connection to TLS |
| AUTH | AUTH LOGIN PLAIN | RFC 4954 | Client authentication (list of mechanisms) |
| PIPELINING | PIPELINING | RFC 2920 | Batch multiple commands without waiting for reply |
| ENHANCEDSTATUSCODES | ENHANCEDSTATUSCODES | RFC 2034 | Return X.Y.Z codes alongside 3-digit codes |
| DSN | DSN | RFC 3464 | Support delivery status notifications |
| CHUNKING | CHUNKING | RFC 3030 | Transfer message body in binary chunks (BDAT) |
| SMTPUTF8 | SMTPUTF8 | RFC 6531 | Support internationalized mailbox names |
| BINARYMIME | BINARYMIME | RFC 3030 | Accept binary MIME parts (requires CHUNKING) |
Common SMTP implementation pitfalls
MAIL FROM:<"Sender Team" <team@example.com>> is a syntax error. Use only the bare address: MAIL FROM:<team@example.com>. Display names go in the From header inside DATA.Migration from RFC 2821 to RFC 5321
| Aspect | RFC 2821 (2001) | RFC 5321 (2008) | Impact if code targets 2821 |
|---|---|---|---|
| Core protocol | Complete SMTP | Identical semantics with clarifications | None |
| Reply code registry | Enumerated in RFC | Delegated to IANA | Update reference; no code change |
| Address literal syntax | IPv4 only in bracket form | Adds IPv6 with IPv6: tag | Update address parser for IPv6 |
| Errata integration | Separate errata | Errata integrated in main text | None |
| Internationalization | ASCII only | ASCII base with pointer to RFC 6531 for SMTPUTF8 | None (extension is separate RFC) |
| SIZE recommendations | Section 3.1.1 | Clarified in section 4.5.3.1.5 | Review SIZE handling logic |
Related standards and further reading
- RFC 5322: Internet Message Format (headers and body of the actual message)
- RFC 6409: Message Submission (port 587 client-to-server distinction)
- RFC 3207: STARTTLS extension for SMTP over TLS
- RFC 4954: SMTP AUTH extension
- RFC 8314: Cleartext considered obsolete for submission/access
- RFC 6152: 8-bit MIME transport
- RFC 1869: The EHLO extension mechanism
- DSN Parsing Guide: reading bounce reports produced by SMTP failures
- Authentication-Results Header: interpreting SPF, DKIM, DMARC verdicts
- Hard Bounce vs Soft Bounce: 4xx vs 5xx handling patterns
- PTR and rDNS Records: FCrDNS setup for EHLO compliance
- Received Headers and Email Trace Chain: reading the Received chain SMTP produces
- Postfix Guide: configuring a common RFC 5321 implementation
Frequently asked questions
What is the difference between HELO and EHLO?
HELO is the legacy greeting from RFC 821 (1982). EHLO is the extended greeting introduced in RFC 1869 and codified in RFC 5321. When a client sends EHLO, the server responds with a multi-line reply listing all supported extensions (SIZE, STARTTLS, AUTH, PIPELINING, and others). HELO produces only a single greeting line without capability information. Modern clients always send EHLO first; if the server responds with a syntax error, they fall back to HELO. In 2026, every production SMTP server supports EHLO; HELO is retained purely for backward compatibility.
Does RFC 5321 require authentication?
No. RFC 5321 defines the base SMTP protocol; authentication is a separate extension in RFC 4954. A vanilla RFC 5321 conversation does not require the client to authenticate. This is why open relays existed for decades; the protocol did not mandate closure. Modern operational best practice requires AUTH for message submission (per RFC 6409 and RFC 8314) but server-to-server relay per RFC 5321 remains authentication-optional.
Does RFC 5321 require TLS?
No. RFC 5321 is transport-security-agnostic; STARTTLS is defined as an optional extension in RFC 3207. RFC 8314 (2018) declared cleartext obsolete for message submission and access, but did not amend RFC 5321 for server-to-server relay. Practical reality in 2026: cleartext SMTP relay still occurs when both peers lack STARTTLS support, though this is uncommon at reputable providers. TLS-required policies (MTA-STS, DANE) sit on top of RFC 5321 as separate mechanisms.
What is the difference between MAIL FROM and the From header?
MAIL FROM is the envelope sender, a protocol-level attribute of the SMTP conversation. It becomes the Return-Path header of the delivered message and is used for bounce routing. The From header is a message-level attribute inside DATA, defined by RFC 5322, that names the visible sender to the recipient. The two can differ (a common pattern with newsletter platforms where MAIL FROM points at a bounce-processing subdomain but From displays the company brand). Anti-spoofing mechanisms like DMARC require alignment between these two identities per configured policy.
Why do some servers disable VRFY and EXPN?
Both commands allow a client to query which addresses exist on a server without sending mail. Spammers used VRFY to harvest valid addresses from target domains at scale. Modern operational best practice disables both commands on internet-facing MTAs to prevent address harvesting. RFC 5321 section 3.5.3 explicitly permits this: implementations MAY implement VRFY as a no-op returning 252 (cannot verify) to avoid disclosing address existence. Most production Postfix and Exchange deployments disable VRFY and EXPN entirely.
What happens when a message hits the SIZE limit?
If the client sent the SIZE parameter with MAIL FROM and the value exceeds the server-advertised limit, the server rejects at MAIL FROM with a 552 or 452 code before any data transfer. If the client did not declare SIZE, the server can still reject after DATA if the actual message exceeds its limit. Either path produces a bounce back to the sender. Some servers accept messages slightly over the advertised limit as a courtesy; others enforce strictly. The advertised SIZE is a hint, not a hard commitment, per RFC 5321 section 3.7.5.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
