RFC 5322 — Internet Message Format

Every message you send has to follow a strict format, and filters at the major providers reject or heavily penalize messages that break it. Getting the format right is therefore a baseline deliverability requirement.

RFC 5322 defines that format: the content that travels inside the SMTP DATA command. The envelope around it is covered in RFC 5321 (SMTP). A message is a header section, made of fields of the form Name: body CRLF, followed by an optional body. One empty line separates the two.

Line and length rules

• Lines end with CRLF. A bare CR or a bare LF MUST NOT appear. This is a classic malformation introduced by naive scripts.
• Each line MUST be at most 998 characters long (not counting the CRLF), and SHOULD be at most 78.
• A header field may be folded across lines: a CRLF followed by whitespace (a space or a 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)

Only Date: and From: are mandatory. A duplicate of any field with a maximum of 1 (two From: headers, or two Subject: headers) makes the message malformed. A duplicate From: is also a known phishing evasion pattern, and filters punish it hard.

The fields that matter most for deliverability

From:

This field names the author or authors of the message. It is the identity DMARC evaluates and the one users see. Its syntax is a mailbox-list, and the display name is optional: "Ann Example" <ann@example.com>. If more than one mailbox is listed, Sender: becomes mandatory. That field holds a single mailbox: the agent responsible for actually transmitting the message. When Sender: is absent, the From: address is implicitly the sender. Alignment between this domain and the domains authenticated by SPF and DKIM is the core of DMARC.

Date:

This field records when the author "pushed send", in date-time syntax: day-of-week, DD Mon YYYY HH:MM:SS ±ZZZZ. The year has 4 digits and the zone is a numeric offset; names such as GMT and EST are obsolete syntax. Dates that are far in the past or the future are a spam signal at several providers.

Message-ID:

The syntax is <id-left@id-right> in angle brackets. Both sides are dot-atom-text, with no folding whitespace inside. The generator MUST guarantee global uniqueness, conventionally with a unique value followed by @ and your domain. Message-IDs that are missing, repeated across messages, or syntactically broken (no @, no angle brackets, not unique) are strong heuristics for bulk mail and spam. Always generate one at submission, with a domain you control.

Reply-To:

This field says where the author wants replies to go, in place of From:. Legitimate uses include role addresses and the handling of campaign replies. A Reply-To: domain that is very different from the From: domain is a common scam pattern and is scored accordingly. Keep the two consistent, or make the difference easy to explain.

In-Reply-To: and References:

These fields contain the Message-ID of the parent message, or several of them, and they build threads. When a sequence claims to be a reply (a "re:" in the subject with no real threading headers), the mismatch is detectable.

Resent and trace fields

• Resent-From:, Resent-Date:, Resent-To: and the other resent fields are added as a block at the top of the message, most recent first, when a user sends an existing message into the transport again (manual forwarding as a new message). Within a block, Resent-From: and Resent-Date: are mandatory. The original fields are never altered.
• Received:: each MTA hop adds one at the top. Reading them from the bottom up reconstructs the delivery path. A forged or inconsistent chain of Received fields is a filtering signal.
• Return-Path: is added at final delivery and records the envelope MAIL FROM (see RFC 5321). Authors MUST NOT set trace fields themselves.

Common malformations that trigger filtering

The safe rule is to generate messages with a real MIME library, never by concatenating strings, and to validate them with a linter before you increase volume.

What RFC 5322 does not cover

MIME (multipart bodies, attachments, HTML parts, content transfer encoding) is defined in RFC 2045–2049. Internationalized addresses and headers are RFC 6531 and RFC 6532 (SMTPUTF8). List-Unsubscribe and the other list headers are RFC 2369, RFC 2919 and RFC 8058. RFC 5322 is only the basic grammar of headers and body that those standards build on.

Related articles

• RFC 5321 (SMTP), the envelope that carries this content
• RFC 5598 (Internet Mail Architecture), on which actor sets which header
• DMARC, which authenticates the From: domain