Loading Techie Utils…

Email Header Analyzer

The delivery path, the authentication results, and what a forgery looks like. Free, and runs entirely in your browser — nothing is uploaded.

About Email Header Analyzer

The Authentication-Results header is somebody's summary, not the evidence. Any sender can write one, and a forwarded message carries whatever the last hop decided to say — so the raw DKIM-Signature is read here as well, and it says three things the summary never does.

l= limits how much of the body the signature covers. A signature with l=1000 protects the first thousand bytes and nothing after them: anyone can append whatever they like and it still verifies. The receiving server reports dkim=pass, entirely correctly, and the message being read is not the message that was signed.

h= lists the headers that were signed, and everything absent from it is unprotected. A signature that does not cover From verifies perfectly well after the From line has been replaced — which is the one thing DKIM exists to prevent.

A header signed once but present twice is an attack. DKIM signs from the bottom up, so the last copy is the one covered; most mail clients display the first. Both are defensible readings of the standards, and the gap between them is where a message that passes authentication shows a different sender to the person reading it. The same applies to a second From or Subject header, which RFC 5322 forbids and which this reports separately.

The headers are where the answer is. Every question people actually have about a message — did it really come from that domain, why did it take four hours, which hop marked it as spam, is this a forgery — is answered there and nowhere else. The body is what the sender wanted you to read; the headers are what the machines that carried it wrote down.

Two things decide whether a reader of them is right or wrong. Received headers run backwards: each server puts its line at the top, so the last one in the file is the first hop the message took. Reading them top to bottom gives a delivery path in reverse, which is how people conclude a message originated at their own mail server. This reverses them.

And everything above the last trusted hop was written by the sender. A forged Received chain costs nothing to produce and is extremely common; the only lines worth believing are the ones added by servers you control, which are the ones nearest the top of the file.

The Authentication-Results header is worth more than re-running the checks yourself. It is the result at the moment of delivery, against the DNS as it was then — and a domain's SPF record can change between a message arriving and somebody asking about it.

Everything happens in this tab. That is not incidental: a header block is the most sensitive thing most people ever paste into a web tool, carrying addresses, subjects, internal hostnames and the shape of an organisation's mail estate.

Where it helps

  • Reads the raw DKIM-Signature, not just the receiving server's verdict — so a body-length limit, an unsigned From line or a SHA-1 signature is reported even when authentication passed.
  • Catches the duplicate-header attack, where the copy that was signed is not the copy your mail client shows you.
  • Reports duplicate From, Subject and Date headers, which RFC 5322 forbids and which servers and clients resolve differently.
  • Reads the ARC chain, which is how a mailing list's mail survives DMARC — and says that it is worth exactly as much as your trust in the domains that sealed it.
  • Compares the Date header against the first Received line, so a message written to look older or newer is visible.
  • Surfaces Received-SPF, List-Unsubscribe with one-click support, the spam filter's own score, and what the message was sent with.
  • Puts the delivery path in the order the message travelled, which is the reverse of the order it is written in.
  • Shows the time spent at each hop, so a delay is attributed to the server that caused it.
  • Reads the Authentication-Results the receiving server wrote, rather than re-checking DNS that has since changed.
  • Catches the two shapes a forgery takes: a display name carrying a different address, and a valid signature from a domain that is not the sender.
  • Flags hops that handed the message on without TLS.
  • Runs entirely in your browser — a header block is the most sensitive thing most people paste into a web tool.

Limits

  • Only the topmost hops can be trusted. Everything above the last server you control was written by whoever sent the message.
  • It reads what the headers say; it cannot re-verify a DKIM signature, because that needs the message body as well.
  • Alignment is judged on the last two labels of a domain, which is right for .com and wrong for .co.uk — the exact answer needs the public suffix list.
  • A message with the headers trimmed — forwarded as an attachment, or copied out of a preview pane — has nothing useful in it.
  • Nothing here tells you whether a message is safe. It tells you what the servers recorded, which is evidence rather than a verdict.

Frequently asked questions

Where do I get the headers?

Gmail: the three dots on a message, then Show original. Outlook: File, Properties, Internet headers — or View source in the web client. Apple Mail: View, Message, All Headers. Paste the whole block, not the part that looks relevant; the part that looks irrelevant is usually where the answer is.

Which Received header is the real sender?

The bottom one is the first hop, and it is also the one most likely to be invented. A sender can write as many Received headers as they like before handing the message over, and they all appear below the genuine ones. The first line added by a server you actually control is where the trustworthy part starts.

Why does it say DKIM passed on a message that is obviously fake?

Because DKIM proves a message was not altered since the signing domain sent it — and the signing domain can be the attacker's. A valid signature from evil.example on a message claiming to be from your bank is a correctly signed forgery. DMARC exists precisely to require that the signing domain and the visible one be the same.

The message took four hours. Where did it go?

Look at the per-hop delays rather than the total. Almost all of the time will be at one hop, and a long pause at a single server is usually greylisting — a deliberate temporary rejection to make spam senders give up — or a queue backed up behind something else.

Related tools

More Network & DNS tools

  • DNS Lookup — Resolve A, AAAA, MX, TXT, NS, CNAME, SOA and CAA records
  • IP Lookup — Resolve addresses and reverse DNS for a host or IP
  • Port Checker — Test whether TCP ports accept connections
  • Nmap Port Scanner — Scan a host's common TCP ports, Nmap style, and see what each open service says it is
  • Ping (TCP) — Measure connection latency with repeated TCP probes
  • What Is My IP — Your public address, and what a browser reveals about you
  • WHOIS — Registry records for a domain, an IP address or an AS number
  • DNS Propagation Checker — The same name asked of resolvers worldwide, and of the zone's own servers
  • Email Authentication Checker — SPF, DKIM, DMARC and MX for a domain, read together
  • DKIM Lookup — A domain's DKIM keys, for a selector or by trying the common ones, and whether each is worth anything
  • DMARC Lookup — A domain's DMARC policy, and what it actually asks receivers to do
  • Reverse DNS Lookup — The PTR record for an address, and whether it confirms itself
  • IP Blacklist Checker — Whether an address is on the blocklists that actually stop mail
  • Reverse IP Lookup — What an address says about itself: its name, its certificate, its network
  • Traceroute — Every hop between this server and a host, with the time each one took
  • Broadband Speed Test — Download, upload, latency and jitter, measured from this tab
  • HTTP Headers — Grade a site's security headers from A+ to F, see every response header, and get the fix for your server
  • Redirect Checker — Follow a URL's redirects hop by hop, and flag loops, downgrades and temporary redirects doing a permanent job
  • IP Address Converter — Write an IPv4 or IPv6 address as an integer, hex, binary, expanded or mapped form, and see what kind it is
  • MAC Address Lookup — Find the manufacturer behind a MAC address, and see what kind of address it is
  • MAC to IP Converter — Build the IPv6 address a MAC forms with SLAAC, recover the MAC from one, or find a MAC's IP in an ARP table
  • IP to MAC Lookup — Find the MAC address behind an IP: computed for multicast and EUI-64 addresses, or read from an ARP table
  • DNSSEC Checker — Whether a domain's DNSSEC validates, and if not, whether it is the DS, a key, an algorithm or an expired signature