📋 Email Header Analyzer

What This Tool Actually Shows You

Paste the raw header block from any email — not the message body, the headers — and this tool extracts the sender and recipient fields, reconstructs the full chain of mail servers the message passed through (the Received headers), calculates the time delay at each hop, and pulls out the SPF/DKIM/DMARC verdicts from the Authentication-Results header if one is present. Everything happens client-side in your browser; the header text you paste is never sent to any ToolsNovaHub server.

The one exception, and it's worth being upfront about: if a Received line includes a public IP address, this tool optionally looks up that IP's approximate location using a third-party geolocation API, purely to help you spot an unexpected origin country at a glance. That lookup sends only the bare IP address, never any other header content, to the geolocation provider.

Getting the Raw Headers Out of Gmail, Outlook, and Apple Mail

Every major email client hides raw headers behind a specific menu, since almost no one needs them day to day. In Gmail (web), open the message, click the three-dot menu in the top-right of the message pane, and choose "Show original" — this opens a new tab with the complete raw source, headers included, ready to copy. In Outlook (desktop), open the message, go to File → Properties, and the headers appear in the "Internet headers" box near the bottom of that dialog. In Outlook on the web, open the message, click the three-dot menu, and choose "View" → "View message source." On Apple Mail (macOS), open the message and choose View → Message → All Headers, or Raw Source for the complete text including the body.

Once you have the raw text, you can paste the entire thing (headers plus body) into the box above — this tool automatically stops parsing at the first blank line, which is exactly where headers end and the body begins in a properly formatted email, so there's no need to manually trim anything.

Reading the Delivery Path: Hops, Timestamps, and Delay

Each Received header represents one mail server accepting the message and passing it forward, and a typical message picks up somewhere between two and six of these depending on how many relays, forwarding rules, and security gateways it passes through. Reading the chain in chronological order (oldest to newest, which is what this tool displays) tells you the actual physical and organizational path the message traveled — starting from the sender's outgoing server, potentially through a bulk-mail provider or relay, and ending at whichever server finally delivered it into your inbox.

The delay between consecutive hops is often more revealing than the hops themselves. A message that sat for six hours between two servers, then arrived normally elsewhere, points to a specific bottleneck worth investigating — a queued mail server, a greylisting delay, or a busy relay. Consistently short delays (seconds, not minutes) across every hop generally indicate a healthy, uncongested delivery path. Occasional negative delays ("clock skew" in this tool's output) simply mean two servers' clocks weren't perfectly synchronized — common and rarely meaningful on its own, but worth noting if it appears alongside other suspicious signals.

Making Sense of SPF, DKIM, and DMARC at a Glance

The Authentication-Results header, when present, is added by the receiving mail server after it has already checked the message against the sending domain's published authentication policies, so it saves you from having to independently verify each one. A clean result shows all three as pass: SPF confirms the sending server's IP was authorized by the domain's SPF record, DKIM confirms the message body wasn't altered in transit and was cryptographically signed by the claimed domain, and DMARC confirms the domain's overall policy (which of SPF/DKIM must align, and what to do on failure) was satisfied.

A single failure isn't automatically damning — legitimate forwarding, mailing list processing, or a recently changed sending infrastructure can all cause a genuine sender to fail SPF or DKIM without malicious intent. What deserves real scrutiny is a DMARC failure combined with a visible mismatch between the From address and the Return-Path, which this tool flags automatically when both are present in the pasted headers, since that combination is exactly the pattern a spoofed sender produces and a legitimate misconfiguration rarely does. If you manage the sending domain yourself, our DMARC Record Generator can help you set the right policy so failures like this get reported back to you directly.

Spotting a Mismatched From, Return-Path, or Reply-To

Three address fields matter beyond the visible "From" name your inbox displays: the actual From address, the Return-Path (where bounce notifications go, often revealing the true sending infrastructure), and Reply-To (where your reply actually goes, if different from From). A mismatch between From and Return-Path domains is common and often entirely legitimate — most bulk email providers, newsletter platforms, and CRM tools send on a client's behalf from their own infrastructure while keeping the client's domain in the visible From field.

A Reply-To address that quietly redirects to a completely different domain than the visible sender, though, deserves more attention — it's a specific, low-effort technique that shows up disproportionately often in phishing attempts, since it lets an attacker spoof a trusted-looking From address while still receiving any reply a fooled recipient sends. This tool highlights both mismatches automatically whenever they're present, so you don't have to manually compare three separate header values by eye. For a deeper look at the sending domain itself, our WHOIS Lookup tool can show you exactly how recently that domain was registered — a very young domain claiming to be an established brand is a strong additional signal.

Automated Analysis vs Reading Raw Headers by Eye

Real Scenarios This Tool Is Actually Used For

A finance team member receives an unexpected invoice email that looks legitimate but wasn't expected. Pasting the headers here quickly shows whether SPF/DKIM/DMARC actually passed for the claimed sending domain, and whether the Return-Path traces back to infrastructure that has nothing to do with the claimed vendor.

A message claiming to be from a bank lands in the inbox instead of spam, which feels reassuring but isn't proof of legitimacy on its own. Checking the actual Authentication-Results and the delivery path's originating server against the bank's known infrastructure gives a far more concrete answer than the spam filter's placement decision alone.

A small business debugging why its own transactional emails (order confirmations, password resets) are arriving late complains about a diagnosed spam-folder problem when the real issue is a slow hop somewhere in their email service provider's own relay chain. The hop-by-hop delay breakdown pinpoints exactly which leg of the journey is the bottleneck, rather than guessing — and running our SMTP Tester against their own outgoing server can confirm whether the delay originates on their side or further downstream.

A job seeker receives an unusually generous remote-work offer after minimal interviewing, a well-known scam pattern. Comparing the sending domain in the headers against the company's actual known domain, and checking whether DMARC passed for that claimed domain, often surfaces a completely unrelated sending infrastructure within seconds.

Header Fields Worth Recognizing

What Header Analysis Can and Can't Tell You

Header analysis is a genuinely strong signal, but it isn't a verdict on its own. A message can pass SPF, DKIM, and DMARC perfectly while still being a scam — authentication only proves the message actually came from the domain it claims to, not that the domain or its content is trustworthy. Attackers who register a convincingly similar look-alike domain (support-yourbank-secure.com instead of yourbank.com, for instance) can pass every authentication check while still being entirely fraudulent, because the checks validate the domain in the header, not whether that domain deserves your trust.

Equally, a legitimate email can occasionally show an authentication failure due to forwarding through a mailing list, a corporate mail gateway rewriting headers, or a recently migrated email provider that hasn't finished propagating DNS changes — none of which indicate anything malicious. Treat header analysis as one strong input alongside the message's actual content, the domain's plausibility, and whether you were expecting it at all, rather than a single automated pass/fail answer.

What Happens to the Headers You Paste

Header parsing, timestamp calculation, and authentication-result extraction all run entirely in your browser using JavaScript — the header text itself is never transmitted to any ToolsNovaHub server or stored anywhere. The only network activity this tool performs is an optional per-IP geolocation lookup for public IP addresses found in the Received chain, sent directly to a third-party IP geolocation API, and that request contains only the bare IP address, nothing else from the pasted headers. If you'd rather skip that lookup entirely, the delivery path table and every other section still work fully without it — the IP address itself is always shown regardless.

This client-side approach also means there's no artificial limit tied to server load or rate limiting — you can analyze as many messages, one at a time, as you need, and nothing about your usage pattern is logged beyond standard, anonymized page-view analytics that apply to every page on this site equally.

FAQ

🔗 Related Tools & Guides