World’s largest virtual agentic engineering & quality conference
Paste raw email headers to trace delivery hops, extract sender IPs, and read the SPF, DKIM, and DMARC verdicts the receiving server already recorded. The tool is developed by TestMu AI (formerly LambdaTest) and is completely free to use.
An email header analyzer is a browser-based tool that parses the raw header block of an email message, defined by RFC 5322, to reconstruct its delivery path. It unfolds wrapped header lines, walks each "Received:" trace field hop by hop, and surfaces the SPF, DKIM, and DMARC verdicts the receiving server already recorded.
The raw header block is the part of an email a normal inbox view hides: every server the message passed through, the exact timestamps at each hop, the sender's originating IP address, and the machine-readable authentication verdicts. Reading it is the standard first step in diagnosing delivery delays, tracing a message's real source, or investigating a suspected phishing attempt. See the SPF Record Checker and DMARC Record Checker for checking a domain's published policy rather than a specific message's headers.
The tool first unfolds the pasted text: RFC 5322 section 2.2.3 allows a header field to wrap onto indented continuation lines, and those line breaks are removed before anything else runs. It then splits the block into individual header fields, extracts every "Received:" line in order, and parses each one for its from, by, with, id, and timestamp tokens.
Consecutive hop timestamps are diffed to compute the delay at each step and the total transit time. Sender IPs are pulled from the bracketed literal in the from field (both IPv4 [203.0.113.10] and IPv6 [2001:db8::1] forms). Finally, the tool reads any Authentication-Results header, defined by RFC 8601, lists the SPF, DKIM, and DMARC results it already contains, and pulls each verdict's ptype.property context (the IP an SPF check matched, or the domain a DKIM/DMARC check validated) from the same header field.
The Header Completeness Check runs against the same parsed field list: it looks for Message-ID, Date, Return-Path, Received-SPF, DKIM-Signature, Authentication-Results, and MIME-Version, and reports which ones are present. This is a completeness check on the pasted text, not a spoofing signal by itself, plenty of legitimate mail omits Received-SPF or MIME-Version.
Important: this tool does not perform its own SPF, DKIM, or DMARC verification. Doing that correctly requires querying DNS as the receiving mail server saw it at delivery time, which a browser cannot replicate after the fact. Instead, it displays the verdicts the receiving server already computed and stamped into the header, exactly as every major header analyzer does.
This page is built in two explicit tiers, and the widget tells you which one you are using:
There is no blacklist or spam-score check on this page. A real DNSBL check like Spamhaus blocks queries relayed through public DNS-over-HTTPS resolvers, so a browser-only tool cannot run one reliably, see the FAQ below for why.
These three mechanisms work together to authenticate a message, and this tool displays whatever the receiving server already decided for each one:
All processing on this page, including the hop trace, delay math, and Authentication-Results parsing, happens entirely in your browser. Nothing is uploaded unless you explicitly click the "Look up IP" button. Testing automated notification flows from your own QA pipelines pairs naturally with TestMu AI HyperExecute for orchestrating those jobs and TestMu AI Test Manager for tracking the results.
An email header analyzer is a tool that parses the raw RFC 5322 header block of an email message, in particular its Received: trace fields, to reconstruct the hops a message took, the delay between each hop, the sender's originating IP address, and the SPF, DKIM, and DMARC verdicts the receiving mail server already recorded.
This tool only displays results. It reads the Authentication-Results header (RFC 8601) that the receiving mail server already stamped onto the message and shows the SPF, DKIM, and DMARC verdicts found there. It does not query DNS or re-run authentication checks itself.
In Gmail, open the message, click the three-dot menu, and choose Show original. In Outlook, open File, then Properties, and read the Internet headers box. In Apple Mail, use View, Message, then All Headers. Copy the full block, including every Received: line, into this tool.
Each Received: header is stamped by one mail server as a message passes through it, recording which host it received the message from (from), which server processed it (by), the protocol used (with), an optional message ID, and a timestamp. Reading them in order reconstructs the delivery path.
Reverse DNS, IP geolocation, and RDAP ownership lookups are not derivable from the header text alone; they require querying public DNS-over-HTTPS resolvers, an IP geolocation API, and RDAP registries. These lookups are opt-in: nothing is sent until you click Look up IP for a specific hop.
It flags common spoofing indicators derived from the pasted text: a From-domain and Return-Path-domain mismatch, a missing Authentication-Results header, and any SPF, DKIM, or DMARC verdict of fail or softfail. These are heuristics, not proof; legitimate mail can trigger the mismatch warning too.
No. Header parsing, hop reconstruction, delay calculation, and the spoofing heuristics all run locally in your browser's JavaScript. Nothing is uploaded unless you explicitly click the Look up IP button, which sends only that single IP address to the named third-party services.
Spamhaus, the most widely used DNSBL, blocks queries relayed through public DNS-over-HTTPS resolvers, so a real blacklist check requires a backend with its own resolver. This tool is client-side only with no backend of its own, so a blacklist check is not offered rather than shipped as a broken or fake one.
Did you find this page helpful?
TestMu AI forEnterprise
Get access to solutions built on Enterprise
grade security, privacy, & compliance