What does RFC 5322 define?

Every email you've ever sent follows a recipe. RFC 5322 is that recipe. It's the standard that defines the Internet Message Format, which means it specifies exactly how an email message should be structured so that any email client in the world can read it correctly.

Think of an email as having two parts: the envelope (that's RFC 5321 territory, covering how messages get delivered) and the letter itself. RFC 5322 is the letter. It covers what goes inside the message once it arrives.

What RFC 5322 actually defines:

• Header fields like From, To, Subject, Date, and Message-ID. RFC 5322 defines which are required, which are optional, and exactly how they must be formatted.
• Syntax rules for addresses, folding long header lines, and what characters are valid where.
• Body structure, including how the header section and the message body are separated (by a blank line, specifically).
• Line length limits: lines should stay under 998 characters, with 78 being the recommended soft limit.

Why does it matter in practice? If your From header is malformed, some receiving servers will reject the message outright. If your Date header is missing or in the wrong format, spam filters may flag it as suspicious. A missing or duplicate Message-ID can confuse threading in clients like Gmail or Outlook, so replies appear as separate conversations instead of a thread.

Most senders never touch RFC 5322 directly. A good ESP handles compliant formatting for you. But if you're sending via API, building a custom integration, or debugging a delivery issue, knowing what RFC 5322 governs tells you exactly where to look when something displays wrong.

You can see RFC 5322 headers in real life by opening the Email Header Analyzer on any message. If anything looks off, that's where we'd start digging.