OSINT Email Header Analyzer Free

It doesn't need to. When the email was originally delivered, the receiving mail server (e.g., Gmail or Outlook) already performed the DNS lookups, verified the cryptographic signatures, and recorded the results in the "Authentication-Results" header. This tool reads those pre-computed verdicts directly from the headers you provided. No live DNS queries or external verification is required — everything you need is already embedded in the headers.

Yes — your email headers never leave your device. Whether you paste headers, drag & drop an .eml file, or browse to upload, all parsing, scoring, and analysis runs entirely in your browser using JavaScript. Nothing is sent to any server, and nothing is stored or logged. You can verify this yourself: open your browser's Developer Tools (F12), go to the Network tab, then analyze some headers. You'll see zero network requests. This makes the tool safe to use with sensitive investigation data, even in air-gapped environments.

Yes. Since all processing is 100% client-side, your headers stay on your device. It's worth knowing that email headers contain routing metadata (server names, IP addresses, timestamps) but never the email body or attachments. You can also disconnect from the internet after loading the page — the tool works identically offline.

You can upload .eml files (standard email format exported from Gmail, Thunderbird, Apple Mail, and others), .txt files containing raw header text, and .msg files (Microsoft Outlook format). You can either drag & drop files directly onto the upload area or click "Browse Files" to select them. For .eml files, the tool automatically strips the message body and analyzes only the headers.

Email headers reveal the servers the email passed through, the sender's IP address (sometimes), the email client and operating system used, authentication results (SPF, DKIM, DMARC), and timing information. For OSINT investigations, this can help identify the true origin of an email, detect spoofing attempts, profile the sender's technical environment, and provide leads for further investigation.

Look for failed SPF, DKIM, or DMARC checks, mismatches between the From address and Return-Path, suspicious Reply-To addresses pointing to different domains, and display name spoofing (where the display name contains a fake email). Our spoofing risk score automatically evaluates ten weighted factors — including typosquatting/look-alike domain detection and thread authenticity verification — and gives you a single confidence rating from 0 to 100, with a plain-English explanation for each factor.

SPF (Sender Policy Framework) checks if the sending server is authorized to send for the claimed domain — like checking if a letter carrier's badge is valid. DKIM (DomainKeys Identified Mail) uses a cryptographic signature to verify the email hasn't been tampered with in transit — like a wax seal on an envelope. DMARC (Domain-based Message Authentication) ties SPF and DKIM together and tells receiving servers what to do when checks fail (accept, quarantine, or reject). Together, they form the standard for verifying a sender's identity.

Some headers can be forged by the sender, particularly the "From" and "Reply-To" fields. However, "Received" headers added by intermediate servers are much harder to fake since each server in the chain appends its own. The Authentication-Results header is especially trustworthy because it's computed by the receiving server — the sender cannot control what it says. Our header completeness check will flag any missing critical headers that might indicate tampering or truncation.

X-headers are non-standard headers added by mail clients and servers. They can reveal the email client and version (X-Mailer), the sender's IP (X-Originating-IP), the email provider (X-Google-DKIM-Signature, X-MS-Exchange-*), and spam assessment scores. This metadata can be invaluable for profiling the sender's environment and corroborating other evidence.

Click any IP address in the hop timeline or IP intelligence table to automatically open our IP Lookup tool in a new tab with that IP pre-filled and searched. Use "Investigate All IPs" to look up every public IP found in the headers at once. This gives you geolocation, ISP, and network details for each server in the delivery chain — all without leaving your analysis.

Most email header analysis tools are built for IT administrators troubleshooting deliverability. This tool is purpose-built for OSINT and cybersecurity investigators. Key differences: (1) Composite spoofing risk scoring (0-100) with ten weighted factors including typosquatting detection and thread authenticity — not just raw pass/fail. (2) Visual hop-by-hop timeline with delay visualization and anomaly detection. (3) Automatic IP extraction with one-click geolocation lookup via our IP Lookup tool. (4) Campaign analysis mode — compare multiple emails to identify shared infrastructure, common IPs, and coordinated phishing campaigns. (5) Full JSON export of structured analysis data for integration with SIEM, ticketing, or OSINT platforms. (6) Sender profiling from X-headers (email client, OS, provider detection). (7) Defanged IOC export for safe sharing in reports and ticketing systems. (8) SHA-256 evidence hashing for chain-of-custody documentation. (9) RFC 2047 encoded display name decoding and thread header (In-Reply-To/References) parsing. (10) 100% client-side — no data ever leaves your browser, making it safe for sensitive investigations. Other tools send your headers to their servers for processing.

Yes. Once the page has loaded in your browser, you can disconnect from the internet and the tool works identically. All analysis — header parsing, spoofing scoring, authentication checking, IP extraction, and timeline rendering — runs entirely in your browser. This makes it suitable for air-gapped forensic workstations and environments where sensitive data must not leave the network.

If the original receiving server didn't include an Authentication-Results header — or if the email was forwarded in a way that stripped those headers — this tool will have less data to work with and will flag the missing information as a header completeness warning. However, the spoofing risk score also evaluates non-authentication signals like Reply-To mismatches, Return-Path discrepancies, display name tricks, typosquatting/look-alike domain detection, thread authenticity (Re:/Fwd: without threading metadata), and routing anomalies, so it can still flag suspicious emails even without authentication headers.

Campaign Analysis mode lets you paste headers from multiple emails and analyze them together to identify shared infrastructure. It finds common IP addresses, shared routing domains, and consistent patterns across a set of phishing or spam samples. Use it when you receive multiple suspicious emails and want to determine if they originate from the same attacker or infrastructure — shared sending IPs and routing domains are strong indicators of coordinated campaigns.

The "Export JSON" button downloads the complete analysis as a structured JSON file. It includes the message summary, spoofing risk assessment (with all factor scores), authentication results, hop details, extracted IPs, IOCs, and sender profile. This structured format is designed for integration with SIEM platforms, incident response ticketing systems, threat intelligence databases, or custom OSINT workflows. You can also use it to archive analysis results for case documentation.

The spoofing risk score includes a "Look-alike Domain" check that detects typosquatting — when an attacker registers a domain that looks nearly identical to a trusted brand (e.g., "gmai1.com" instead of "gmail.com"). It uses three techniques: (1) a database of known typosquat patterns for major email providers, (2) Levenshtein distance to catch single-character substitutions, and (3) confusable character normalization (e.g., "rn" looks like "m", "0" looks like "o", "1" looks like "l"). If the From domain closely resembles a well-known domain, it will be flagged.

In-Reply-To and References are threading headers defined in RFC 5322. They contain Message-IDs of earlier emails in a conversation thread. Legitimate replies always include these headers, so if an email has a Subject starting with "Re:" or "Fwd:" but no In-Reply-To or References header, it was likely fabricated to look like part of an existing conversation — a social engineering technique. This tool automatically checks for this mismatch as part of the spoofing risk score.

When you analyze headers, the tool generates a SHA-256 cryptographic hash — a unique fingerprint of the exact text that was analyzed. Record this hash in your case notes alongside the timestamp. If the same headers are re-analyzed later and produce a different hash, the input was modified. This helps establish that the evidence you documented matches what was originally examined. For best results, upload the original .eml file rather than pasting text, since copy-paste can inadvertently alter whitespace or encoding.