RFC 5322 — Internet Message Format

RFC 5322 defines the content that travels inside the SMTP DATA command (see RFC 5321 — SMTP for the envelope). A message is a header section (fields of the form Name: body CRLF) followed by an optional body, separated by one empty line. Filters at major providers reject or heavily penalize messages that violate this spec, so format compliance is a baseline deliverability requirement.

Line and length rules

• Lines are terminated by CRLF. Bare CR or bare LF MUST NOT appear — a classic malformation introduced by naive scripts.
• Each line MUST be ≤ 998 characters (excluding CRLF) and SHOULD be ≤ 78.
• Header fields may be folded across lines: a CRLF followed by whitespace (space/tab) continues the same logical field. Unfolding reverses this. Non-ASCII bytes are not permitted in headers; encoded-words (RFC 2047) are used instead.

Header field occurrence table (Section 3.6)

Field	Min	Max	Notes
Date: (orig-date)	1	1	Required
From:	1	1	Required; mailbox-list
Sender:	0	1	MUST appear if From: has >1 mailbox; single mailbox
Reply-To:	0	1	Address list
To: / Cc: / Bcc:	0	1 each
Message-ID:	0	1	SHOULD be present
In-Reply-To: / References:	0	1 each	SHOULD appear in replies
Subject:	0	1
Comments: / Keywords:	0	unlimited
Trace (Received:, Return-Path:)	0	unlimited blocks	Prepended in transit; never added by the author
Resent-*	0	unlimited blocks	See below
Optional/extension fields (X-*, List-*, …)	0	unlimited	Names must be unique unless specified otherwise

Only Date: and From: are mandatory. Duplicating any max-1 field (two From: headers, two Subject: headers) makes the message malformed — and duplicate From: is a known phishing evasion pattern that filters punish hard.

The fields that matter most for deliverability

From:

Names the message author(s) — the identity DMARC evaluates and the one users see. Syntax: mailbox-list (display-name optional: "Ann Example" <ann@example.com>). If more than one mailbox is listed, Sender: (a single mailbox: the agent responsible for actual transmission) becomes mandatory. When Sender: is absent, the From: address is implicitly the sender. Alignment between this domain and the authenticated SPF/DKIM domains is the core of DMARC.

Date:

When the author "pushed send," in date-time syntax: day-of-week, DD Mon YYYY HH:MM:SS ±ZZZZ (4-digit year; numeric zone offset — GMT, EST etc. are obsolete syntax). Wildly wrong dates (far past/future) are a spam signal at several providers.

Message-ID:

<id-left@id-right> in angle brackets; both sides dot-atom-text; no folding whitespace inside. The generator MUST guarantee global uniqueness — conventionally something unique @ your domain. Missing, duplicate-across-messages, or syntactically broken Message-IDs (no @, no angle brackets, non-unique) are strong bulk-mail/spam heuristics; always generate one at submission with a domain you control.

Reply-To:

Where the author asks replies to go, overriding From:. Legitimate uses: role addresses, campaign reply handling. A Reply-To: domain wildly different from From: is a common scam pattern and gets scored accordingly — keep them consistent or explainable.

In-Reply-To: / References:

Contain the parent's Message-ID(s); they build threading. For sequences that claim to be replies ("re:" subject games without real threading headers), the mismatch is detectable.

Resent and trace fields

• Resent-From: / Resent-Date: / Resent-To: etc. — added as a block, prepended (most recent first), when a user reintroduces an existing message into the transport (manual forwarding-as-new). Within a block, Resent-From: and Resent-Date: are mandatory. Original fields are never altered.
• Received: — each MTA hop prepends one; reading them bottom-up reconstructs the delivery path. Forged or inconsistent Received chains are a filtering signal.
• Return-Path: — prepended at final delivery, recording the envelope MAIL FROM (see RFC 5321). Authors MUST NOT set trace fields themselves.

Common malformations that trigger filtering

Malformation	Why it hurts
Missing Date: or From:	Violates the only two MUSTs; instant heuristic hit
Missing Message-ID:	Legitimate MSAs add one; absence correlates with spamware
Duplicate From:/Subject:/Date:	Malformed + phishing-evasion pattern
Multiple mailboxes in From: without Sender:	Spec violation
Bare LF line endings, lines > 998 chars	Parsers diverge; some MTAs reject outright
Raw 8-bit / UTF-8 bytes in headers without RFC 2047 encoding (or SMTPUTF8)	Undefined rendering, filter penalty
Malformed Date: (2-digit year, alphabetic zones, impossible values)	Obsolete syntax; bulk-mailer fingerprint
Unmatched angle brackets / comments in address fields	Parsing divergence exploited by spoofers, so filters distrust it
Header/body separator missing or wrong	Body text interpreted as headers, or vice versa
Empty or whitespace-only Subject: (allowed, but scored)	Bulk heuristic

The safe rule: generate messages with a real MIME library, never string concatenation, and validate with a linter before ramping volume.

What RFC 5322 does not cover

MIME (multipart bodies, attachments, HTML parts, content-transfer-encoding) is RFC 2045–2049; internationalized addresses/headers are RFC 6531/6532 (SMTPUTF8); List-Unsubscribe and other list headers are RFC 2369/2919/8058. RFC 5322 is only the base header/body grammar those build on.

See also

• RFC 5321 — SMTP — the envelope this content rides in.
• RFC 5598 — Internet Mail Architecture — which actor sets which header.
• DMARC — authenticating the From: domain.