Internet Message Format: what RFC 5322 actually defines
A standards-first look at the Internet Message Format: the header syntax and header/body structure every email message follows, regardless of transport.
SMTP moves bytes from one server to another. It says nothing about what's inside its DATA command. Without a shared header syntax, no mail client or server could reliably parse a From address, a Subject line, or a message's threading relationship to another. The format was originally RFC 822 in 1982, revised as RFC 2822 in 2001, and stands today as RFC 5322, published in 2008.
What RFC 5322 defines
RFC 5322 defines the syntax of header fields, name: value, one per line, with folding rules for long lines. It defines the header/body split: a blank line separates them. And it defines the semantics of the fields most software actually relies on: From, Date, To, Subject, Message-ID, In-Reply-To, and References.
"This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs."
How it works
A parser reads header lines until the first blank line. Everything after that blank line is the body, which RFC 5322 treats as opaque. MIME, not this RFC, governs structured bodies.
A header line longer than 78 characters, recommended, not required, is folded: continued on the next line with leading whitespace. A conforming parser un-folds it back into one logical line before reading the value.
Anatomy
Header fields:
| Field | Required |
|---|---|
From | Yes |
Date | Yes |
To | No, but near-universal |
Subject | No |
Message-ID | No, but widely relied on for threading and deduplication |
In-Reply-To / References | No, used for threading |
Message-ID format: <local-part@domain>, required to be globally unique. Folding: a line over 78 characters continues on the next line with a leading space or tab.
Worked example
A raw header block with a folded Subject line, a Message-ID, and an RFC 5322 date-time value:
Date: Sun, 09 Aug 2026 17:00:00 +0200From: hello@acme.comTo: user@example.comSubject: Your Q3 invoice is ready, along with a summary of thisquarter's usage and billing detailsMessage-ID: <a1b2c3@acme.com>
The Subject line folds onto a second line, marked by the leading space before "quarter's." The Date header's exact syntax, day name, two-digit day, three-letter month, four-digit year, time, and numeric timezone offset, is a common source of malformed headers when generated by hand instead of a library.
Where this doesn't reach
RFC 5322 says nothing about non-text or multi-part bodies. That's MIME's job. Header values are 7-bit US-ASCII unless MIME-encoded via RFC 2047's encoded-word syntax, also covered on the MIME page, not here.
It places no message size limit. And it authenticates nothing: a From header can claim any address it wants, syntactically valid or not. Verifying who's actually allowed to use that address is the gap SPF, DKIM, and DMARC close.
Check it yourself
View the raw source of any email you've received. In Gmail, open the message and select "Show original." Look at the exact header casing, order, and folding underneath the rendered view your mail client normally shows you.
Where it fits
This page covers what rides inside the DATA command SMTP transports. For how a body carries more than plain text, structured content this format leaves opaque, see MIME. For verifying who's allowed to use a given From address, see SPF, DKIM, and DMARC. For the full standards landscape, see the reference hub.
FAQ
Is Message-ID required?
Not strictly, RFC 5322 marks it optional, but nearly every mail system relies on it for threading and deduplication, so treat it as required in practice.
Can the From header contain any address?
Syntactically, yes. RFC 5322 defines the format, not who's allowed to use it. Verifying the sender is authorized is what SPF, DKIM, and DMARC exist for.
What happens to a header line over 78 characters?
It gets folded: continued on the next line with a leading space or tab. A parser is expected to un-fold it back into one logical line before reading the value.
Does this RFC define attachments or HTML email?
No. It defines headers and the header/body split only. Structured, non-text bodies are MIME's job.
RFC reference
RFCs covered: RFC 5322. Superseded / updated by: obsoletes RFC 822 and RFC 2822.