What email headers actually are
Every email arrives with two parts: the body (what you read) and the headers (the metadata around it). Headers carry the envelope (From, To, Subject, Date), routing information (every server that handled the message), and authentication results (whether the sender domain's SPF / DKIM / DMARC checked out). Most mail clients hide them by default because they're long and unfriendly, but they contain almost everything you'd want to know to diagnose a problem with the message.
Where to get the raw headers
- Gmail: open the message → three-dot menu (top right of message) → Show original. Copy the entire block above the body.
- Outlook (web): open the message → ⋯ menu → View message source.
- Outlook (desktop): File → Properties → Internet headers text box.
- Apple Mail: View → Message → Raw Source (⌥⌘U).
- Thunderbird: View → Headers → All, or Ctrl-U for full source.
The four things this tool surfaces
1. The envelope
From, To, Subject, Date, Reply-To, Return-Path, Message-ID. The basic who-sent-it-to-whom-and-when. The tool flags when Reply-To or Return-Path use a different domain from From — sometimes legitimate (mail sent through marketing platforms uses bouncing addresses on the platform's domain), sometimes a phishing tell.
2. Authentication results
The Authentication-Results header is what the receiving server records about its anti-spoofing checks. SPF / DKIM / DMARC each get a pass / fail / neutral status. Pass on all three is the strongest signal of authentic mail. Fails (especially DMARC fails) are the strongest signal of a spoof attempt — though forwarders and mailing lists can legitimately cause SPF fails on transit.
3. Received chain (journey)
Every mail server that handles the message prepends a Received header before forwarding. Read top-down they go newest-first; the tool reverses them into chronological order so you can read the journey as the message actually traveled. Each hop shows the "from" server (where it came from), the "by" server (where it arrived), the protocol used, the server-assigned message id, and the timestamp.
Long gaps between hops indicate a delay (often a downstream server was rate-limiting). A hop where the "from" IP doesn't match any known authorized sender is the spot to look for spoofing. Many legitimate setups have 3-5 hops (origin → outbound MTA → optional relay → receiving MTA → spam filter → final mailbox).
4. Mismatch flags
The tool highlights five common red flags:
- Reply-To ≠ From domain — could be legitimate (use this inbox for replies), often phishing.
- Return-Path ≠ From domain — usually a marketing platform (Mailchimp, SendGrid), occasionally suspicious.
- SPF fail / softfail — sending IP not authorized.
- DMARC fail — neither SPF nor DKIM aligned with From.
- Display name implies a person but address is generic ("John Smith <noreply@…>") — sometimes a friendly-from from a SaaS, sometimes spoof.
What this is NOT
This tool only analyzes headers. It does not:
- Open or render the message body (you paste only headers).
- Scan attachments — there are no attachments in the input.
- Send the headers anywhere — pure client-side parsing.
- Look up the sender domain's SPF / DKIM / DMARC records — for that, use the email auth checker.
Privacy
The text you paste is processed entirely in your browser. No fetch calls, no telemetry, no logging. Open your browser's DevTools → Network tab and confirm for yourself.
Adjacent tools
- Email auth checker — query a domain's SPF, DKIM, and DMARC records.
- IP reputation — check whether a sending IP is on any major blocklist.
- DNS lookup — query MX, TXT, SPF records directly.
- WHOIS / RDAP — identify the owner of any sending IP you find in the Received chain.