# RFC 5322 — Internet Message Format

> Deliverability-focused digest of the message format: required vs. optional headers, From/Date/Message-ID/Reply-To rules, line limits, and malformations that trigger filtering.

Source: emailmarketing.net — https://emailmarketing.net/learn/rfc/rfc5322-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)](https://emailmarketing.net/learn/rfc/rfc5321-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)

| Field | Min | Max | Notes |
|---|---|---|---|
| `Date:` (orig-date) | 1 | 1 | **Required** |
| `From:` | 1 | 1 | **Required**; a mailbox list |
| `Sender:` | 0 | 1 | **MUST** appear if `From:` has more than 1 mailbox; a single mailbox |
| `Reply-To:` | 0 | 1 | An 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 | Added at the top in transit; never added by the author |
| `Resent-*` | 0 | unlimited blocks | See below |
| Optional and extension fields (`X-*`, `List-*`, …) | 0 | unlimited | Names must be unique unless specified otherwise |

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](https://emailmarketing.net/learn/authentication/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](https://emailmarketing.net/learn/rfc/rfc5321-smtp)). 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; an instant heuristic hit |
| Missing `Message-ID:` | Legitimate mail submission agents (MSAs) add one, so its absence correlates with spamware |
| Duplicate `From:`, `Subject:` or `Date:` | Malformed, and a phishing evasion pattern |
| Several mailboxes in `From:` without `Sender:` | Violates the specification |
| Bare `LF` line endings, lines over 998 characters | Parsers disagree; some MTAs reject outright |
| Raw 8-bit or UTF-8 bytes in headers without RFC 2047 encoding (or SMTPUTF8) | Rendering is undefined, and filters penalize it |
| Malformed `Date:` (2-digit year, alphabetic zones, impossible values) | Obsolete syntax, and a fingerprint of bulk mailers |
| Unmatched angle brackets or comments in address fields | Spoofers exploit the ways parsers disagree, so filters distrust it |
| Missing or wrong separator between header and body | Body text is read as headers, or the reverse |
| Empty or whitespace-only `Subject:` (allowed, but scored) | A bulk-mail heuristic |

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)](https://emailmarketing.net/learn/rfc/rfc5321-smtp), the envelope that carries this content
- [RFC 5598 (Internet Mail Architecture)](https://emailmarketing.net/learn/rfc/rfc5598-email-architecture), on which actor sets which header
- [DMARC](https://emailmarketing.net/learn/authentication/dmarc), which authenticates the `From:` domain