What this RFC defined
RFC 2821 was the major SMTP revision that updated the original RFC 821 from 1982. It formalised the distinction between port 25 (MTA-to-MTA relay) and port 587 (mail submission), clarified relay rules to address the open relay spam problem, deprecated obsolete commands (SEND, SOML, SAML), and documented nineteen years of deployed SMTP practice in a single authoritative document.
Where you would have seen it in practice
Mail servers configured between 2001 and 2008 referenced RFC 2821 as the SMTP standard. The EHLO, MAIL FROM, RCPT TO, DATA command sequence that all SMTP transactions follow was documented in RFC 2821 essentially as it exists today. RFC 2821’s clarification of relay restrictions helped close the open relay abuse that had enabled mass spam distribution in the late 1990s.
How it connects to other RFCs
RFC 2821 obsoletes RFC 821 and is itself obsoleted by RFC 5321 in 2008. The evolution chain is RFC 772 to RFC 821 to RFC 2821 to RFC 5321 (current). RFC 2821 implementations are considered RFC 5321-compliant since no breaking changes were made to the command syntax or the three-digit reply code structure.
Current status
RFC 2821 was obsoleted by RFC 5321 in October 2008. New SMTP implementations should reference RFC 5321. Existing configurations and code that reference RFC 2821 continue to function correctly since RFC 5321 is backward-compatible with RFC 2821’s command set and requirements.
The 2001 refresh
RFC 2821 was John Klensin 2001 rewrite of RFC 821. The nineteen-year gap had accumulated significant errata, undocumented practice, and extension activity that needed formal integration. RFC 2821 incorporated ESMTP (originally defined in RFC 1869) into the base standard, clarified reply code semantics, introduced the SIZE extension normatively, and tightened the wording around edge cases like empty MAIL FROM values used for bounce messages. It also added guidance on relay behavior, spam mitigation, and security considerations that were absent from the original RFC 821.
Notable changes from RFC 821
The most consequential change was the shift from HELO to EHLO as the recommended greeting, formalizing what had already been near-universal practice for a decade. RFC 2821 also removed the SEND, SOML, and SAML commands, which no MTA had implemented in years. The VRFY and EXPN commands were retained but marked as security-sensitive, since they can leak recipient information. Extended reply codes (defined in RFC 3463) were referenced, giving bounce messages more granular error semantics than the three-digit code alone.
Why RFC 5321 replaced it
RFC 2821 was replaced by RFC 5321 in October 2008. The seven-year gap between the two documents accumulated further clarifications, particularly around internationalization preparations and TLS handling. RFC 5321 did not change core protocol behavior; it clarified ambiguities and integrated errata. If you are looking at code that references RFC 2821, it is functionally correct for basic SMTP, but any new implementation work should target RFC 5321. Old code citing RFC 2821 is not broken; it is merely referencing an older revision of the same protocol.
RFC 2821 (April 2001), authored by John Klensin, was the second-generation SMTP specification. Obsoleted RFC 821 (1982) and merged in RFC 1869 (ESMTP extensions). Established the SMTP framework used for the following decade. Obsoleted by RFC 5321 in October 2008. Reference RFC 5321 for current SMTP; RFC 2821 is a historical bridge document that introduced most of the modern semantics.
RFC 2821 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Second-generation SMTP specification |
| Author | John Klensin |
| Predecessor | RFC 821 (1982), RFC 1869 (1995 extensions) |
| Successor | RFC 5321 (2008) |
| Published | April 2001 |
| Status | Obsolete; historical |
Changes from RFC 821 to RFC 2821
| Aspect | RFC 821 (1982) | RFC 2821 (2001) |
|---|---|---|
| EHLO extension mechanism | Not defined | Folded in from RFC 1869 |
| Source routing | Standard syntax | Marked obsolete (parse only) |
| Reply codes | Basic set | Extended with enhanced status codes reference (RFC 2034) |
| Errata | Various accumulated | Integrated |
| Line length limits | Implicit | Explicit (998 chars for command lines) |
| MX record handling | Introduced separately in RFC 974 | Fully integrated |
Changes from RFC 2821 to RFC 5321
| Aspect | RFC 2821 (2001) | RFC 5321 (2008) |
|---|---|---|
| Core protocol semantics | Same as RFC 5321 | Same as RFC 2821 |
| Errata integration | Not yet | Integrated |
| Internationalization awareness | Limited | Acknowledges SMTPUTF8 direction (RFC 6531 came 2012) |
| Modern authentication references | SPF just standardized (RFC 4408, 2006, post-2821) | Full acknowledgment of authentication ecosystem |
Common mistakes when RFC 2821 is the reference
@a,@b:user@c) as obsolete. Generators must not emit; parsers should reject or strip for security. Source routing enabled open relay abuse historically.Related standards and further reading
- RFC 5321 Guide: current SMTP reference
- Email Protocols and Ports Guide: SMTP alongside sibling protocols
Frequently asked questions
Is RFC 2821 still relevant?
Only for historical context. RFC 2821 was superseded by RFC 5321 in October 2008. Reference RFC 5321 for current SMTP. Existing code and documentation targeting RFC 2821 remains largely valid because the core protocol has not changed materially; the revision folded in errata and refined language.
What was the main improvement RFC 2821 brought over RFC 821?
Integration of ESMTP extensions and MX record processing into the base standard. RFC 821 was a small document; ESMTP came separately via RFC 1869 (1995); MX record handling came via RFC 974 (1986). RFC 2821 folded these into a single comprehensive document, making SMTP easier to implement from a single reference. Also formalized source routing as obsolete and cleaned up various ambiguities.
Do modern SMTP servers implement RFC 2821 or RFC 5321?
RFC 5321. Postfix, Exim, Sendmail, Microsoft Exchange, and cloud services (SendGrid, Amazon SES, Mailgun) all reference RFC 5321. Existing implementations targeting RFC 2821 are functionally interoperable; there is no wire-format break between the two revisions.
Why were source routes deprecated in RFC 2821?
Security. Source routing let attackers construct messages that transited unexpected paths through servers, enabling open relay exploitation. It was also operationally unnecessary once MX record-based routing became universal. RFC 2821 marked source routing as obsolete; RFC 5321 continued this. Parsers should reject or strip source-route paths.
What is the relationship between RFC 2821 and RFC 2822?
Companion documents published simultaneously in April 2001. RFC 2821 defines the SMTP transport protocol (how mail moves between servers). RFC 2822 defines the message format (what mail looks like on the wire). Both were superseded in 2008: RFC 2821 by RFC 5321, RFC 2822 by RFC 5322. The paired numbering (2821/2822, 5321/5322) reflects their companion status.
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.
