E-mail header fields (Received, Date, From, Message-ID) — Forensic Artifact Reference (E-mail)

01Location

The raw message (.eml, .msg export or the mailbox store), not the rendered view in a mail client
'View source', 'Show original' or 'Message options' in the client; the original is preferable to a forward

Through which servers did the message pass, in what order and at what times?
What did the sender's software claim about the author, the date and the reply address?
Is this the same message as another copy, and which identifier does it carry?

Format	Text header fields in RFC 5322 syntax: a name, a colon and a value, with long values folded onto continuation lines that begin with white space. The header block ends at the first empty line.
Applies to	RFC 5322 (message format) and RFC 5321 (SMTP trace information). Clients and servers add many further fields that these standards do not define.

Field	What it tells you
Received	Trace line added by each SMTP server: FROM (name given in EHLO and the address from the TCP connection), BY, optional WITH, ID and FOR clauses, a semicolon and a date-time.
Return-Path	Added at final delivery; holds the reverse-path from the SMTP MAIL command, the address for failure notices.
Date	The origination date: when the creator said the message was complete and ready to enter the delivery system. It is not the transport time.
From, Sender, Reply-To	From names the author; Sender names the agent that transmitted the message, if different; Reply-To names where replies should go.
Message-ID	A unique identifier for one version of one message, guaranteed unique by the host that generated it. Revisions get new identifiers.
In-Reply-To, References	The Message-IDs of the messages a reply answers, used to rebuild threads.

Field	Encoding	Note
Received (after the semicolon)	RFC 5322 date-time, e.g. Tue, 07 Apr 2026 10:12:43 +0300	RFC 5321 says servers SHOULD use explicit numeric offsets rather than zone names. Convert each hop to UTC before comparing hops.
Date	RFC 5322 date-time with offset	Set by the originating software on the sender's side, so it follows the sender's clock and zone. It can precede, and differ from, the first Received time.

Decode raw values with the Timestamp decoder and convert local wall-clock times with the Local time to UTC.

Work from the raw message and keep an unmodified copy with its hash. A forwarded or re-saved message has been rewritten by the forwarding client.
List the Received lines from the bottom up. Each server prepends its own line, so the lowest line is the earliest hop and the top line is the receiving server's.
Decide which hops belong to your own organisation. Only lines added by servers you control are reliable; lines below them were written by systems you cannot vouch for.
Convert every time to UTC, then compare the Date claim with the first trusted Received time and note the difference.
Record Message-ID, and use it to find the same message in the mail service's message trace and in other mailboxes.

From, Sender, Reply-To and Date are values the sender's software wrote. Nothing in RFC 5322 makes them true.
RFC 5322 treats trace fields as strictly informational and leaves their interpretation to RFC 5321. Separately, a Received line below your own trust boundary can be missing, edited or invented.
Clock differences between servers can make hops appear out of order or show negative delays; the line order, not the time, is the order of handling.
A Message-ID shows which version of a message this is. It does not show who wrote it or that it was read.