Analyse email headers
Every header analyser online works the same way: you paste a message's headers into a form, they go to a server, and a verdict comes back. The headers of a message are not neutral data — they contain who wrote to whom, when, through which servers, and often the subject. Pasting them into a form is the thing you were trying to investigate a message about in the first place.
This one does the same analysis without the form. Drop the file, or paste the headers, and everything is parsed here: the Received chain laid out oldest-first with the delay at each hop, the authentication results each relay recorded, the disagreements between From, Sender, Reply-To and Return-Path, display names containing a different address, domains built from look-alike characters, executable and double-extension attachments, and every external resource the body would have fetched.
Nothing is looked up. There is no DNS query, no reputation service and no live DKIM verification, because each of those would mean telling a third party which domain you are investigating. Every finding here is derived from the message itself and says what it is based on.
- 1.Drop an .eml or .msg file, or paste a header block into the box.
- 2.Read the delivery chain, the authentication results and the findings — each with the evidence it was drawn from.
- 3.Cross-check against the raw headers, shown in file order with their decoded values alongside.
Drop email files here
Built for .eml, .msg, .mbox. Nothing is uploaded — the file is read by code running in this tab.
In most mail clients this is “Show original”, “View source” or “Message details”. Paste the whole thing — headers alone are enough, and the body is fine too. Nothing is sent anywhere; it is parsed in this tab.
What this page cannot do
- Authentication results are read, not verified. If a relay wrote "dkim=pass" this shows that it did; it does not re-check the signature, because doing that needs a DNS lookup for the signing domain's public key. A forged Authentication-Results header added by an attacker before the message reached your own mail server would be reported as what it claims to be — which is why the panel shows which server wrote each result.
- No IP address is geolocated and no domain is checked against a blocklist. Both are network calls, and neither happens here.
- A .msg composed in Outlook and never transmitted has no delivery chain to analyse. The analyser says so rather than showing an empty section.
- Findings are signals, not verdicts. A Reply-To at a different domain is normal for a support desk and is also how business-email-compromise works; the explanation for each finding says which ambiguity applies.
If it did not work
- There are no authentication results.
- Why: No relay that handled the message recorded any.
- Try: That is reported as an absence, not a failure. It is normal for messages you sent yourself and for mail from servers that do not check.
- The received chain has gaps in the timing.
- Why: Not every relay writes a timestamp, and the ones that do use their own clocks.
- Try: Hops with no timestamp show no delay rather than an interpolated one. Large negative delays mean two relays disagreed about the time.
Questions
Is my email actually uploaded anywhere?
No. There is no server here that accepts a file. The page's Content-Security-Policy sets connect-src to 'self', so the browser itself refuses any request to another origin, and form-action is 'none' so nothing can be submitted anywhere. The only network requests this site makes are for its own JavaScript, its own font files, and the Vercel page-view counter — which records that a page was viewed and nothing about what you opened. You can confirm all of it in your browser's network panel with the page open.
Can it tell me whether an email is a phishing attempt?
It can tell you what the message contains and where it disagrees with itself, which is most of what an analyst actually looks at: whether the display name matches the address, whether the domain uses look-alike characters, whether the authentication results pass, whether replies would go somewhere else, what the delivery path was, and what the body would have fetched. It will not give you a score, because a score computed from the message alone would be a guess dressed as an answer.
How is this different from pasting headers into an online analyser?
The analysis is comparable. The difference is that nothing leaves the tab: the site has no endpoint that accepts a message, and its Content-Security-Policy blocks off-origin requests so a regression could not introduce one silently.
Does it check SPF and DKIM itself?
No, and it says so wherever it shows a result. Verifying either requires a DNS lookup, which would mean sending the sender's domain to a resolver you did not choose. What it does instead is show which server recorded each result, so you can judge how much to trust it.
Related
- Open EML files — Open .eml email files in your browser with remote content blocked, full header analysis, attachment extraction and SHA-256 hashes. Nothing is uploaded.
- Open Outlook MSG files — Open .msg files from Outlook in your browser: body, HTML, recipients, dates, attachments and embedded messages, read from the real Compound File structure. Nothing is uploaded.
- Convert EML to PDF — Convert .eml email files to PDF without uploading them. Headers, body text, reply chains and a full attachment index with SHA-256 hashes, laid out on real pages — entirely in your browser.