Reading Received headers from bottom to top is often taught as the way to follow a message's route. That ordering can explain chronology, but it does not authenticate the oldest entry. A sender can place invented trace fields in a message before the first trusted receiver handles it. Start by finding the receiving boundary you can substantiate.
Understand how trace is added
SMTP systems prepend Received trace information as messages pass through them. The newest entry is therefore normally closest to the top. A field can record the receiving system, claimed sending host, connection information, protocol, queue identifier and time. Not every implementation includes the same optional detail. RFC 5321 section 4.4.
The connecting IP observed by a trusted receiver is different evidence from a client-supplied EHLO/HELO name or a hostname copied into lower headers. Preserve those distinctions rather than displaying every name as a verified physical hop. A private address or an internal hostname can describe a legitimate internal segment without being publicly resolvable.
Establish the trustworthy segment first
Begin with the final receiving system and work backward through systems whose operation and logs are known. Identify the point where the message entered from outside that boundary. Correlate the trusted field's queue identifier, connection record and timestamp with server logs. If a gateway is operated by a third party, use authorized evidence from that gateway rather than assuming the entire chain is trusted because the last receiver accepted it.
Older fields below the boundary remain claims unless corroborated. A valid later DKIM result does not automatically establish every earlier network hop, and a familiar domain in an untrusted trace line is not proof the message traversed that organization.
Reconstruct a hypothetical three-entry chain
Suppose the top Received field identifies an internal relay at 10:05 UTC, the next identifies the perimeter gateway at 10:03 UTC, and the oldest claims a bank host at 09:58 UTC. Authorized logs corroborate the two internal handling events and the peer address observed at the perimeter. No evidence corroborates the bank claim.
The supported route reaches back to the perimeter's observed peer, then stops. The familiar bank name remains supplied text. Even the two-minute difference between internal timestamps is only an apparent interval until clock accuracy and queue records are checked; it does not by itself assign a delay to a server.
These are invented field and log assumptions, not a measured route or executed parser. In an actual incident, preserve which evidence supports each hop and ask the relevant administrator for missing records rather than turning the lowest line into proof of origin.
Use timing cautiously
Convert timestamps to a consistent timezone while retaining originals. Clocks can be wrong, and a timestamp in an untrusted field may be invented. A negative interval or long gap is a lead to investigate, not proof of tampering or the exact location of a delay. Queue logs can distinguish waiting time from clock discrepancies.
Close with a route diagram or short ordered list that labels each hop as observed, corroborated or claimed. Identify the last reliable boundary, any unexplained timing and what additional source would resolve it. Do not turn the apparent originating IP into a person's identity or geographic certainty.
Build a bounded route record
- Start with the final receiver you can substantiate.
- Match each trusted hop to queue and connection records.
- Keep sender-claimed names separate from observed peer addresses.
- Retain original timezone values and investigate clock differences before assigning delay.
- Stop at the uncorroborated boundary; identify the log source needed to continue.