Email Header Analyzer

Runs in browser New Web Utilities

Paste the header block of an e-mail ("Show original" in Gmail, "View message source" in Outlook) and the analyzer reads it entirely in your browser: every Received hop in order with the delays between them, the SPF, DKIM and DMARC verdicts and which server recorded them, whether the From domain aligns with the envelope and the signatures, the candidate originating addresses and the spam-filter verdicts. Each finding says what it means and how far the header can be trusted, because every line below your own mail server's can be written by the sender.

Privacy: This tool runs entirely in your browser. Your input never leaves your device.

What do an email's headers record about where it came from?

Each mail server that relays the message adds a Received line at the top, so the route reads newest first (RFC 5321), and your own receiving server records in Authentication-Results (RFC 8601) whether SPF, DKIM and DMARC passed; DMARC passes only when SPF or DKIM passed for a domain aligned with the From address (RFC 7489). Every header below your own server's entries can be written by the sender, so a result counts only when its authserv-id is your receiving system, and even a pass says which domain vouched for the message, not that a request in it is honest.

Security note: A message that passes every check can still be fraud from a look-alike domain. Confirm payment changes and credential requests through a channel you already trust, never through the reply address of the message.

How to use Email Header Analyzer

  1. Open the message in your mail client and show its source: "Show original" in Gmail, File then Properties in Outlook, View then Message then All Headers in Apple Mail.
  2. Copy everything from the first header line down to the first blank line and paste it into the field.
  3. Press Analyze headers and start with Findings: the high and medium items are the ones to act on.
  4. Read Authentication results and Sender identity and alignment to see whether the From address is backed by a passing, aligned check, then the Received hops for the route the message took.

Email Header Analyzer features

  • Reads the whole header block in your browser: unfolds long headers, decodes encoded names and subjects, and ignores a message body pasted by mistake
  • Lists every Received hop oldest first — sending host, address, receiving server, protocol, TLS, time in UTC and the delay since the previous hop — and the total transit time
  • Shows the SPF, DKIM and DMARC verdicts with the exact result recorded (softfail, temperror …), which server recorded it and which header it was taken from
  • Checks DMARC-style alignment: whether the envelope (Return-Path) domain and the DKIM signing domains match the From domain, strictly or relaxed
  • Finds warning signs with a severity each: a Reply-To on another domain, a display name showing another address, duplicate From or Subject headers, hidden characters, missing reverse DNS, urgency flags and bulk-mailing scripts
  • Lists every originating-address candidate (X-Originating-IP, X-Sender-IP, the oldest public Received hop) and warns when they disagree
  • Reads spam-filter verdicts from SpamAssassin, Rspamd, Microsoft (SCL), Proofpoint, Barracuda and Amazon SES headers

Inputs and outputs

Inputs

  • Message headers — the full header block of one message as your mail client shows it, up to 2 MB; a body pasted after the blank line is ignored.
  • Nothing else: no address, domain or setting is needed, and nothing is fetched.

Outputs

  • Summary and Findings — the three verdicts, the hop count, the transit time and every finding with its severity and meaning.
  • Authentication results and Sender identity and alignment — the recorded result of SPF, DKIM and DMARC with the server that wrote it, the From, envelope and signing domains, and whether they align.
  • Received hops, Originating address candidates and Message — the route oldest first with times and delays, the addresses the message may have started from, and the From, To, Subject, Date, Message-ID and Return-Path as written.
  • DKIM signatures, Spam filter, Alignment notes and Reading this result — each signature's domain, selector and algorithm, the filter verdicts, how alignment was decided, and what the analysis cannot establish.

Email Header Analyzer example

A message that passes SPF and DKIM for another domain but fails DMARC

Input:

Headers of a message "From: Example Accounts Payable <accounts@example.com>" with "Reply-To: ap-desk@payments-update.example", sent through mail.billing-portal.example and received by mx.google.com (the tool's Load example).

Output:

Summary: SPF Passed · DKIM Passed · DMARC Did not pass · Received hops 3 · Transit time 00:00:10 · High-severity findings 1 · Medium-severity findings 1
Findings: High — DMARC fail (mx.google.com recorded dmarc=fail for example.com) · Medium — Reply-To points to a different domain · Low — Hop 1: sending host has no matching reverse DNS · Low — Marked urgent · Low — Sent with a bulk-mailing or scripting library
Authentication results: SPF pass, DKIM pass, DMARC fail — all recorded by mx.google.com in the newest Authentication-Results
Sender identity and alignment: From domain example.com · Envelope (Return-Path) domain billing-portal.example · SPF aligned with From: No · DKIM aligned with From: No
Received hops: 1 WIN-7Q2J4KD 203.0.113.77 → mail.billing-portal.example 09:13:59 · 2 → mx.google.com +00:00:09 · 3 +00:00:01

How to read the Email Header Analyzer results

DMARC "Did not pass" means the receiving server recorded that neither an aligned SPF pass nor an aligned DKIM pass backs the From address. Forged mail looks like this, but so do messages that were forwarded or passed through a mailing list; if the message asks for money, credentials or a change of bank details, confirm it through another channel before acting.

SPF and DKIM "Passed" with "aligned with From: No" mean the checks vouched for another domain — a sending service or a look-alike name — not for the address the reader sees. Mail sent through a service that does not sign for the From domain looks like this, and so does mail from a look-alike domain.

"Not recorded" means no trusted receiver wrote a result for that check; it is not a failure. A foreign Authentication-Results header in the findings explains why a result was set aside.

High-severity findings are reasons to distrust the message (a DMARC failure, an address hidden in the display name, hidden characters inside an address); medium ones need a second look; low and info findings describe the message more than they accuse it.

A hop delay of minutes to hours usually means queuing or greylisting, not tampering; a negative delay means two servers' clocks disagree or a Received line was written by the sender.

When to use Email Header Analyzer

  • Checking what the receiving server recorded about a payment-change or password-reset e-mail — whether an aligned, passing check backs its From domain — before acting on it.
  • Explaining to a colleague or a customer why their message landed in spam: no DKIM, an unaligned envelope domain, a missing reverse DNS.
  • Measuring where a slow message waited: the hop with the long delay names the server that queued it.
  • Collecting the facts for an abuse report: the originating address candidates, the sending service and the receiving server's own entry.

Troubleshooting

  • "No header lines were found": the paste starts with the message text. Copy the original source, which begins with lines such as Received: or Delivered-To:.
  • Every verdict says "Not recorded": the headers were copied from the sender's Sent folder, or the receiving server writes no Authentication-Results. Analyse the copy in the recipient's mailbox.
  • A result is listed as "not from the receiving server": a gateway in front of your mailbox writes results under another name. If that gateway is yours, its results are trustworthy; otherwise treat them as the sender's claim.
  • Lines were "joined to the header above": the copy lost the indentation of folded headers. Copy from the raw source view rather than a formatted one.

Frequently asked questions about Email Header Analyzer

Where do I find the full headers of a message?

In Gmail open the message, then the three-dot menu and Show original. In Outlook on the desktop open the message, then File, Properties and copy the Internet headers box; in Outlook on the web use the More actions menu, View, View message details. In Apple Mail use View, Message, All Headers; in Thunderbird View, Message Source. Copy everything from the first line down to the first blank line: a trimmed paste hides hops and results.

Which Authentication-Results header decides the verdict?

The newest one written by your own receiving server: the top-most header whose authserv-id matches a host in the receiving part of the Received trace. A header written under another name is shown as not from the receiving server and is not used. A forged header that copies your receiver's exact name cannot be told apart from the real one; it is harmless only because receivers remove incoming headers that claim their name (RFC 8601 §5), so check that your mail system does.

Why are some times shown "as written" and not converted?

A date with no time zone, or with an abbreviation such as IST or BST that means different offsets in different places, cannot be placed on a timeline. The analyzer shows such a date exactly as written, leaves it out of the delay and transit arithmetic, and says so instead of guessing an offset.

Is the originating IP address the sender's computer?

Not necessarily. X-Originating-IP is written by the sender's webmail or sending service, X-Sender-IP by Microsoft's filters, and the oldest Received line from a public address can be written by the sender itself. Every candidate is listed with where it came from; when they disagree, rely on the entry your own server wrote about the host that handed it the message.

Does "DKIM pass" prove who sent the message?

It proves that the signing domain (d=) vouched for the signed headers and body as they arrived. It backs the From address only when that domain aligns with the From domain, which is exactly what DMARC checks; a pass for a sending service's own domain says nothing about the From address.

Are my headers uploaded or looked up anywhere?

No. The analysis runs in your browser and nothing is sent or stored. Because no network request is made, DKIM signatures are not verified against the published key and addresses are not checked against block lists; the IP Blacklist Checker and the DKIM Record Checker do that on request.

Technical notes

The header block is the RFC 5322 message header: long fields are unfolded at the line breaks the sender inserted, non-ASCII names and subjects are decoded from RFC 2047 encoded words, and fields such as From, Subject and Message-ID are expected exactly once. Each mail server that relays the message adds a Received field at the top (RFC 5321 §4.4), so the block reads newest first; the tool reverses it to show the journey in order.

Receivers record their checks in Authentication-Results (RFC 8601): the first token is the authserv-id naming the system that wrote it, followed by results such as spf=pass smtp.mailfrom=…, dkim=fail header.d=… and dmarc=fail header.from=…. Because anyone upstream can write such a header, only the receiver's own count (RFC 8601 §5): the tool takes each verdict from the newest Authentication-Results whose authserv-id matches a host of the receiving part of the Received trace, falls back to the newest Received-SPF for SPF (RFC 7208 §9.1), and reports any other header as foreign.

DMARC (RFC 7489 §3.1) passes only when SPF passes for an envelope domain, or DKIM passes for a signing domain, that aligns with the From domain — the same organizational domain in relaxed mode, the identical domain in strict mode. The organizational domain is computed from the Public Suffix List bundled with the tool. ARC sets (RFC 8617) are summarised but never decide a verdict: they record what an intermediary saw.

Delays are computed only between hops whose date has a usable time zone; a date with no zone or an ambiguous abbreviation (IST, BST, AST) is kept as written and skipped, and a delay measured across such a hop names the hop it starts from.

Limitations and methodology

Nothing is verified against the internet: DKIM signatures are not checked against the published key, addresses are not looked up in block lists, and SPF is not re-evaluated — the tool reports what the receiving servers recorded.

Headers below your own mail server's entries can be written by the sender. A forged Authentication-Results header that copies your receiving server's exact authserv-id cannot be told apart from the real one; only the receiver removing such headers on arrival (RFC 8601 §5) protects against it.

The originating address is only a candidate: X-Originating-IP and the oldest Received lines can be written by the sending side, and webmail or VPN users show their provider's address.

Times are only as good as each server's clock, and dates without a usable time zone are not converted.

Security and privacy

The headers are analysed in your browser and are never sent, looked up or stored, so the names and addresses of the people in them stay on your device.

References