Email Header Analyzer – Hop-by-Hop Relay Table | NetworkUstad

When an email arrives late, lands in spam, or looks suspicious, the evidence is in its headers: a chain of Received lines, each stamped by a server that handled the message, in reverse chronological order. Reading raw headers is painful, because the newest hop is listed first and the dates use an old format. This analyzer unfolds the headers, extracts each Received hop with its from and by hosts, and computes the delay between hops, so you can see where the message waited and where it flew. It also surfaces the From, Subject, and authentication results when present, giving the whole story in one table.

How to Use the Email Header Analyzer

1. Open the message in your mail client and copy its full headers.
2. Paste them into the input box.
3. Click Analyze.
4. Read the relay table from the last hop backwards to the origin.
5. Look for large delays, which mark the slow hop.
6. Compare the first Received host with the From domain for spoofing clues.

Key Features

• Unfolds wrapped header lines before parsing.
• Extracts from and by hosts from every Received line.
• Computes the delay between consecutive hops in minutes.
• Surfaces From, Subject, and authentication results when present.
• Handles missing or unparsable dates without failing the whole analysis.
• Runs entirely in the browser; headers are never uploaded.

What the Result Means

The table reads newest-first, because that is how mail servers append Received lines: the top hop is the server that delivered the message to you, and the bottom hop is closest to the sender. A delay of a few seconds between hops is normal; a delay of hours at one hop means the message queued there, which is the usual cause of late delivery. A mismatch between the earliest Received host and the claimed sender domain is a spoofing clue, not proof, but combined with a failed authentication result it is strong evidence the message should not be trusted.

Worked Example

A message sent at 09:58 arrives at 10:00, and the user complains it was late. The analyzer shows two hops: sender.example.org to mail.example.com at 09:58, then mail.example.com to the receiving server at 10:00, a delay of just 2 minutes, which is normal. The real cause turns out to be the client polling interval, not the mail path, and the table proves it in one glance instead of a long argument about server logs.

Best Practices and Tips

• Always read Received lines bottom-up to follow the message forward in time.
• Focus on the hop with the largest delay when diagnosing lateness.
• Check authentication results for SPF, DKIM, and DMARC passes or failures.
• Be wary of Received lines that were added by the sender: only your own server hops are fully trustworthy.
• Save the full headers when reporting phishing; the table alone loses evidence.

Common Mistakes to Avoid

• Reading the hops top-down and concluding the message travelled backwards.
• Trusting the earliest Received line, which the sender controls.
• Treating a small delay as a problem; seconds are normal.
• Deleting the headers after analysis instead of keeping them for the report.

Frequently Asked Questions

What is a Received header?

A stamp added by each mail server that handles a message, recording where it came from, where it went, and when.

Why are the hops in reverse order?

Because each server prepends its stamp to the top, so the most recent handler ends up first.

What delay is suspicious?

Hours at a single hop, or a message that arrives days after sending, usually points to a queue or a filtering delay.

Can headers be faked?

Yes, especially the earliest ones. Headers added by your own provider are the most reliable.

Related Tools

• Cookie Header Parser – Parse Cookie and Set-Cookie headers
• DMARC Record Builder – Build a DMARC policy record