RFC 5322 Explained: The Internet Message Format Standard

RFC 5322 is the IETF standard that defines the Internet Message Format: the exact syntax of an email message once it has been composed. It specifies the header fields at the top (From, To, Subject, Date, Message-ID), the blank line beneath them, and the plain-text body. Published in October 2008, it replaced RFC 2822 and, before that, RFC 822, and it is the reference that says which addresses are syntactically legal and how the headers that email authentication inspects are built.

Every email client and server agrees on this one specification, which is why headers follow the same shape no matter which client sent the message. For anyone working on email validation or deliverability, RFC 5322 is the rulebook that decides whether an address is well-formed and whether the From and Return-Path fields that SPF, DKIM, and DMARC read are correctly built.

What is RFC 5322?

RFC 5322, titled "Internet Message Format," is the IETF specification that describes the syntax of a text email message: the ordered set of header fields, the blank line that separates them from the body, and the body content. It defines the message itself, not how that message travels across the network.

The specification is written using a notation called Augmented Backus-Naur Form (ABNF), which gives an unambiguous grammar for every allowed construct. Two large parts of the document handle this: a lexical analysis of messages (how raw characters group into tokens, folding whitespace, and comments) and the syntax rules that define each header field. You can read the canonical text at the RFC Editor.

What RFC 5322 defines

RFC 5322 defines a message as a stream of US-ASCII characters split into two parts by a single empty line: everything above the empty line is the header section, and everything below is the body. It specifies the header fields, the address syntax, the required message structure, the lexical rules, and a separate set of obsolete constructs kept only for parsing legacy mail.

The specification covers several distinct areas:

• Header fields, each a field name, a colon, and a field body. RFC 5322 defines fields such as From, Sender, Reply-To, To, Cc, Bcc, Message-ID, In-Reply-To, References, Subject, Date, and the trace fields like Received and Return-Path.
• Address syntax, the rules for what a valid mailbox looks like. An address is a local part, an at sign, and a domain, with optional display names and grouped address lists.
• Message structure, the requirement that the header section precede the body, that certain fields (Date and From) are mandatory, and that most fields appear at most once.
• Lexical rules, including folding of long header lines across multiple physical lines and the handling of comments and whitespace.
• Obsolete syntax, a separate section that documents older constructs so that software can still parse legacy messages while never generating them.

Because attachments and non-ASCII content are not part of this core format, they are handled by the separate MIME specifications, which build on top of RFC 5322 rather than replacing it. In practice, a modern message is often described as four layers working together: the transport envelope, the RFC 5322 header fields, the message body, and MIME attachments.

RFC 5322 vs RFC 5321: two standards, two jobs

RFC 5321 and RFC 5322 are companion standards that cover different stages of an email's life. RFC 5321 defines SMTP, the protocol that moves a message between servers, and it governs the envelope used during delivery. RFC 5322 defines the content, the message document carried inside that envelope. In short: RFC 5321 is transport, RFC 5322 is the message.

A useful analogy is postal mail. The envelope with the delivery address is SMTP (RFC 5321); the letter folded inside, with its own "Dear" line and signature, is the message (RFC 5322). You can read the SMTP specification at the RFC Editor for the transport side.

Aspect	RFC 5321 (SMTP)	RFC 5322 (Message)
Governs	Transport / delivery	Message content
Layer	Envelope	Header fields and body
Key address	MAIL FROM (Return-Path)	From header
Read by	Sending and receiving servers	Mail clients and readers

5321.From vs 5322.From in email headers

The 5321.From is the envelope sender (also called MAIL FROM or Return-Path), the address the sending server declares during the SMTP conversation. The 5322.From is the From header the recipient actually sees inside the message. The two do not have to match, and they legitimately differ in cases like mailing lists and forwarding.

That gap is why authentication checks specify which "from" they evaluate: SPF validates the 5321.From (the envelope sender), while DMARC anchors on the 5322.From (the header the reader sees). Reading an authentication result correctly depends on knowing which of the two addresses a given check inspects.

From RFC 822 to RFC 2822 to RFC 5322

RFC 5322 is the current member of a single family of standards that began with RFC 822 in 1982. RFC 822 set the header-and-body shape email still uses and itself refined earlier work in RFC 733. RFC 2822 revised and clarified those rules in 2001, and RFC 5322 revised RFC 2822 in 2008. Each revision kept the format recognizable while tightening the grammar and marking older constructs as obsolete.

Standard	Year	Role
RFC 733	1977	Early message format
RFC 822	1982	Established header/body format
RFC 2822	2001	Revised and clarified RFC 822
RFC 5322	2008	Current standard, revised RFC 2822

This history is why you still see email described as "RFC 822 format" in older documentation. It is the same family of rules; RFC 5322 is simply the current member. The revisions did not reinvent email, they clarified ambiguities and formally separated the syntax that current software should produce from the obsolete syntax it must still be able to read.

How RFC 5322 supports SPF, DKIM, and DMARC

Modern email authentication is built directly on the header fields RFC 5322 defines. SPF, DKIM, and DMARC each reference specific parts of the message format: SPF checks the envelope 5321.From, DKIM signs selected RFC 5322 headers and the body, and DMARC requires alignment with the visible 5322.From domain. Without a common definition of those fields, these checks would have nothing consistent to evaluate.

The standards for SPF, DKIM, and DMARC map onto the message format like this:

• SPF checks the 5321.From (the envelope MAIL FROM) against a domain's published sending policy, so it operates on the RFC 5321 side rather than the visible header.
• DKIM attaches a cryptographic signature over selected RFC 5322 header fields and the body, letting a receiver confirm those headers were not altered in transit.
• DMARC ties the results together by requiring that the authenticated identity align with the 5322.From domain the recipient sees, which is the header RFC 5322 defines.

Return-Path, From, and the other trace and origination fields that these systems inspect are all specified in RFC 5322.

Why RFC 5322 matters for validation and deliverability

RFC 5322 is the rulebook that decides whether an email address is syntactically legal before you ever attempt delivery. A validator that follows the specification can reject malformed local parts, illegal characters, and broken domain syntax at the door. That syntax check is the first and cheapest layer of any effort to verify whether an address is valid, well before a mailbox lookup happens.

Deliverability depends on the same foundation. Mailbox providers expect well-formed headers, and messages that violate the format can be filtered or rejected outright, adding to your bounce rate. Correct From and Return-Path fields also let authentication pass, which providers weigh heavily when deciding inbox placement. Syntax conformance alone will not fix a damaged sender reputation or missing authentication, but broken syntax is a reliable way to make deliverability worse.

Running your list through a verifier before a send catches both problems at once: it removes addresses that fail RFC 5322 syntax and flags the invalid mailboxes that would hard bounce. Check your list with BounceCheck before your next campaign to clear the invalid addresses that hurt your sender reputation.

FAQs

What is the difference between RFC 5321 and RFC 5322?

RFC 5321 defines SMTP, the protocol servers use to transport a message, and it governs the envelope. RFC 5322 defines the message itself: the header fields and body carried inside that envelope. They are companion standards covering delivery versus content.

What do 5321.from and 5322.from mean in email headers?

The 5321.From is the envelope sender (MAIL FROM or Return-Path) declared during the SMTP conversation. The 5322.From is the From header the recipient sees inside the message. They can legitimately differ, for example with mailing lists or forwarding.

How does RFC 5322 relate to SPF, DKIM, and DMARC?

Those authentication systems operate on the addresses and header fields RFC 5322 defines. SPF checks the envelope 5321.From, DKIM signs selected RFC 5322 headers and the body, and DMARC requires alignment with the visible 5322.From domain.

What is the relationship between RFC 822, RFC 2822, and RFC 5322?

They are successive versions of the same Internet Message Format. RFC 822 (1982) established the header-and-body shape, RFC 2822 (2001) revised it, and RFC 5322 (2008) is the current revision. Each kept the format recognizable while tightening the grammar.

When was RFC 5322 published and what did it replace?

RFC 5322 was published by the IETF in October 2008. It replaced RFC 2822 (2001), which had itself revised RFC 822 (1982). RFC 5322 is the current version of the Internet Message Format and the one modern email software should follow.