What this RFC defines
RFC 4021 registers the complete set of standard email header fields with IANA. It provides a canonical inventory of all headers defined across the various email RFCs: From, To, Subject, Date, Message-ID, MIME-Version, Content-Type, and dozens more, including their syntax, semantics, and the defining RFC for each one.
Where you see it in practice
When you need to know whether a particular email header is a registered standard or a proprietary extension, RFC 4021 is the reference. Email parsers and validators reference it to determine which headers are standard versus custom. The X- prefix convention for proprietary headers is also discussed here, though that convention has since been formally deprecated for new headers.
How it connects to other RFCs
RFC 4021 is a registration document that references virtually every other email RFC. It catalogues headers from RFC 5322 (message format), the MIME suite, RFC 5321 (SMTP trace headers like Received:), and authentication headers from RFC 7208 (SPF), RFC 6376 (DKIM), and others. It is informational and does not define new protocols.
Current status
RFC 4021 is a current informational RFC, published March 2005. The IANA header field registry it describes continues to be updated as new headers are standardised. It is the definitive lookup reference for standard email header fields.
The mail header registry
RFC 4021 (updated by RFC 3864 procedures) registered dozens of mail and MIME header fields with IANA, formalizing which headers exist and how they are used. Before this registration, header field usage was scattered across many RFCs and vendor extensions with no single authoritative list. The registry lets implementations know which header names are reserved, which are experimental, and which are provisional. Any new header field for mail or MIME should be registered under this framework.
Structure of the registry
The IANA Message Headers registry lists each header with its status (standard, informational, obsoleted), the reference RFC where it is defined, and any related registrations. As of 2026, hundreds of header fields are registered, including standard ones (From, To, Subject, Date, Message-ID), MIME ones (Content-Type, Content-Transfer-Encoding), authentication ones (DKIM-Signature, Authentication-Results, ARC-Seal), and many application-specific ones (List-Unsubscribe, X-Mailer).
Why registration matters
Registration prevents collision between independent implementations that might otherwise invent conflicting header names. It also makes it easier for parsers to know what to expect and to correctly ignore unknown headers. If you invent a new mail header for your application, prefixing with X- was the old convention but is deprecated by RFC 6648; use a descriptive name and register it. Common patterns like X-Company-Feature should be updated to Company-Feature style names for new development.
RFC 4021 (March 2005) creates the IANA Message Headers registry: the authoritative list of standardized email header field names, their definitions, and where they were introduced. Companion RFC 3864 establishes the registration procedures. Registry covers headers from RFC 5322 (From, To, Subject, Message-ID, Date), MIME headers from RFC 2045, and many extension headers (Received, Return-Path, List-Id, DKIM-Signature, ARC-Seal, and hundreds more). Reference registry for parsers, generators, and gateway processors.
RFC 4021 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Establish IANA registry for message header field names |
| Registry maintained at | iana.org/assignments/message-headers |
| Registration procedures | RFC 3864 (companion document) |
| Two protocols covered | Mail (email headers) and Netnews (Usenet headers, largely overlapping) |
| Coverage | RFC 5322 headers, MIME headers, extension headers (DKIM, DMARC, SPF, ARC, List-*, and more) |
| Published | March 2005 |
Categories of registered mail headers
| Category | Examples | Defined in |
|---|---|---|
| Origination | From, Sender, Reply-To, Date | RFC 5322 |
| Destination | To, Cc, Bcc | RFC 5322 |
| Identification | Message-ID, In-Reply-To, References | RFC 5322 |
| Informational | Subject, Comments, Keywords | RFC 5322 |
| Resent | Resent-From, Resent-Date, Resent-Message-ID | RFC 5322 |
| Trace | Received, Return-Path | RFC 5321 |
| MIME | MIME-Version, Content-Type, Content-Transfer-Encoding, Content-Disposition | RFC 2045, RFC 2183 |
| Authentication | DKIM-Signature, ARC-Seal, ARC-Message-Signature, ARC-Authentication-Results, Authentication-Results | RFC 6376, RFC 8617, RFC 8601 |
| List | List-Id, List-Post, List-Unsubscribe, List-Unsubscribe-Post | RFC 2919, RFC 2369, RFC 8058 |
| Disposition | Disposition-Notification-To, Original-Message-ID | RFC 8098 |
Common header handling mistakes
X- as an experimental marker. Modern pattern (per RFC 6648): register directly, or use a descriptive name without X-. Registered names document the intent and prevent collision.From, FROM, and from are the same field. Parsers must compare case-insensitively; generators typically use consistent casing (usually title case) but not by protocol requirement.Related standards and further reading
- RFC 5322 Guide: message format including headers
- Message-ID Header: correlation identifier
- Authentication-Results Header: SPF/DKIM/DMARC verdicts
- Received Headers and Email Trace Chain: delivery path forensics
Frequently asked questions
How do I find the authoritative list of email headers?
The IANA Message Headers registry at iana.org/assignments/message-headers. Includes every registered header with its defining specification, protocol scope (mail, netnews, or both), and status (standard, informational, obsolete). Reference this registry, not local documentation or search results, when implementing header-aware code.
Can I invent my own custom header for my application?
Yes, but register it via RFC 3864 procedures. Ad-hoc unregistered headers risk colliding with future standards. Registration is lightweight for informational or vendor-specific headers. Use a descriptive name (not X- prefix per RFC 6648); include vendor identifier if the header is company-specific (e.g., Mycompany-Feature rather than Feature).
Why does RFC 6648 deprecate X- prefixes?
Two problems with X-. First, X- headers frequently become de-facto standards without proper registration, then collide with the un-prefixed name when the standards tree eventually registers. Second, X- signals “experimental” which does not reflect reality for headers deployed for decades. Modern approach: register descriptive names directly. Existing X- headers can continue in use for backward compatibility.
Are header field names case-sensitive?
No. Per RFC 5322, header field names are case-insensitive. From:, FROM:, and from: are the same field. Parsers must compare case-insensitively. Generators typically use consistent title case (From:, Message-ID:) for readability, but this is convention not requirement. Field values, on the other hand, may be case-sensitive depending on the specific header semantics.
What is the difference between mail and netnews headers?
RFC 4021 covers both because Usenet netnews (NNTP) shares a message format lineage with email; both derive from RFC 822 and its descendants. Many headers apply to both protocols (From, Subject, Message-ID, Date). Some are specific: mail has Received and Return-Path; netnews has Path, Newsgroups, and Xref. The IANA registry marks scope per header. Modern relevance: mail is universal, netnews continues in niche communities.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
