Email Forensics - Free Online .eml Header, Authentication & Attachment Analyzer
Email Forensics
Load a raw .eml file or an Outlook .msg to reconstruct its delivery chain, verify its DKIM body hash offline, and check its attachments, archives and links - without uploading anything.
Drop a .eml or .msg file here
or click to browse from your device
Choose messageMessage Overview
The envelope fields this message declares, and what stands out about it.
Header Chain
Every Received: header, reconstructed in the order the message actually traveled, and plotted on a shared time axis above so a long hop or an out-of-order timestamp is visible at a glance.
Authentication
This tool can only display and interpret the Authentication-Results header a receiving mail server already stamped - it cannot query DNS to independently re-verify SPF, DKIM or DMARC. An all-pass result is only trustworthy if it was stamped by your own mail infrastructure; a header added by an untrusted intermediate hop proves nothing. The one exception is the DKIM body hash, which is recomputed here from the message itself - see the panel below for exactly what a match does and does not prove.
Headers
Every header exactly as stored, and the same list decoded and flagged for anything unusual, such as a duplicated From or Subject.
Body & Links
The HTML body is shown inside a sandboxed, script-disabled frame, and remote images or resources it references are never loaded - only counted.
Attachments
Every attached file, its declared type versus what its own bytes actually are, a SHA-256 hash, and any double-extension trick. Archive attachments are opened and their contents get the same checks, without anything inside ever being executed.
Sender Analysis
Display-name and address checks, plus a heuristic-only look at the sending domain for internationalized (punycode) labels and visually-confusable characters.
Strings
Printable text found anywhere in the raw file.
--
Raw Source
The complete raw .eml source, exactly as read from the file.
Understanding Email Header Forensics
What the Received Chain Actually Shows
Every mail server that handles a message prepends its own Received: header before passing the message along, so the raw source ends up with the most recent hop listed first. Reading that chain in the order the message actually traveled - oldest hop to newest - reconstructs the real delivery path: which server it left from, which servers relayed it, and roughly how long each hop took. A hop with a timestamp earlier than the one before it, or a multi-hour gap where none is expected, is a lead worth investigating, not proof on its own - clock skew between servers is common and mundane.
Why Authentication Results Can't Be Re-Verified Here
SPF, DKIM and DMARC all depend on DNS lookups against the sending domain's published records at the time the message was delivered. A browser page has no way to perform that lookup after the fact, and even if it could, the records may have changed since. What this tool can do is read the Authentication-Results header your own mail server already stamped, and explain what it says. That header is only meaningful if you trust the infrastructure that added it - an attacker who controls an earlier hop can add a fake header claiming everything passed.
Why the HTML Body Runs in a Sandbox
An HTML email is, functionally, an untrusted web page someone else wrote. This tool renders it inside an iframe with every sandbox permission turned off - no scripts, no same-origin access, no form submission, no popups - after also stripping script/style tags, event-handler attributes and javascript: links from the markup itself. Remote images and other externally-hosted resources referenced in the HTML are never fetched: loading them would silently confirm to whoever sent the message that it was opened, which is exactly what a tracking pixel is for.
100% Private, In-Browser
Header parsing, MIME decoding, authentication interpretation and attachment hashing all run locally in your browser. The message is never uploaded anywhere. That matters here more than almost anywhere else on this site: the emails people most want to check are the ones that look like phishing, invoicing fraud or account compromise - exactly the messages that should not be forwarded to a third-party server to get an answer.
Indicators, Not Proof
Everything on this page describes what is stored in the file, which is not the same as intent. A missing Authentication-Results header can mean a message was never checked by any server you trust, or simply that it was sent from a mailbox that doesn't perform those checks. A punycode domain can be a perfectly legitimate internationalized business name. A mismatched Reply-To is standard practice for many mailing lists and support systems. Treat every finding here as a lead to corroborate against the full context - who the message is from, what it's asking for, and whether it matches how that sender normally communicates - and where the stakes are high, involve someone qualified rather than relying on a single automated read.
Key Takeaways
- The delivery chain is reconstructed, not guessed: every Received: header is parsed and placed in the order the message actually traveled.
- Authentication results are reported, never re-verified: SPF/DKIM/DMARC checks require live DNS, which this page deliberately does not perform.
- The HTML body can never run code: it is sanitized, then rendered in a fully sandboxed frame with scripting disabled.
- Remote images are never loaded: tracking-pixel-style resources are counted and reported, not fetched.
- Nothing leaves your device: every parse, hash and check runs client-side in your browser.