Email Header Analyzer & Hop Timeline
Paste the message headers to build a delivery timeline. Reported authentication results are read from the text, not independently verified.
Runs locally in your browserLocal processing ·
Paste the message headers to build a delivery timeline. Reported authentication results are read from the text, not independently verified.
Runs locally in your browserPaste the header block of a message — the text behind “Show original” in Gmail, “View message source” in Outlook or “All Headers” in Apple Mail — into the box and press Analyze locally. The workbench lists every Received line as one hop, puts the time between consecutive hops in the Delay column, and reads the authentication results the message itself reports.
Everything is parsed in the tab: no request is sent, nothing is stored and the headers never leave your device. That is also the limit of the answer. VoriTools prints what the headers say; it does not contact a mail server, look up DNS records or verify a signature.
Every mail server inserts its own Received line at the top of the message, so the block is ordered newest first: the Received line closest to the body was written by the first server that handled the message, and the top line was written by the server that handed it to the mailbox. The analyzer reads the block bottom-up, which is why hop 1 is the oldest and the last row is the delivery into the mailbox.
Delay is the difference between two timestamps, and each timestamp comes from the clock of the server that wrote it, in that server’s own timezone. A long delay means the message waited somewhere — a greylisting server, a spam filter, a retry queue — so the panel flags the hop, not the reason. Delays over five minutes (300 s) become findings, and a hop whose timestamp is earlier than the hop before it is reported as timestamps running backwards: that is a clock that is behind, not a negative delay.
The summary is a reading of the header text, not a verification. Every mechanism=result pair is listed in order, bestguesspass is shown as written and not treated as a failure, and neutral or none stay unflagged. fail, softfail, temperror and permerror are repeated in the findings with the mechanism that reported them.
The same mechanism is often listed more than once: a message that passed through a mailing list carries a signature from the list and one from the sender, so a dkim=pass can sit next to a dkim=fail. Results that an intermediary recorded in ARC-Authentication-Results are tagged ARC and shown next to the receiving server’s own results; if only ARC results exist the panel says so, because they were not produced by the provider that received the message. Confirming any of it still means checking the DKIM selector, the SPF record or the DMARC policy with a DNS tool.
Findings cover a missing Message-ID or Date header, a Reply-To domain that differs from the From domain, delayed hops and timestamps that run backwards. A missing Authentication-Results header is reported differently from a header that exists but holds no SPF, DKIM, DMARC or ARC result, and text that contains no header lines at all gets one clear error instead of a list of missing fields.
Two limits are worth knowing. Headers are text the sender controls, so a forged header block is displayed exactly as written and a pass line proves nothing by itself. And only the header block is read — the first empty line ends it — so X-Received and other trace headers with a different name are not hops, and an older header block quoted inside the body of a forwarded message contributes nothing.