What this RFC defines
RFC 5322 defines the format of email messages: how headers are structured (From, To, Subject, Date, Message-ID), what characters are allowed, how folding whitespace works, and how the body separates from the headers. It is the rulebook that every email client and server uses to parse and generate messages.
Where you see it in practice
Every email you send has a Date: header in RFC 5322 format. The Message-ID: header your ESP generates is defined here. When a spam filter parses your From: header to extract the domain for DMARC alignment, it follows RFC 5322’s address parsing rules. Malformed headers that violate RFC 5322 often cause display bugs in email clients or trigger spam filter penalties.
How it connects to other RFCs
RFC 5322 supersedes RFC 2822 (2001) and RFC 822 (1982). It works alongside RFC 5321 (SMTP transport) and the MIME RFCs (2045-2049) which extend the message body format. RFC 6532 extends RFC 5322 to support UTF-8 headers for internationalized email.
Current status
RFC 5322 is the current standard for internet message format, published October 2008. It remains the authoritative reference for email header syntax and is not expected to be superseded in the near term.
The current message format standard
RFC 5322 is the current definition of what constitutes a valid internet mail message. It specifies the structure (headers, blank line, body), the syntax of each core header field, the rules for continuation lines and quoting, and the character set constraints. Every email client, mail server, and library that generates or parses email must conform to this document to produce mail that is broadly compatible across the internet. The document is authored by Pete Resnick and was published in October 2008.
Practical impact on address parsing
RFC 5322 address syntax is famously complex. The grammar allows comments in nested parentheses, quoted display names, multiple domain forms, and edge cases like the local-part being a quoted string containing spaces and special characters. Most email validation regexes on the internet are wrong because they simplify this grammar, and the popular “just check for @ and a dot” heuristic accepts inputs that RFC 5322 rejects and rejects inputs that RFC 5322 accepts. The correct approach is to use a library that implements the ABNF grammar directly, such as the Python email.utils module, the Ruby Mail gem, or the rfc-email-validator family of packages.
Character set and encoding rules
RFC 5322 constrains header fields to US-ASCII. Non-ASCII characters in headers must be encoded per RFC 2047 (encoded-word syntax for display names and comments) or, for modern deployments, per RFC 6532 (internationalized email headers, which permits UTF-8 directly when both endpoints support RFC 6531). The body has no character set constraints in RFC 5322 itself; MIME headers (RFC 2045) declare the body content type and encoding. This layered design means RFC 5322 stays small and focused on structure while delegating content details to MIME.
RFC 5322 (October 2008) defines the Internet Message Format: the structure and syntax of email messages themselves (as opposed to the transport protocol in RFC 5321). It specifies header fields (From, To, Subject, Date, Message-ID), the header block terminator (blank line), body separation, folding whitespace, and character set constraints. Obsoletes RFC 2822 (2001) and RFC 822 (1982). Extended by RFC 6532 for internationalized (UTF-8) headers and by the MIME RFCs (2045 through 2049) for structured body content. Every email client, mail server, and parsing library targets this document.
RFC 5322 at a glance
| Aspect | Detail |
|---|---|
| Scope | Message-level format: headers, body separator, header field syntax |
| Complements | RFC 5321 (SMTP transport) and MIME RFCs (body structure) |
| Character set | US-ASCII in base standard; UTF-8 via RFC 6532 for internationalized headers |
| Address syntax | Complex ABNF grammar: mailbox, group, display-name, angle-addr, comments, folding whitespace |
| Header/body separator | Single CRLF line (empty line) |
| Line length | SHOULD be under 78 chars, MUST be under 998 chars (excluding CRLF) |
| Published | October 2008 (obsoletes RFC 2822, RFC 822) |
| Status | Current standard; no successor planned |
Complete core header field reference
RFC 5322 defines a small set of standard header fields. Many additional headers are registered in RFC 4021 and elsewhere. The core fields below appear in essentially every email message.
| Header | Purpose | Format | Required? |
|---|---|---|---|
From | Visible sender identity | mailbox-list (usually one mailbox with display name) | Required |
Sender | Actual submitting party if different from From | Single mailbox | Conditional (if From has multiple, or if sender differs) |
To | Primary recipients | address-list | Recommended |
Cc | Carbon-copy recipients | address-list | Optional |
Bcc | Blind-carbon-copy recipients (stripped on delivery) | address-list | Optional |
Date | Time message was sent by originator | Fri, 15 Jul 2026 09:32:15 +0000 | Required |
Message-ID | Globally unique identifier for the message | <unique-id@domain> | Recommended |
Reply-To | Address for replies if different from From | address-list | Optional |
Subject | Short human-readable topic | unstructured text (RFC 2047 encoded if non-ASCII) | Recommended |
In-Reply-To | Message-ID(s) this message replies to | msg-id-list | Optional (threading) |
References | Full chain of prior Message-IDs in thread | msg-id-list | Optional (threading) |
Return-Path | Envelope sender copied by receiving MTA | angle-addr | Added by receiver (not sender) |
Received | Trace field from each MTA in path | Complex trace syntax | Added by MTAs (see Received trace guide) |
Address specification syntax
RFC 5322 address grammar is famously complex. The core forms are shown below, together with correct examples for each.
Critical parsing rules and gotchas
| Rule | Applies to | Consequence if violated |
|---|---|---|
| CRLF terminates every line | Entire message | Bare CR or bare LF causes parser errors and can be exploited (SMTP smuggling) |
| Blank line separates header from body | Whole message | Malformed body detection; content appears in headers or vice versa |
| Header lines can fold on whitespace | Long header values | Continuation must start with space or tab; parsers must unfold before processing |
| Line length limit | Header and body lines | MUST under 998, SHOULD under 78; longer lines may be truncated or rejected by strict receivers |
| Header names case-insensitive | All header field names | from: and From: are equivalent; parsers must normalize |
| Header values case-sensitive for content | Header field bodies | Message-ID comparison is case-sensitive per section 3.6.4 |
| Comments in parentheses ignored | Structured headers | Parser must recognize and skip comments; content inside is not part of the semantic value |
Common header handling mistakes
user..name@example.com) and reject valid ones (like "quoted user"@example.com). Use a proper library (Python email.utils.parseaddr, Ruby Mail gem, JavaScript email-addresses) rather than a homemade regex."security@yourbank.com" <attacker@example.com> is legal syntax where the display name looks like an email address. Naive UI code shows the display name as trustworthy; the actual sender is attacker@example.com. Always extract the addr-spec, never trust display name presentation for authenticity decisions.Migration from RFC 2822 to RFC 5322
| Aspect | RFC 2822 (2001) | RFC 5322 (2008) | Impact if code targets 2822 |
|---|---|---|---|
| Core grammar | ABNF for header fields | Same ABNF with clarifications | None |
| Obsolete syntax | Documented separately | Integrated in main text | None |
| Errata | Errata reported separately | Errata integrated | None |
| Line length | SHOULD 78, MUST 998 | Same, clarified | None |
| Address literals | IPv4 | IPv4 + IPv6 | Update address parser for IPv6 literal syntax |
| Group syntax | Section 3.4 | Same | None |
Related standards and further reading
- RFC 5321: SMTP transport protocol (carries RFC 5322 messages)
- RFC 4021: Registration of mail and MIME header fields
- RFC 2045 through RFC 2049: MIME (multipart body structure)
- RFC 2047: Encoded-word syntax for non-ASCII in headers
- RFC 6532: Internationalized email headers (UTF-8)
- RFC 6531: SMTPUTF8 extension for internationalized addresses
- RFC 5890: IDNA 2008 (internationalized domain names)
- RFC 3696: Address checking and validation guidance
- Message-ID Header: correct generation and uniqueness patterns
- Received Headers and Email Trace Chain: parsing the Received chain
- Authentication-Results Header: SPF, DKIM, DMARC verdicts
- Content-Type and MIME Structure: body-side complement to RFC 5322
- Email Headers Explained: full walkthrough of a real message
Frequently asked questions
What is the difference between RFC 5322 and RFC 5321?
RFC 5321 defines SMTP, the protocol that transfers messages between servers; RFC 5322 defines the internal format of the message being transferred. Think of RFC 5321 as the envelope in the postal system (with To/From addresses and delivery instructions) and RFC 5322 as the letter inside (with headers, salutation, and body). Both are needed. A message that conforms to RFC 5322 but is transported outside SMTP is still valid mail; conversely, an SMTP conversation transporting a malformed message will still complete the protocol, though the recipient client may fail to parse the result.
Why is email address validation so hard?
RFC 5322 address grammar is exceptionally permissive. Quoted local-parts allow spaces, most punctuation, and even embedded quotes. Comments in nested parentheses are legal and can be interleaved anywhere in the address. Display names can contain almost any character when quoted. IP address literals (IPv4 and IPv6) are legal. The result is that a full RFC 5322 address parser is a substantial piece of code, and simplifications almost always miss valid addresses or accept invalid ones. Practical advice: use a library that implements the ABNF grammar, and pair syntax validation with an actual delivery test to a mailbox verification service.
What character encoding do email headers use?
Base RFC 5322 restricts headers to US-ASCII. Non-ASCII characters are encoded via RFC 2047 encoded-word syntax (e.g., =?UTF-8?B?SGVsbG8=?=). Modern deployments increasingly support RFC 6532 which permits raw UTF-8 in header values when the SMTP server advertises SMTPUTF8 per RFC 6531. Body content is not constrained by RFC 5322 itself; it is described by MIME headers per RFC 2045.
What is the maximum line length in an email?
RFC 5322 section 2.1.1 says lines SHOULD be under 78 characters and MUST be under 998 characters, excluding the CRLF terminator. Longer values (typical for DKIM-Signature, References with many IDs, long Subject with encoded text) must be folded on whitespace boundaries. A folded line starts with a space or tab. Parsers unfold before processing. Violating the 998 limit can cause strict receivers to reject the message or truncate the line.
What does Return-Path have to do with the From header?
Nothing directly. Return-Path is added by the receiving MTA from the MAIL FROM envelope address per RFC 5321; it identifies where bounces go. The From header inside the message is set by the sender and identifies the visible sender to the recipient. The two can differ. DMARC alignment policy compares them (specifically compares the From domain against the Return-Path domain for SPF alignment, and against the DKIM-Signature domain for DKIM alignment) and rejects when policy requires alignment and the domains differ.
Can I use RFC 5322 headers with UTF-8 directly?
Only if both the sending and receiving mail systems support RFC 6531 (SMTPUTF8) and RFC 6532 (internationalized headers). Base RFC 5322 requires ASCII in headers; UTF-8 in a header without SMTPUTF8 negotiation is a protocol violation and produces unpredictable results. For compatibility, use RFC 2047 encoded-word syntax for non-ASCII display names and Subject values; every mail client from the last 20 years handles that correctly.
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.
