← RFC Reference

RFC 5322 – Internet Message Format

Why This RFC Exists

RFC 5322 defines the syntax of an email message — the text that flows through SMTP during the DATA phase. Its ancestor, RFC 822 (1982), was one of the earliest internet standards. RFC 5322 updated the format with stricter syntax rules, clearer obsolete-syntax handling, and alignment with modern practices.

This RFC is purely about the message format — it says nothing about how the message gets transported (that's RFC 5321) or how attachments work (that's RFC 2045 and the MIME family). It defines the header fields, the body, and the rules for addresses, dates, and message identification.

How It Works

An email message is divided into two parts separated by a blank line:

1. Header section: A sequence of header fields, each as Name: value, terminated by CRLF.
2. Body: The message content, which is simply unstructured text (MIME adds structure on top).

Message Structure

Required Header Fields

RFC 5322 mandates that every message MUST contain these fields:

Additionally, every message SHOULD contain a Message-ID field — a globally unique identifier. Messages without a Message-ID cause problems with threading, deduplication, and DKIM signing.

Common Header Fields

Key Technical Details

Address Formats

RFC 5322 defines two valid address formats:

• Addr-spec: alice@example.com — just the mailbox.
• Name-addr: Alice Smith <alice@example.com> — a display name plus angle-bracketed address.

Display names containing special characters must be quoted: "O'Brien, Alice" <alice@example.com>. The local-part (before the @) is case-sensitive per spec but treated as case-insensitive by virtually all mail systems in practice.

Date Format

The date format is specific and unforgiving:

The format is: day-of-week, DD Mon YYYY HH:MM:SS zone. The day-of-week is optional but conventional. The timezone must be a numeric offset (-0500), not a name like "EST". While the spec tolerates old timezone abbreviations as obsolete syntax, generating them is not recommended.

Message-ID Format

A Message-ID must be globally unique and follows the form:

Best practice is to use a UUID or timestamp-based unique part combined with your sending domain: <20260311153000.a1b2c3@mail.example.com>.

Header Folding

Long header values can be "folded" by inserting a CRLF followed by at least one space or tab (whitespace). This is how long recipient lists or subject lines stay within the 998-character line limit:

Parsers must "unfold" these by joining lines where the continuation starts with whitespace.

Trace Headers

Each mail server that handles a message prepends a Received: header. These form a top-to-bottom trail — the topmost Received: header was added last. The Return-Path: header is added only by the final delivery system and contains the envelope sender from MAIL FROM.

Common Mistakes

• Missing or malformed Date header. Some spam filters penalize messages without a proper Date header or with a date far in the future/past. Always generate it at send time.
• Missing Message-ID. Without a unique Message-ID, replies won't thread properly, DKIM signatures may not cover the field, and some spam filters flag the message.
• Incorrect address quoting. Display names with commas, periods, or special characters must be quoted. O'Brien, Alice <alice@example.com> is invalid — it must be "O'Brien, Alice" <alice@example.com>.
• Using BCC incorrectly. The BCC header should be stripped before transmission. If you include BCC recipients in the header that gets delivered, you've defeated the purpose of blind carbon copy.
• Exceeding line length. Header lines and body lines must not exceed 998 characters. Use header folding for long headers and proper MIME encoding for long body content.
• Confusing From and Sender. The Sender: header is required only when the actual transmitting entity differs from the From: author. Don't add a redundant Sender header that matches From — it's unnecessary and can confuse filters.
• Wrong timezone format. Using EST instead of -0500 is obsolete syntax. Always use numeric offsets.

Deliverability Impact

• DKIM signing depends on headers. DKIM (RFC 6376) signs specific header fields. Missing or malformed headers means the signature may not cover what you expect, or the message may fail verification.
• DMARC alignment checks the From header. DMARC (RFC 7489) compares the domain in the From: header against SPF and DKIM results. A mismatched or missing From header means automatic DMARC failure.
• Threading and user experience. Proper Message-ID, In-Reply-To, and References headers ensure your messages thread correctly in recipients' mail clients. Broken threading makes your messages look unprofessional.
• Spam filter heuristics. Filters check for RFC 5322 compliance. Missing required headers, malformed dates, and non-standard formatting are all negative signals that increase your spam score.
• Display name spoofing. Mailbox providers increasingly display warnings when the From address looks suspicious. Using a clean, consistent From header with a recognizable display name improves open rates and trust.

Related RFCs