Reading mail headers for delivery and authentication clues
A delayed message or an unfamiliar sender often leads to the same place: the headers above the message body. They contain useful delivery records, but they are not a single trustworthy certificate of the entire journey. Start by asking which system wrote each line.
Separate the visible author from delivery identities
Use the mail client option for message source or original message. A From line copied into an ordinary forwarded message is not a substitute for the original delivery headers.
Fields to read first
See RFC 5322 §3.6 for message fields and RFC 5321 §4.4 for Return-Path and trace records.
| Field | Meaning and limits |
|---|---|
| From | The stated author; a display name alone does not establish identity |
| Reply-To | The requested reply destination; a difference from From is not automatically evidence of abuse |
| Return-Path | The return address recorded at final delivery, with a different role from From |
| Date | An origination time supplied by the sender, not a receiving-server arrival time |
| Received | A handoff record added by a server |
New Received lines are added at the top
An SMTP server prepends its own Received line when it accepts a message. Reading the normal sequence from oldest to newest therefore means reading bottom to top. Putting records in that order does not, by itself, make them trustworthy.
Read a two-hop example
The lower line says relay received the message at 12:00:00; the upper says inbox received it at 12:00:04. The from part describes the sending side and by identifies the receiver adding the record. Four seconds is the difference between recorded arrivals, not necessarily four seconds of network transmission. Queueing, processing and clock differences can contribute.
Received: from relay.example.com (relay.example.com [192.0.2.20])
by inbox.example.net; Fri, 23 Oct 2026 12:00:04 +0000
Received: from sender.example.com (sender.example.com [192.0.2.10])
by relay.example.com; Fri, 23 Oct 2026 12:00:00 +0000Work outward from a receiver you trust
A sender can put fabricated Received lines into a message before handing it over. For an investigation, identify records added by your receiving service and trace back through peers those systems directly observed.
The bottom IP is not necessarily the original sender
Beyond the trusted boundary, earlier records may be sender-supplied claims. A familiar hostname is not enough to establish who wrote even a topmost line; use provider documentation or administrative logs to establish its origin. An IP address in a header also does not, by itself, identify a personal device or physical address.
Ask who produced Authentication-Results
Authentication-Results records outcomes such as SPF, DKIM and DMARC, together with the identities checked. Its initial authserv-id identifies the authentication service. The results become useful evidence only when you can attribute them to a trusted receiving environment.
An example result
SPF authenticated an example.org identity, while DKIM authenticated example.com. With From using example.com, aligned DKIM can account for the DMARC pass. Pasting this text into a reader does not repeat any authentication. RFC 8601 §1.2 and §7.1 explain the trust boundary and forged-result problem.
Authentication-Results: inbox.example.net;
spf=pass smtp.mailfrom=mailer.example.org;
dkim=pass header.d=example.com;
dmarc=pass header.from=example.comInspect order and time differences in the analyzer
Paste the Received example into the Online Tools mail header analyzer. It presents the lower record first, followed by a four-second difference. Parsing runs in the browser without sending the entered header to the server for analysis. It does not verify SPF or DKIM, or investigate the hosts named in the text.
Remove the body and keep continuation lines
Headers end at the blank line before the body. Use that header portion and retain leading whitespace on folded lines: the spaces before by and spf in these examples mark continuations. The input limit is 262,144 characters. Shared output may contain addresses, internal hostnames and IPs, so limit it to what is needed. Negative time differences or missing dates are clues about clocks, syntax or missing records, not conclusive proof of tampering.
Specifications and related reading
RFC 5321 §4.4: trace records; RFC 5322 §2.2.3: folded fields; RFC 8601 §2.2: Authentication-Results syntax. Continue with SPF, DKIM and DMARC alignment or the limits of IP address location.