RFC 2822 · · Proposed Standard (obsoleted by 5322)
The email format's in-between edition.
The official title is "Internet Message Format." What it actually did: modernise RFC 822's 1982 email format, most importantly giving the date a four-digit year, then hand off to RFC 5322 seven years later. The middle of three, and the one people forget.
Written by Noel Lang · IT trainer
TL;DR
RFC 2822 was the 2001 revision of the internet email format, sitting between the 1982 original RFC 822 and the current RFC 5322 . It kept the same header, blank line and body structure and cleaned up the syntax, most visibly by requiring a four-digit year in the Date header. It is now obsolete, but the format it described is essentially the one you still use.
The problem it solves
By 2001,
RFC 822
was nearly twenty years old. It still described email accurately, but it showed its age: the grammar was loose in places, some rules were ambiguous, and its date format used a two-digit year, 82 rather than 1982, the kind of shortcut the Y2K scare had just taught everyone to distrust.
RFC 2822 was the tidy-up. It did not reinvent email; it restated the existing format in stricter, clearer language and fixed the details that two decades of real use had exposed. The most visible change was the smallest to describe: the year in a Date header became four digits. Everything a modern parser relies on to read a date unambiguously starts here.
The middle child
Every trilogy has a middle installment nobody quotes, and in the email format story that is RFC 2822. RFC 822 gets remembered as the origin. RFC 5322 gets used because it is current. RFC 2822 did the quiet, necessary work in between, modernising the grammar and closing the year gap, and then stepped aside seven years later when 5322 refined it further.
That is not a criticism. The reason 5322 could be a small, safe edit is that 2822 had already done the hard modernisation. When you see “RFC 2822” in an old library or a code comment, read it as “the email format, one edition ago”: the same shape, the same blank-line rule, just superseded by a newer document that says almost the same thing.
What the RFC actually says
Short and mostly a careful respecification of RFC 822. The map, if you go to the source:
| Section | In plain words |
|---|---|
| 1 · Introduction | States the goal plainly: revise RFC 822, keep what works, drop what the last two decades proved unused or broken. |
| 2–3 · Body & syntax | The heart of it: the same header, blank line and body, respecified in a stricter, cleaner grammar than 1982 managed. |
| 3.3 · Date and time | The famous fix: a four-digit year, at last, replacing RFC 822's two-digit one. |
| 4 · Obsolete syntax | An honest appendix listing the old 822 forms a parser must still accept but nobody should generate. The graceful-degradation section. |
Things people get wrong
-
"RFC 2822 replaced RFC 822 with a new format."
It did not change the format, it re-specified it. The header block, the blank line and the body are identical to
. What RFC 2822 fixed was precision and a few details, the four-digit year above all. Same email, tighter rulebook. -
"If code says 2822, it is out of date and wrong."
Out of date, yes; wrong, almost never. Because the format barely moved between 822, 2822 and
, code that targets RFC 2822 still parses and produces valid modern email. Update the citation when you can, but it is not a bug on its own. -
"RFC 2822 covers sending mail."
It covers only the message format, the same scope as 822 and 5322. Moving a message between servers is SMTP's job,
. The trilogy 822, 2822, 5322 is all about what a message looks like, never about how it travels.
Where you'll still meet RFC 2822
An obsolete edition that lingers in citations more than in behaviour. Where it turns up:
| You see | What it means |
|---|---|
| A code comment citing "RFC 2822" | Usually a library or tutorial written between 2001 and 2008. The format it means is the same one RFC 5322 now defines. |
Date: Mon, 11 Oct 2010 22:14:15 +0000 |
The four-digit-year date format, the one visible change RFC 2822 made and RFC 5322 kept. |
Python's email.utils.parsedate docs |
Older standard-library documentation and many mail tools still name RFC 2822 as their reference point. |
| A "must accept, must not generate" parser rule | The obsolete-syntax handling that RFC 2822 formalised, so new mail is clean but old mail still reads. |
Questions people actually ask
What is RFC 2822? +
RFC 2822 is the 2001 revision of the internet email message format. It replaced the original RFC 822 from 1982, kept the same header-blank-line-body structure, and cleaned up the syntax, most visibly by requiring a four-digit year in the Date header. It was itself replaced by RFC 5322 in 2008, so it is now obsolete, but for seven years it was the definition of what an email looked like.
What is the difference between RFC 822, RFC 2822 and RFC 5322? +
They are three editions of one standard, the internet message format. RFC 822 (1982) is the original, RFC 2822 (2001) modernised it and fixed the two-digit year, and RFC 5322 (2008) is the current version. Each obsoletes the one before, and the core, a header block, a blank line and a body, never changed. New code should follow RFC 5322; RFC 2822 is the forgotten step in between.
What is the RFC 2822 date format? +
It is day-of-week, day month four-digit year, time and zone offset, for example Mon, 11 Oct 2010 22:14:15 +0000. The headline change from RFC 822 was exactly this: a full four-digit year instead of the old two-digit one, closing a Y2K-style ambiguity. RFC 5322 carries the same format forward.
Is RFC 2822 still current? +
No. RFC 2822 was obsoleted by RFC 5322 in October 2008. You will still see it cited in older libraries, tutorials and code comments, because the format barely changed, but any new work should reference RFC 5322. Treat a mention of 2822 as pointing at the same email format, one edition out of date.
Referenced by
Other explainers on this site that point back to this RFC:
How RFC 2822 connects
What came before
-
RFC 822 (1982) defined the email format first. RFC 2822 is its modernised second edition, keeping the shape and fixing the details.
Part of a guided cluster: The email RFCs, explained