Why the Received chain is read oldest-first

Each mail server that handles a message prepends its own Received header at the top of the stack, so the header block as stored has the newest hop first and the oldest hop — the message's actual origin — last. That's convenient for a mail server (each hop only needs to look at the top), but it's backwards for a human trying to trace how a message actually traveled from sender to inbox. This tool reverses the order specifically to match the real chronological path, so "hop 1" genuinely means the first server that touched the message, not the last one to add its header.

What hop timing gaps can and can't tell you

Each Received header carries its own timestamp, and the gap between consecutive hops is often diagnostic — a message that spent ninety seconds transiting one internal relay likely hit a queue or a scanning delay, while a two-hour gap between two hops in the same organization is worth investigating. But timestamps in Received headers are self-reported by whichever server wrote them, and a server with a badly skewed clock (or a deliberately falsified header, in a spoofing attempt) produces a gap that reflects that discrepancy rather than genuine transit time. Large or negative gaps are a signal worth looking at, not proof of anything on their own — this tool surfaces the data; interpreting it against what you know about the sending infrastructure is still a human judgment call.