Email RFCs: which document governs what
Email is not one specification. It is a stack of documents written across four decades, each one narrow, several of them replaced without being withdrawn. Support pages and vendor docs still cite numbers that stopped being current years ago, which is how an argument about correct behaviour ends up quoting a superseded text. This category holds one page per standard: what it defines, what it replaced, and what it means for a sender in practice.
Read the number before the argument
An RFC is never edited. When the working group changes something, it publishes a new number and marks the old one obsolete, so both documents stay online and both stay quotable. The obsolete text is still useful history, and it is still what half the internet links to.
Three chains cause most of the confusion. Transport went 821 to 2821 to 5321. Message format went 822 to 2822 to 5322. Sender authentication went 4408 to 7208 for SPF and 4871 to 6376 for DKIM. If a vendor page cites the first number in any of those pairs, it has not been revised in a long time.
The standards by job
Grouping by number tells you nothing, because the numbering follows publication order rather than subject. Grouping by the job the document does is what makes the set navigable.
Moving the message
The conversation between two servers: commands, replies, and the envelope that is separate from the headers a reader sees.
SMTP itself, the extension mechanism, submission by a mail client, greylisting behaviour
Writing the message
Header syntax, address syntax, and the multipart rules that let one message carry text, HTML and attachments at once.
Internet message format, the five MIME parts, non-ASCII headers, the header field registry
Proving who sent it
Three independent checks and one header that records their verdicts. Every bulk sender requirement published since 2024 rests on this group.
Saying why it failed
The machine-readable side of a bounce or a complaint. These are the documents your bounce parser is implementing, whether it knows it or not.
enhanced status codes, delivery status notifications, the report container, feedback report format
Identifying bulk mail
The headers that tell a mailbox provider this message belongs to a list, and the one that lets a reader leave it without opening anything.
List-Unsubscribe and its siblings, one-click signalling, List-Id
Reading the mailbox
Retrieval protocols and the encryption guidance that changed how clients are expected to connect to them.
The full index and where the standards land in practice
The complete list, with each document summarised in a line and sortable by subject, is the email RFC directory. Use it when you have a number and need the subject; use this category when you have a problem and need the number.
Most standards on this page show up somewhere concrete on the rest of the site. The reply codes and the dotted enhanced codes that receivers return are documented one rejection at a time in the SMTP code reference. The list headers become an implementation task in the unsubscribe guides, one page per sending platform. The authentication group turns into three DNS records, explained in the authentication guides and testable against a live zone with the SPF record checker.
Two documents are worth reading even when nothing is broken. The Internet mail architecture names the actors and hands you the vocabulary the other texts assume you already have, and the null MX record is the short one-page standard for a domain that sends but never receives, which is a configuration a surprising number of senders need and skip.
