What this RFC defined
RFC 822 defined the standard for ARPA internet text message format in 1982, establishing the fundamental structure of email: headers separated from the body by a blank line, the From:, To:, Subject:, and Date: header fields, and the ASCII character set for message content. It is the original foundation of all email format standards that followed.
Where you would have seen it in practice
Every email you have ever sent traces its header structure back to RFC 822. The From:, To:, Subject:, Date: headers and the blank line separating headers from body were defined here in 1982. Understanding RFC 822 provides historical context for email parsing code and explains why email has the constraints and quirks it does, many of which survive unchanged into RFC 5322 forty years later.
How it connects to other RFCs
RFC 822 obsoletes RFC 733 (an earlier message format from 1977). It was obsoleted by RFC 2822 in 2001, which was subsequently obsoleted by RFC 5322 in 2008. The email format lineage: RFC 733 to RFC 822 to RFC 2822 to RFC 5322. Core concepts from RFC 822 survive in RFC 5322 intact after more than four decades.
Current status
RFC 822 was obsoleted by RFC 2822 in April 2001. For any implementation work, reference RFC 5322. RFC 822 is historically significant as the document that defined the fundamental structure of email in 1982 and is worth reading for anyone building email infrastructure to understand where the format came from.
The header structure it defined
RFC 822 introduced the two-part message model that still underpins every email: an ordered list of header fields, a blank line, and then the message body. The document specified the syntax for the core fields (From, To, Cc, Bcc, Reply-To, Message-ID, In-Reply-To, References, Subject, Date, Sender) and left the door open for extensions through the X-prefix convention. The permissive date syntax and comment nesting rules from RFC 822 caused decades of parser bugs; RFC 2822 later tightened these rules significantly, and RFC 5322 tightened them further.
Why parsers still care about it
Any email parser that must accept legacy messages (archived mail, mbox files from the 1990s, MIME encapsulation of forwarded content) needs to handle RFC 822 semantics. This is why libraries like the Python email.parser module, the Ruby Mail gem, and Java JavaMail all default to lenient parsing and only enforce the stricter RFC 5322 rules when explicitly requested. If your application processes historical email archives or accepts inbound mail from any source, you will encounter RFC 822 quirks: obsolete date formats, folded headers with leading spaces, unquoted display names containing special characters, and the like.
Its lasting cultural impact
RFC 822 gave the world the notation user@host for email addresses. Before RFC 822, ARPANET mail addresses used syntaxes like “user at host” or bang-path routing through UUCP. The @ sign as address separator, the concept of a domain-part and local-part, and the idea that an address is stable regardless of how mail is routed all trace to this document. When you write your email address on a business card, you are using a convention Dave Crocker codified in 1982 in a 47-page document.
RFC 822 (August 1982), authored by Dave Crocker, was the original Internet Message Format specification. Established the header/body structure, From/To/Subject/Date/Message-ID headers, and the addr-spec syntax for email addresses (local-part@domain) that has been universal for over 40 years. Obsoleted by RFC 2822 (2001) and then RFC 5322 (2008). Reference RFC 5322 for current message format; RFC 822 is historical foundation.
RFC 822 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Original standard for Internet email message format |
| Author | Dave Crocker |
| Established headers | From, To, Cc, Bcc, Subject, Date, Message-ID, References, In-Reply-To, Received, Reply-To |
| Address syntax | local-part@domain, still standard today |
| Published | August 1982 (obsoleted RFC 733) |
| Superseded by | RFC 2822 (2001), then RFC 5322 (2008) |
| Status | Historical foundation; core structure still in use |
What RFC 822 established that still lives today
| Element | Introduced by RFC 822 | Status in 2026 |
|---|---|---|
| Header/body separation via blank line | Yes | Unchanged in RFC 5322 |
| Case-insensitive header names | Yes | Unchanged |
| Header folding (CRLF + whitespace) | Yes | Unchanged |
| Comments in headers via parentheses | Yes | Unchanged |
| Quoted strings via double quotes | Yes | Unchanged |
| local-part@domain address format | Yes | Universal |
| Display-name and angle-bracket address syntax | Yes | Unchanged (e.g., Alice <alice@example.com>) |
Message-ID format (<unique@domain>) | Yes | Unchanged |
| Received trace header | Yes | Expanded but same purpose |
| Multiple recipients per header | Yes | Unchanged |
What has changed since RFC 822
| Aspect | RFC 822 (1982) | RFC 5322 (2008) |
|---|---|---|
| Character set | ASCII only in headers | Extended by RFC 2047 and RFC 6532 for non-ASCII |
| Multipart content | Not supported | Added by MIME (RFC 2045+) |
| Address routing | Included source routing syntax (@a,@b:user@c) | Deprecated (obsolete syntax) in RFC 2822 |
| Date format | Various tolerated forms | Tightened; older forms marked obsolete |
| Authentication headers | Not defined | SPF, DKIM, DMARC results, ARC (RFC 5321, 6376, 8601, 8617) |
Common mistakes when RFC 822 is the reference
@a.example.com,@b.example.com:user@c.example.com. This was deprecated by RFC 2822 and marked obsolete in RFC 5322. Modern parsers should not accept source routing (security risk: attackers can construct messages routed through unexpected paths). Reject or strip source-route forms.Wed, 15 Jul 2026 09:15:22 +0000.Related standards and further reading
- RFC 5322 Guide: current message format
- Message-ID Header: identifier introduced by RFC 822
- Received Headers and Email Trace Chain: Received header lineage
Frequently asked questions
Is RFC 822 still relevant today?
Only for historical context. RFC 822 was obsoleted by RFC 2822 in 2001, then by RFC 5322 in 2008. Reference RFC 5322 for current message format. RFC 822 remains valuable to understand the origins of email: the header structure, address syntax, and other fundamentals that Dave Crocker established in 1982 are still the basis for every message sent today.
Why is the “message/rfc822” MIME type named after this RFC?
Historical: when MIME was designed in 1996, RFC 822 was still the current message format standard. The message/rfc822 Content-Type indicates “the content of this part is an RFC 822 formatted message.” When RFC 822 was obsoleted by RFC 2822 and then RFC 5322, the MIME type name was not changed to preserve backward compatibility. Every DSN, MDN, and ARF report today uses message/rfc822 or text/rfc822-headers despite the underlying format being defined by RFC 5322.
What was source routing in RFC 822?
A syntax allowing senders to specify the path a message should take through intermediate hosts. Example: @a.example.com,@b.example.com:user@c.example.com meant “route through a.example.com and b.example.com to reach user@c.example.com”. Deprecated because it enabled abuse (open relay exploitation, unexpected message paths) and became irrelevant with modern DNS-based routing. Marked obsolete in RFC 2822 and RFC 5322.
Did RFC 822 support attachments?
No. RFC 822 defined ASCII text-only messages with structured headers. Attachments and non-text content came later via MIME (RFC 2045 through 2049, 1996). Before MIME, sending binary content over email required manual encoding (uuencode, later base64) and hoping the receiver knew how to decode. MIME formalized this with Content-Type and Content-Transfer-Encoding headers.
Who was Dave Crocker?
Dave Crocker was an early Internet email pioneer who authored RFC 733 (1977) and RFC 822 (1982), establishing the message format standard used to this day. He remained active in Internet mail standardization for decades, contributing to DKIM (RFC 6376) and other authentication work. Every time you write your email address on a business card, you are using conventions Crocker codified.
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.
