When you open an email, you see the friendly version: a name, a subject, a timestamp, and the message itself. Underneath that sits a block of metadata that records exactly how the message got to you: which servers it passed through, what checks ran along the way, and when each step happened. That block is the email header, and it is written for machines, not for people.
The Mail Header Analyzer takes that raw text and turns it into something you can actually read. Paste in the header, and you get the delivery path, the authentication results, and any sender mismatches laid out plainly.
What raw headers look like
Open the original source of a message in Gmail ("Show original") or Outlook ("View source"), and you will see lines that start with tags like Received:, DKIM-Signature:, Authentication-Results:, Return-Path:, and Message-ID:. A single message can carry dozens of these lines.
Two things make them awkward to read by hand. First, the Received: headers stack in reverse order, newest server on top and the original sender at the bottom, so you read the journey backwards. Second, the cryptographic signatures are long base64 strings that push everything else off the screen:
Received: from mail.vendor.com (mail.vendor.com [203.0.113.10])
by mx.yourcompany.com with ESMTPS id abc123
for <[email protected]>; Tue, 24 Jun 2026 09:14:02 +0000
Received: from internal.vendor.com (internal.vendor.com [198.51.100.5])
by mail.vendor.com; Tue, 24 Jun 2026 09:11:47 +0000
Finding a delay or a failed check means picking through this line by line. The analyzer does the picking for you.
Following the delivery path
A common help-desk complaint sounds like this: "Why did my email take three hours to arrive?" Mail is supposed to feel instant, but messages get queued, throttled, or held up by intermediate servers (MTAs) and anti-spam gateways.
The tool pulls every Received: header and rebuilds the route in the right order, oldest hop first. For each hop it shows the sending IP, the receiving hostname, and the timestamp, then calculates the gap between hops. So when a message really did sit for three hours, you can see which server held it, whether that was the sender's own network, a filtering service like Proofpoint or Mimecast, or the final destination. Instead of guessing where the slowdown happened, you point straight at it.
Checking authentication: SPF, DKIM, and DMARC
When a receiving server accepts a message, it records the outcome of its identity checks in the Authentication-Results: header. Reading that raw is tedious, so the analyzer extracts it and gives you plain Pass, Fail, or Neutral markers for each check.
Three checks matter here:
- SPF confirms the sending server is allowed to send for that domain.
- DKIM verifies a cryptographic signature that proves the body was not altered in transit.
- DMARC ties the two together and tells receivers what to do when a check fails.
Say a newsletter keeps landing in spam. Paste the headers of a test send, and the tool might show SPF passing while DKIM fails, because a forwarding server rewrote the body and broke the signature. That single DKIM break is enough to fail DMARC, and now you know exactly what to fix rather than blaming the whole setup.
Catching a spoofed sender
One of the easiest tricks attackers use is display-name spoofing. The message looks like it came from "[email protected]" in the visible From: field, but the address mail actually returns to is something like "[email protected]".
The analyzer lines up three fields side by side: the visible From:, the Return-Path: (the envelope sender), and the Reply-To:. When these disagree in a way that does not add up, that is a classic phishing signature, and the tool flags it. Instead of arguing over whether a reported email "feels off," you can show the mismatch and settle it.
A quick forensic walk-through
A finance manager gets an urgent note, apparently from a long-standing vendor, asking that future payments go to a new bank account. The logo is right, the signature block is right, even the writing style fits. Before wiring anything, they forward it to IT.
The analyst drops the raw headers into the Mail Header Analyzer. The path shows the message originated from a residential IP in another country, nowhere near the vendor's corporate mail servers. The authentication results show a hard SPF and DMARC failure. The consistency check shows the Return-Path: pointing at a throwaway address. What looked like a routine payment update is a fraud attempt, and it took seconds to prove rather than an afternoon of back-and-forth.
Where to start
If a message ever looks wrong, or a legitimate campaign keeps missing the inbox, grab the raw header and run it through the analyzer before you do anything else. The delivery path tells you where a message has been, the authentication results tell you whether it is who it claims to be, and the sender comparison tells you whether someone is trying to fool you. That is usually enough to decide your next move with confidence.