Email header analyzer
Paste raw headers to diagnose routing delays and authentication evidence.
Your inputs
Your results
Ready when you areYour results will appear here.
How it works
Unfolds pasted email headers, extracts message details and reported SPF, DKIM and DMARC results, and displays Received hops with UTC timestamps and adjacent intervals. Repeated fields are retained. Learn how to retrieve headers: https://support.google.com/mail/answer/29436?hl=en. Compare the workflow with Google Admin Toolbox: https://toolbox.googleapps.com/apps/messageheader/.
A few things to know
Reported results are untrusted evidence, not a new authentication check. No network requests, DNS lookups, signature verification, geolocation, spam scoring or inbox guarantee. Timing requires four-digit years and numeric timezone offsets; unknown -0000 zones, named zones, leap seconds and invalid dates remain unknown. Encoded words are decoded with supported browser character sets; malformed or unsupported words remain raw. This is a practical header reader, not a complete RFC validator. Header data may include private addresses or infrastructure details.
When to use this tool
Original email headers contain routing history and receiver-reported authentication details that the normal message view hides. This analyzer unfolds header lines, extracts key fields and shows Received hops in chronological order with UTC timestamps where parsing is possible. Use it to organize a delivery investigation or compare reported domains. It reads supplied evidence; it does not authenticate the message again or determine whether its content is safe.
- Inspect reported SPF, DKIM and DMARC results from an original message.
- Compare recorded relay timestamps when investigating a delay.
- Decode a supported encoded subject and review sender-related fields.
How to use email header analyzer
Copy original headers
Retrieve the full header view from your email service and paste it into Original email headers. Preserve folded continuation lines. The message body after the first blank line is ignored; up to 500 KB is supported.
Inspect message and authentication fields
Review From, Return-Path, Message-ID and the reported Authentication-Results. Repeated fields are retained. Compare domains and note which receiving service claims to have added the authentication result.
Review the route cautiously
Read the hop table and adjacent UTC intervals. Unknown or invalid timestamps remain unknown. Treat negative intervals and missing hops as evidence limitations, and consult your receiving service or provider when additional logs are needed.
Read the sample relay interval
Inputs
Use the supplied headers with two Received lines: sender to relay at 13:00:00 +0100, then relay to inbox at 12:00:05 +0000 on 10 October 2026.
Result
The analyzer reads nine fields, two Received hops and one authentication report. The route interval is five seconds after timezone normalization. The encoded subject becomes Hello ✓.
What it means
13:00 +0100 is 12:00 UTC, so the recorded hops are five seconds apart. That interval is between recorded relays, not a measurement of the full time from composing the message to inbox display.
Common mistakes to avoid
Trusting every pasted authentication field
Headers can be forged or copied. A displayed pass is a reported claim; identify the trusted receiving service before treating it as meaningful evidence.
Reading Received lines top to bottom as travel order
New relays prepend headers, so original headers usually show newer hops first. The analyzer presents the recorded route oldest first to simplify comparison.
Calling the interval delivery time
Missing hops, clock differences and client processing affect the picture. The reported interval covers only parseable recorded hops rather than every stage of delivery.
Frequently asked questions
Definitions, edge cases, and practical next steps for this tool. Search all tool FAQs ↗
Where can I find the original headers?
Use your email service’s original-message or full-header option. In Gmail, the message menu includes Show original. Copy the headers rather than a screenshot or the ordinary From/To display, because routing and authentication fields are usually hidden in that simpler view.
Does an SPF pass here prove the sender is genuine?
No. The tool extracts a reported result from supplied text and does not run SPF. A result also needs domain and trust context. Compare the authenticated domain with other message fields and confirm the report was added by your trusted receiving service.
Does this verify DKIM signatures?
No. It can display reported DKIM results and signature-related context, but it does not fetch keys or cryptographically verify the message. A fresh signature check requires the original signed content and an appropriate verification workflow, beyond reading pasted headers.
Why is a hop timestamp unknown?
The supported parser expects a four-digit year and numeric timezone offset. Named zones, an unknown -0000 timezone, invalid dates and leap-second values remain unknown. Retaining that uncertainty is more useful than assigning a made-up UTC time.
How are timezone differences handled?
Supported numeric offsets are converted to UTC before adjacent intervals are calculated. A 13:00 timestamp at +0100 can precede a 12:00:05 timestamp at +0000 by five seconds. Clock errors can still affect the reported timeline even when the arithmetic is valid.
Why can From and Return-Path differ?
They are different message fields and may legitimately contain different addresses. The analyzer shows both without declaring the difference fraudulent. Use authentication alignment and your sending-service configuration to interpret them; the parser itself cannot verify who controls either address.
Can it detect spam, phishing or inbox placement?
No. It performs no spam scoring, geolocation, URL inspection or content-safety classification. Header structure and reported results can support an investigation, but they do not establish that a message is safe or explain every delivery decision.
Is header data sent to an external service?
This analyzer processes the pasted text locally and makes no DNS or network requests. Headers may still contain private addresses and infrastructure details, so consider those details before sharing a copied result or downloading it into a shared workspace.
Explore the topic in the blog
Sources and method
Use the references below to check definitions and platform guidance. The model’s scope and limits are explained above. Read our editorial standards.