How do RFCs evolve and become deprecated?

You're reading through some email documentation and you spot two RFCs covering the same territory. One is from 2001, one is from 2011. Which one actually matters? And how do you know if the newer one has itself been replaced by something else?

Here's how the process works. RFCs don't get edited after publication. Once an RFC is out, it's frozen. If something needs to change, a new RFC is written. That new document explicitly states whether it obsoletes the old one (replaces it entirely) or simply updates it (amends specific parts while leaving the rest intact).

Every RFC carries a status label that tells you where it sits in the lifecycle. The main ones you'll encounter are:

• Proposed Standard. Active, being adopted, but not yet widely battle-tested.
• Internet Standard. Fully ratified, broad consensus, this is what you implement.
• Best Current Practice (BCP). Operational guidance rather than protocol. Often more practically useful than a formal Standard.
• Historic. The spec was never widely adopted, or it's been retired by the community. Don't build against it.
• Obsolete. Explicitly replaced by a newer RFC. The old document will tell you exactly which RFC took over.

An RFC with "Obsoleted by RFC XXXX" in its header is telling you directly where to go next. An RFC with "Updated by RFC XXXX" means there's a patch you need to read alongside the original. Both are visible right at the top of every document.

The easiest way to check is the IETF Datatracker. Search any RFC number and you'll see its current status, whether it's been obsoleted or updated, and what replaced it. It takes about 30 seconds. For email specifically, the chain of evolution is worth knowing. RFC 5321 (SMTP) obsoleted RFC 2821, which itself obsoleted RFC 821. RFC 2822 defined the message format, then RFC 5322 replaced it. These aren't trivia. If you're building against RFC 821 without knowing it's been through two full revisions, your implementation will have gaps.

One thing worth knowing: obsolete RFCs stay publicly available forever. The IETF doesn't delete them. That's intentional. Historical context matters when you're debugging old systems or understanding why certain design decisions were made. Just don't implement from them as if they're current.

If you're implementing an email authentication protocol and want to make sure you're reading the right spec, start with the Datatracker. It's the authoritative source. No guesswork needed.