What this RFC defined
RFC 2822 updated the internet message format standard, modernising the original RFC 822 from 1982. It clarified the syntax for header fields, updated the date format requirements, introduced stricter rules for message structure, and removed obsolete features that had accumulated in 19 years of deployed practice.
Where you would have seen it in practice
Mail systems deployed between 2001 and 2008 referenced RFC 2822 as the message format standard. The From:, To:, Subject:, Date: headers that appear at the top of every email message follow RFC 2822 syntax, which is largely identical to RFC 5322. Old documentation or parsing code that references RFC 2822 is fully compatible with RFC 5322 since the format changes were clarifications rather than breaks.
How it connects to other RFCs
RFC 2822 obsoletes RFC 822 and is itself obsoleted by RFC 5322 in 2008. The three RFCs form the linear evolution of the email message format standard. RFC 2822 introduced CRLF line endings as a strict requirement and tightened the date syntax from the permissive rules in RFC 822.
Current status
RFC 2822 was obsoleted by RFC 5322 in October 2008. New implementations should reference RFC 5322. Email messages generated under RFC 2822 rules are valid RFC 5322 messages since the format changes were clarifications rather than breaking changes to the wire format.
The 2001 message format update
RFC 2822, authored by Pete Resnick and published in April 2001, tightened the RFC 822 message format after nineteen years of accumulated ambiguity. The most visible change was mandating CRLF line endings as the sole line separator, removing the LF-only permissiveness that had spread from Unix systems. The date syntax was tightened significantly: the four-digit year became mandatory (RFC 822 allowed two-digit years), and the obsolete zone names like EDT or GMT were moved to a separate obsolete-syntax section, still parseable but discouraged for new mail.
The obsolete-syntax appendix
RFC 2822 pioneered a formal split between current syntax and obsolete syntax. Section 4 documents all the grammar productions that must be accepted for backward compatibility with RFC 822 but should not be generated by new implementations. This split gave parser authors a clear conformance target: reject nothing legal from either era, but generate only current-syntax output. Every major email library since 2001 has followed this dual-mode design, and it is why you can still parse a 1990s archive without special legacy code paths.
Superseded by RFC 5322
RFC 2822 was itself obsoleted by RFC 5322 in October 2008. The changes were incremental: additional clarifications, further tightening of the obsolete syntax boundaries, integration of internationalization preparations. In practice, if your code targets RFC 2822, it will interoperate correctly with any RFC 5322 system. The main reason to reference RFC 5322 in new work is that it is the current standard and contains the most accurate errata. Both documents describe the same underlying message format that has stayed stable since 1982.
RFC 2822 (April 2001), authored by Pete Resnick, was the second revision of the Internet Message Format. Obsoleted the original RFC 822 from 1982, folding in nearly 20 years of operational experience. Formalized ABNF (Augmented Backus-Naur Form) syntax, deprecated obsolete constructs (source routing), and cleaned up ambiguities. Obsoleted by RFC 5322 in October 2008. Reference RFC 5322 for current message format; RFC 2822 is historical bridge document.
RFC 2822 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Second revision of Internet Message Format |
| Author | Pete Resnick |
| Predecessor | RFC 822 (1982) |
| Successor | RFC 5322 (2008) |
| Published | April 2001 |
| Key innovation | Formal ABNF grammar; distinction between obsolete syntax (to parse but not emit) and current syntax |
Changes from RFC 822 to RFC 2822
| Aspect | RFC 822 (1982) | RFC 2822 (2001) |
|---|---|---|
| Grammar formalism | Prose descriptions with informal syntax | Full ABNF grammar (RFC 5234) |
| Source routing | Standard syntax | Marked obsolete; parse only, do not emit |
| Date format | Multiple tolerated forms | Canonical form specified; obsolete forms tolerated on parse |
| Line length | Recommended under 998 characters | Required under 998; recommended under 78 |
| Comment handling | Loose | Explicit nesting rules |
| Address syntax | Various obsolete forms | Current and obsolete forms explicitly separated |
| Errata | Various accumulated | Integrated |
Changes from RFC 2822 to RFC 5322
| Aspect | RFC 2822 (2001) | RFC 5322 (2008) |
|---|---|---|
| Core message format | Same | Same (message format has been stable since 1982) |
| Errata integration | Not yet | Yes |
| Obsolete syntax handling | Well-defined | Same, with additional clarifications |
| Internationalization awareness | Limited | Explicit acknowledgment of RFC 6532 for UTF-8 headers |
Common mistakes when RFC 2822 is the reference
@a,@b:user@c) as obsolete. RFC 5322 continues this. Generators must not emit source routing; parsers should reject or strip it for security.Related standards and further reading
- RFC 5322 Guide: current standard reference
- Message-ID Header: identifier from RFC 822 lineage
Frequently asked questions
Is RFC 2822 still relevant?
Only for historical context. Reference RFC 5322 for current message format; RFC 2822 was superseded in 2008. The core structure has not changed materially since RFC 822 in 1982; the revisions have refined syntax, integrated errata, and formally distinguished current vs obsolete forms.
What was the main improvement RFC 2822 brought over RFC 822?
Formal ABNF grammar. RFC 822 used prose descriptions with informal syntax that led to implementer disagreements. RFC 2822 provided complete ABNF (per RFC 5234) making the grammar machine-parseable and unambiguous. This let parser implementations align on the same specification. Also marked obsolete syntax explicitly for the first time, letting generators produce clean output while parsers accepted legacy input.
Do modern messages comply with RFC 2822 or RFC 5322?
Both. The core format has not changed between them; a valid RFC 5322 message is also a valid RFC 2822 message (with minor clarification differences). New implementations should target RFC 5322 for the most current specification and errata; existing implementations targeting RFC 2822 remain interoperable.
Why was source routing deprecated?
Security and irrelevance. Source routing let senders specify intermediate hops, which enabled open relay abuse (attacker constructs a message routed through victim’s server to bypass restrictions) and unexpected delivery paths. Meanwhile, modern DNS-based routing (MX records) makes source routing operationally unnecessary. RFC 2822 marked it obsolete; RFC 5322 continues the deprecation. Parsers should reject or strip source-route forms.
Are there specific errata that RFC 5322 fixes vs RFC 2822?
Various small ambiguities around header folding, comment nesting, date parsing edge cases, and address group syntax. Most are subtle and rarely encountered. The key difference is that RFC 5322 folds in errata as clarifications; RFC 2822 leaves them as separate errata documents. For most implementers, RFC 5322 is a cleaner reference document even though the semantic changes are minor.
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.
