RFC 5322 · · Draft Standard
The anatomy of an email, and why the From line can lie.
The official title is "Internet Message Format." What it actually decides: the structure of an email message, the headers, the body, and what a real address may look like. It defines the document itself, long before SMTP carries it anywhere.
Written by Noel Lang · IT trainer
TL;DR
RFC 5322 defines the format of an email message. It specifies the header fields (From, To, Subject, Date, Message-ID), the blank line, the body, and the grammar of a valid address. It says nothing about delivery: moving the message is SMTP’s job (RFC 5321). Because 5322 only describes what a header looks like, not whether it is true, the From line can say anything, which is exactly why email spoofing is possible. It replaced RFC 2822 in 2008.
The problem it solves
Email works only because every mail program on earth agrees on the same layout: where the headers end and the body begins, how a date is written, what an address may contain. Without one shared grammar, a message composed in Outlook would be unreadable in Gmail, and a mailing list from 1995 would be gibberish today.
RFC 5322 is that grammar. It is deliberately, almost stubbornly, separate from transport. It says nothing about how a message travels, only what it is: a block of header fields, a single empty line, and a body of plain US-ASCII text. That clean split, format here, delivery in RFC 5321 , is why the same message shape has survived four decades of changing mail servers, clients and networks.
The envelope and the letter
Here is the single most important thing to understand about email, and the source of most confusion around it. Sending a message involves two separate standards that people constantly merge into one.
RFC 5321
is SMTP: the postal service. It carries an envelope with its own sender and recipient (the MAIL FROM and RCPT TO commands), and it is what actually decides where the mail goes. RFC 5322 is the letter inside that envelope: the From:, To: and Subject: you read in your mail app.
The twist, the one that explains a decade of security headaches: nothing in the base standards forces the envelope and the letter to agree. A server routes your mail using the envelope sender. Your eyes read the From: header in the letter. An attacker can put one address on the envelope and a completely different, trusted-looking one in the letter. The mail is delivered by the first and believed by the second. That mismatch is email spoofing, and it is why SPF, DKIM and DMARC were later invented to check that the sender is who the letter claims.
Why the From line can lie
Two standards, two senders. SMTP delivers by the envelope address; you trust the address printed in the letter. Nothing at this layer checks that they match.
Anatomy of a raw email
This is what a message really is once you strip away the mail app: a stack of Name: value header fields, one empty line, then the body. Everything your client shows you is parsed out of this.
What RFC 5322 does not do
The standard is narrower than people assume. Almost everything that makes modern email feel rich lives in other RFCs, layered on top of a plain-text 5322 message:
-
Attachments not here
No. A 5322 body is one block of text. That PDF you attached is Base64-encoded and packed into the body by MIME (RFC 2045). To 5322 it is just more text.
-
HTML and images not here
No. Bold text, buttons and inline images are also MIME, layered on top. RFC 5322 knows only plain text with a subject and a body. Everything richer rides inside as encoded content.
-
Umlauts in headers needs help
Not directly. A raw 5322 header is US-ASCII only. A Subject like Grüße is encoded by RFC 2047 into ASCII gibberish and decoded by your client. The header looks plain; the display does not.
-
Delivery not its job
No. How a message travels, retries and bounces is SMTP (RFC 5321). 5322 describes the letter sitting on the desk, never the postal route it took to get there.
The pattern is always the same: 5322 defines a plain-text container, and MIME (RFC 2045, 2047) packs the modern web into it as encoded text.
What the RFC actually says
The original is readable and mostly grammar. Here is the map, in case you want to visit the source:
| Section | In plain words |
|---|---|
| 2 · Message format | The shape of it all: header fields, then one empty line, then the body. Lines are US-ASCII and, by rule, at most 998 characters long. |
| 2.2 · Header fields | A field is a name, a colon, and a value (From: someone@example.com). The grammar for the parts every message is built from. |
| 2.2.3 · Long lines (folding) | How a header too long for one line is broken across several by inserting a newline before a space, and joined back together on the other side. |
| 3.4 · Address specification | The famous part: what a mailbox and an address group may look like. The source of every "is this a valid email?" argument. |
| 3.6 · Field definitions | Which headers exist and which are mandatory. Every message MUST have an origination Date and a From. Everything else is optional. |
| 4 · Obsolete syntax | The relics: forms a parser must still accept from old mail but must never generate. Decades of backwards compatibility, written down. |
Things people get wrong
-
"The address in the From header is verified."
It is not. RFC 5322 defines what the From field looks like, never that it is true. Anyone can write From: Your Bank <security@bank.com> into a message. The address that actually routed the mail is the SMTP envelope sender, a separate value that need not match. That gap is the root of email spoofing, and the whole reason SPF, DKIM and DMARC exist.
-
"RFC 5322 controls how email is delivered."
It controls nothing about delivery. 5322 describes the document: headers, body, addresses. Moving it from one server to the next, retrying, bouncing, that is all SMTP (RFC 5321). The two were published on the same day and are constantly swapped, but one is the letter and the other is the postal service.
-
"Attachments are stored inside RFC 5322."
They are not part of 5322 at all. The standard knows only plain text: a set of headers and a body. Attachments, HTML and images are MIME (RFC 2045), which encodes them as text and tucks them into the 5322 body. RFC 5322 carries the payload without ever understanding it.
-
"RFC 822 is dead and gone."
Its number is retired, its text is not. RFC 822 (1982) defined the message format so cleanly that 2822 and then 5322 mostly restated it. The core, header colon value, blank line, body, still stands almost verbatim. When people say "822 format" for a date or a header, they are describing something very much alive.
Where you'll meet RFC 5322
You touch this standard constantly without naming it. A field guide to spotting it:
| You see | You're probably looking at |
|---|---|
| "Show original" / "View source" | Every mail client hides a button that reveals the raw 5322 message: the headers and body exactly as this RFC defines them. |
| A Message-ID in a support ticket | The Message-ID: header, a globally unique tag 5322 gives every mail. Support teams use it to find your exact message in the logs. |
| date -R on the command line | The -R flag prints the date in RFC 5322 format, precisely because that is the format email (and much else) expects. |
| A .patch file from git | git format-patch writes each commit as a 5322 message, From and Subject and all, so a patch can literally be emailed and applied. |
| Received: headers stacked on top | Each mail server that handled the message adds a trace header. They are 5322 header fields, but written by SMTP hops (RFC 5321) along the way. |
| A From that does not match the sender | The display name says your bank, the address underneath is a stranger. 5322 permits both, which is why the words and the address can disagree. |
Questions people actually ask
What is RFC 5322? +
RFC 5322 is the internet standard that defines the format of an email message: the header fields (From, To, Subject, Date and more), the blank line, the body, and the exact syntax of a valid address. It says nothing about how a message is delivered. That is SMTP's job. Published in 2008, it replaced RFC 2822.
What is the difference between RFC 5322 and RFC 5321? +
RFC 5322 defines what an email message looks like: its headers and body. RFC 5321 defines SMTP, the protocol that transports that message between servers. One is the letter, the other is the postal system and the envelope. They were published together in 2008 and are constantly confused, but they solve two different problems.
What is RFC 5322 simplified? +
It is the shared grammar that lets every mail program agree on the shape of a message: where the headers end and the body begins, how a date is written, what an address may contain. Without it, a mail composed in one client would be unreadable in another. It defines the message, not its delivery.
What counts as a valid email address under RFC 5322? +
Far more than most people expect. The local part before the @ may contain quoted strings, dots and many special characters, and the grammar even allows comments in parentheses. In practice almost every system accepts a stricter subset, which is why the notorious full RFC 5322 address-matching regex is thousands of characters long and almost never used.
Why can the From address in an email be faked? +
Because RFC 5322 only defines what the From header looks like, not whether it is true. The address that actually routes the mail is the SMTP envelope sender (MAIL FROM in RFC 5321), and nothing in the base standards forces the two to match. That gap is exactly why spoofing works, and why SPF, DKIM and DMARC were bolted on later to check the sender.
Did RFC 5322 replace RFC 2822? +
Yes. RFC 5322 obsoletes RFC 2822, which had itself obsoleted the original RFC 822. It is the current message format standard, later updated in one narrow area by RFC 6854 to allow group syntax in a few header fields. The core defined back in RFC 822 still lives on, almost word for word.
Are attachments and HTML email defined in RFC 5322? +
No. RFC 5322 only knows plain US-ASCII text: headers and a body. Attachments, HTML parts, images and non-ASCII characters all come from MIME (RFC 2045 and friends), which packs everything into a 5322 body as structured text. RFC 5322 carries MIME without knowing what it is.
Referenced by
Other explainers on this site that point back to this RFC:
How RFC 5322 connects
What came before
-
RFC 822 RFC 822 defined the email message format so well that its core survives almost verbatim today. RFC 5322 is the same document, twice revised and modernized.
-
RFC 2822 The 2001 revision that sat between 822 and 5322. RFC 5322 obsoletes it. Its number, 2822, was itself a deliberate homage to 822.
What it works with
-
RFC 5321 · companion to
SMTP, the envelope and the postman
The twin standard, published the same day. 5321 moves the message and carries the envelope sender; 5322 defines the message inside. The two together are one mail system, which is why they are endlessly confused.
-
RFC 2119 · written in the language of
The MUST and SHOULD underneath
Like almost every RFC, 5322 states its rules using the normative keywords MUST, SHOULD and MAY defined in RFC 2119. When it says a line MUST NOT exceed 998 characters, that word has a precise meaning.
Its counterparts
-
RFC 3339 · contrasts with
The other way to write a date
5322's date looks like <span class="font-mono text-sm">Fri, 03 Jul 2026 14:22:05 +0200</span>: human, English, day-name first. RFC 3339 is the machine-readable opposite (<span class="font-mono text-sm">2026-07-03T14:22:05+02:00</span>). Same instant, two cultures.
-
RFC 6854 · updated by
The one small amendment
RFC 6854 (2013) is the only update, and a narrow one: it lets From and a few other fields carry group syntax (an empty named group), needed for automated mail. The rest of 5322 stands untouched.
Part of a guided cluster: The email RFCs, explained