Reading Received Headers — Reconstructing an Email's Path

The record of the journey

Every mail server that accepts a message prepends a Received: header. Because lines are always added at the top, the last step appears first and the first one at the very bottom. So the chain is read bottom to top — the most common confusion on a first look at a header.

A line normally holds four pieces of information: which host the message came from (from, with HELO name and resolved IP), which server accepted it (by), over what kind of connection (with, e.g. ESMTPS) and when (the timestamp at the end).

What AnalyzeMy.Email checks

• The complete chain — every hop broken out individually, in the correct reading order.
• The actually sending IP — taken from the first Received header carrying a public IPv4 address. Private ranges such as 10.x, 192.168.x and 172.16.x are skipped, because they are internal waypoints.
• Encryption per hop — ESMTPS indicates a TLS leg, ESMTP without the S means plaintext. The report marks every transition separately.
• TLS details of the final leg — version, cipher and key strength, read from the header our own server wrote.
• Timestamps and delays — the gap between two hops shows where a message sat waiting.

Where the information becomes reliable

This is the point the whole analysis rests on: Received headers are plain text and trivially forged. A sender can attach any number of invented Received lines to their message, claiming an entirely different origin.

Only what your own infrastructure added is trustworthy — that is, the lines from the first server you control upwards. Everything below that is the sender's assertion. That is why the report reads TLS information exclusively from the header carrying our own server name, and ignores whatever the lines further down claim about encryption.

The practical consequence: a chain that is very long at the bottom and claims many exotic waypoints is not evidence of a long journey — it is frequently an attempt to obscure the real origin. The first hop with a public IP above the trust boundary is the address SPF is checked against and the one that appears in blacklists.

What you typically find

• A hop without ESMTPS in the middle of an otherwise encrypted chain — usually a gateway or virus scanner passing the message on internally in the clear.
• Large time jumps between two lines — greylisting, a full queue, or a server that was temporarily unreachable.
• HELO name not matching the IP — a reputation problem that is checked in its own right.
• Timestamps out of order — usually a badly set clock, occasionally a line inserted after the fact.