What this analysis does
Paste a message header to reconstruct the server chain and identify the hop that consumed the most delivery time.
When someone reports that email is slow, the useful question is which hop introduced the delay. The Received chain already contains that answer; it is simply written in reverse order and in a format that resists quick reading. This view reconstructs the route in chronological order with the time spent at each stage.
Latency belongs to a hop, not to a message
Total transit time is rarely the useful number. A message that took eleven minutes end to end usually spent ten of them at a single intermediary while every other stage completed almost instantly. Attributing the delay to that specific system is what makes the report actionable.
Greylisting is the most common legitimate cause of a large single-hop gap. A receiver temporarily defers an unfamiliar sender, and the sending queue retries after a delay. That produces minutes of latency at one boundary and nothing anywhere else, which is a distinct signature from a general queue backlog.
- Read the chain from the oldest accepted hop upward.
- Compare per-hop gaps rather than only total transit time.
- A single large gap at one boundary usually indicates deferral, not congestion.
Clock skew and timezone noise
Each Received line carries the timestamp of the system that wrote it, and those systems do not share a clock. Small negative intervals are ordinary skew rather than evidence of tampering. Treat sub-minute anomalies as noise unless other evidence supports a different reading.
Timezone offsets are equally easy to misread. Normalizing every timestamp to a single reference before comparing is what makes the sequence meaningful, particularly when a message crossed systems on different continents.
Route changes are infrastructure evidence
The hostnames in the chain describe the path a message actually took, which is often more informative than the configuration people believe is in place. A route that traverses an unexpected relay, an appliance nobody documented or a forwarding service that was supposed to be retired is a finding in itself.
Comparing routes between a working and a failing message is the fastest way to isolate this class of problem. When two messages to the same recipient take different paths, the difference between those paths is the place to look.
Example: one slow boundary in an otherwise fast route
Evidence supplied
A five-hop chain where four hops complete within a second and one records a nine-minute gap.
How to read the result
The timeline attributes the delay to the single boundary responsible and reports the surrounding hops as normal. That points the investigation at deferral or queueing at that specific system rather than at general infrastructure performance.
Known limits
- Timestamps come from independent clocks, so small discrepancies are expected.
- Some systems omit or condense Received lines, producing an incomplete route.
- Hostnames in the chain are self-reported by each hop and are not independently verified.
Common questions
Why does the route look shorter than expected?
Not every system adds a Received line, and some infrastructure deliberately condenses internal hops. A short chain is common and not by itself suspicious.
Can I tell where a message really originated?
The oldest hop your trust boundary accepted is reliable. Lines below that were written by systems you do not control and can be fabricated.
Does a long transit time affect deliverability?
Not directly, but repeated deferrals often indicate a reputation or authentication condition that does affect placement.