rfc·explained

RFC 822 · · Internet Standard (obsoleted by 2822)

The shape of every email, defined in 1982.

The official title is "Standard for the Format of ARPA Internet Text Messages." What it actually decided: what an email looks like, a block of From, To, Subject and Date headers, a blank line, then the body. Written in 1982, obsoleted twice, and still the skeleton under every message you send.

Status
Obsoleted
Also known as
STD 11
Replaces
RFC 733
Replaced by
RFC 2822

Written by Noel Lang · IT trainer

TL;DR

RFC 822 defined the format of an email in 1982. A message is a block of header fields (From, To, Subject, Date), then a single blank line, then the body. It also fixed the email address form local-part@domain and the date format still used today. It was obsoleted by RFC 2822 and then RFC 5322 , but its structure is unchanged and lives under every message you send.

The problem it solves

In the early 1980s, electronic mail on the ARPANET already existed, but every system wrote it slightly differently. One host’s idea of a “From” line was another host’s confusion. Mail crossed between networks and arrived scrambled, because there was no shared agreement on what the top of a message should even contain.

RFC 822 ended that. It fixed one format for the text of a message, so that any program could read a mail written by any other. Crucially, it drew a hard line between the machine-readable part at the top and the human message below, and it standardised the email address itself, the local-part@domain shape you type without thinking to this day.

The business letter analogy

Picture a printed business letter. At the top sits a tidy block: who it is to, who it is from, the date, a “Re:” subject line. Then a gap. Then the letter itself, in plain prose. Anyone can tell the letterhead from the message at a glance, because the blank space between them says “structured details stop here, the actual writing starts now”.

RFC 822 is that convention, written down for machines. The header block is the letterhead; the blank line is the gap; the body is the letter. The one rule a mail program truly depends on is that gap: the first empty line is the border between the two worlds. Get it wrong, put no blank line, and your headers bleed into your text or your text vanishes into the headers. Forty years of email rest on that single empty line.

The two parts of a message

Header fields on top, a mandatory blank line, then the body. This is the “two major parts” everyone asks about, and the blank line is the border that makes it work. The RFC 5322 version looks almost identical, forty years later.

HEADER · machine-readable fieldsDate: Mon, 11 Oct 82 22:14:15 GMTFrom: Jane <jane@example.com>To: Sam <sam@example.net>Subject: Lunch?Message-ID: <abc123@example.com>← the one blank line that separates themBODY · free textAre you free for lunch on Thursday?Jane
Remove the blank line and a mail program can no longer tell where the headers end. That empty line is the whole contract.

What the RFC actually says

The original is dense with grammar rules, but the shape is simple. The map, if you visit the source:

Section In plain words
1–2 · Intro & notation Scope and the grammar notation used throughout. RFC 822 is careful about defining its own syntax vocabulary first.
3 · Lexical analysis The heart of it: a message is header fields, then a blank line, then the body. The single rule everything else hangs on.
4 · Message specification Every standard header defined one by one: From, To, Cc, Subject, Date, Reply-To, Message-ID and the rest.
5 · Date and time The Mon, 11 Oct 82 22:14:15 GMT format, two-digit year and all, that still shapes the Date header today.
6 · Address specification How addresses are written: local-part@domain, display names, angle brackets and groups. The birth of the email address as we know it.

Things people get wrong

  • "RFC 822 is obsolete, so it does not matter."

    Being obsoleted swapped the rulebook, not the format. and kept RFC 822's bones intact: the same header fields, the same blank-line separator, the same body. You touch its design every time you read a From line or a Subject. Obsolete on paper, foundational in practice.

  • "An RFC 822 name is a hostname or a person's name."

    It is an email address, nothing more. The term shows up in X.509 certificates, LDAP and Kubernetes for a field that holds local-part@domain. When something asks for an rfc822Name, it wants jane@example.com, not a server name and not a display name.

  • "RFC 822 covers sending email."

    It does not. RFC 822 defines only the message format, what a mail looks like once written. Getting it from one server to another is SMTP's job, originally RFC 821 and now . Confusing the format with the transport is the same mistake people make with syslog, and just as common.

  • "The two-digit year was harmless."

    RFC 822's date used a two-digit year, 11 Oct 82, a small decision that became a Y2K liability across mail software. fixed it by requiring four digits. A neat reminder that formats meant to last decades should spell out the century.

Where you'll still meet RFC 822

A 1982 standard that never really left. Where its fingerprints show up today:

You see What it means
rfc822Name in a TLS certificate An email address stored in an X.509 Subject Alternative Name. The certificate field is named after this RFC, four decades on.
From:, To:, Subject:, Date: at the top of a mail The RFC 822 header block, unchanged in every email client since 1982.
A blank line that "ate" your message Hand-rolled mail that forgot the empty line between headers and body. RFC 822's one hard rule, broken.
Message-ID: <...@host> The unique-id format RFC 822 introduced, still generated by every mail server for threading and de-duplication.
mutt, procmail, formail Classic Unix mail tools that parse and filter messages directly in the RFC 822 format.

Questions people actually ask

What is RFC 822? +

RFC 822 is the 1982 standard that defined what an email message looks like: a set of header fields such as From, To, Subject and Date, then a blank line, then the message body. It did not define how mail is sent, only how it is formatted. It was obsoleted by RFC 2822 and then RFC 5322, but the structure it set down is still what every email uses today.

What is an RFC 822 name? +

An RFC 822 name is simply an email address in the local-part@domain form that RFC 822 standardised, for example jane@example.com. The phrase survives in technical fields that predate friendlier wording: an X.509 TLS certificate stores an email address in a Subject Alternative Name entry literally typed as rfc822Name, and LDAP and Kubernetes use the same label. So when a tool asks for an RFC 822 name, it wants an email address.

What are the two major parts of an RFC 822 message? +

The header and the body, separated by a single blank line. The header is the block of Field: value lines at the top (From, To, Subject, Date and so on); the body is the free text below. That one empty line is the only thing telling a mail program where the structured header stops and the human message begins, which makes it RFC 822's single most important rule.

What is the RFC 822 date format? +

It is day-of-week, day month year, time and zone, for example Mon, 11 Oct 82 22:14:15 GMT. Notably the year was two digits, a Y2K trap that RFC 2822 later fixed by requiring four. This is the format behind the Date header in every email and the reason mail dates look the way they do.

What is the difference between RFC 822, RFC 2822 and RFC 5322? +

They are three editions of the same email format standard. 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, but the essentials, the header block, the blank line and the body, are unchanged. New code should follow RFC 5322; RFC 822 is where the shape came from.

Referenced by

Other explainers on this site that point back to this RFC:

How RFC 822 connects

What came before

  1. RFC 733 (1977) was the earlier ARPANET message format that RFC 822 revised and replaced. The lineage of the modern email header starts here.

Part of a guided cluster: The email RFCs, explained