Email headers and MIME, decoded

Every mail client exposes the raw source somewhere. In Gmail: three-dot menu on the message, "Show original". In Outlook desktop: File → Properties → Internet headers. In Outlook web: three-dot menu → View message source. In Apple Mail: View → Message → Raw Source. From the command line, use openssl s_client to IMAP and issue a FETCH BODY[HEADER] command, or grep the raw .eml file. The raw source shows every header in order; specific headers can be found with a text search.

Message-ID is written once at message creation and identifies the message globally across all mail infrastructure. The id= field inside a Received header is written by each MTA that handles the message; it identifies the message locally to that MTA queue and changes at every hop. Use Message-ID for cross-server correlation. Use the Received id= only to correlate with a specific MTA logs.

Four headers do most of the work. From (must align with authenticated identity for DMARC). Return-Path (envelope sender, target for SPF checks). Message-ID (needed for threading, bounce correlation, and per-message tracking). List-Unsubscribe with List-Unsubscribe-Post (required by Gmail and Yahoo bulk sender rules since February 2024). The Authentication-Results header (written by the receiver) records the verdict from all of these checks.

Yes, physically. A sender can write any header value they want. What they cannot forge is what the receiving MTAs record. Received headers written by the receiver capture the actual source IP, the reverse DNS, and the TLS state, all of which the sender cannot spoof. Authentication-Results written by the receiver records the auth verdict against DNS-published records (SPF, DKIM), which the sender cannot bypass without controlling DNS. Forge outgoing headers all you want; the trustworthy records are the ones the receiver stamps.

RFC 5322 designates From, Date as MUST. Message-ID, In-Reply-To, References, Subject, Sender, Reply-To, To, Cc, Bcc are SHOULD or optional. In practice, receivers treat Message-ID as effectively mandatory (missing it triggers spam filters). MIME-Version becomes MUST when the message uses MIME. Content-Type is required for any non-plain-text body. The RFC distinction between MUST and SHOULD matters for spec conformance; the operational reality is that receivers penalize a broader set of missing headers than the RFC strictly requires.

RFC 5322 sets a soft limit of 78 characters per line and a hard limit of 998 characters. Longer values must be folded across multiple lines with continuation whitespace (a CRLF followed by a space or tab at the start of the next line). Most modern MTAs and MUAs handle folding automatically; hand-generated headers longer than 998 characters cause SMTP rejections at receiver level, typically with a 500-series error.