Message header analyser — email header analyzer_

A message header analyser reads the raw technical headers attached to an email and turns them into something a human can act on. Every mail server that touches a message stamps a Received: line onto it, and the receiving system records the results of SPF, DKIM and DMARC.

Reading those by hand is slow and easy to get wrong. An analyser reconstructs the delivery path, works out whether the authentication actually proves the sender is who they claim to be, and highlights the patterns that indicate spoofing or phishing.

Gmail: open the message, three-dot menu, Show original. Outlook on the web: three-dot menu, View, View message details. Classic Outlook for Windows: open the message in its own window, File, Properties, copy the Internet headers box. Apple Mail: View, Message, All Headers. Thunderbird: Ctrl+U, or View, Message Source.

Copy everything from the top down to the first blank line — that blank line is where the headers end and the body begins.

Three kinds of thing. What the sender claimed: From, To, Subject, Date, Reply-To — all supplied by whoever composed the message and therefore all forgeable. What the infrastructure recorded: the Received: chain, Authentication-Results, Received-SPF — added by servers as the message travelled. What the filters concluded: vendor headers such as X-Forefront-Antispam-Report or X-Spam-Status.

The investigative value is almost entirely in the second and third groups.

Because each server adds its Received: line to the top of the message as it passes through. The result is a stack in reverse chronological order: the bottom-most line is the first hop, closest to the sender, and the top-most is the last hop, closest to you.

This analyser reverses them for you and numbers them in the order the message actually travelled, so hop 1 is the origin.

The envelope is what the sending and receiving servers say to each other during the SMTP conversation — MAIL FROM and RCPT TO. The header is what is written inside the message itself. They are independent, which surprises people.

The envelope sender ends up recorded as Return-Path and is what SPF checks. The header From: is what your mail client displays. A message can perfectly legitimately have different values in each — and that gap is exactly what spoofing exploits.

Partly, and knowing which part is the whole skill. Anyone can invent From, Reply-To, Subject and even fabricate Received: lines, because those are just text the sender supplies.

What an attacker cannot forge are the Received: lines added by servers after the message left their control, and they cannot produce a DKIM signature that validates against a domain whose private key they do not hold. So trust the top of the chain, which your own infrastructure wrote, and treat everything below the first server you control as a claim rather than a fact. A fabricated hop usually shows as a break in the chain, which this tool flags.

Drag a .eml file onto the input box and the headers are read straight out of it — a .eml is plain text whose headers run down to the first blank line, so everything after that is ignored.

.msg is a compound binary format used by Outlook and is not parsed; open the message in Outlook and copy the Internet headers from File → Properties instead. Nothing you drop is uploaded — the file is read locally by the browser.

Both are correct. Analyser is the British and Commonwealth spelling, analyzer the American one, and this tool answers to either. Microsoft's own tool is the Message Header Analyzer with a z, which is why that spelling dominates search — so both appear on this page deliberately.

No. The entire analyser is JavaScript running in your own browser tab. Nothing is sent to a server, because there is no server component to send it to.

This matters more than it sounds. Email headers routinely contain internal hostnames, private IP ranges, recipient addresses, subject lines, ticket references and internal message IDs. Most popular analysers — including MXToolbox, EasyDMARC and Zoho — POST that data to their infrastructure. If you are analysing a customer's phishing report or an internal incident, that may be a disclosure you are not permitted to make.

Three practical differences. Privacy: MXToolbox processes your headers server-side; this never transmits them. Explanation: MXToolbox reports results, this reports the reasoning — particularly for DMARC, where it computes alignment between the From domain and the SPF and DKIM domains and tells you which mechanism carried the pass. Clarity: MXToolbox is widely described as overwhelming for non-specialists, so findings here are severity-ranked and explained in plain English.

What MXToolbox has that this cannot: live DNS and blocklist lookups, which are impossible from a browser without a backend. For those you get one-click deep links with the IP and domain pre-filled.

No, and it cannot. A browser cannot query DNSBLs, and fetching those services directly is blocked by cross-origin rules. The only workaround is to relay through a server — which would mean uploading your headers and destroying the privacy that is the point of this tool.

Instead it extracts the originating IP and sending domain and gives you deep links with them pre-filled for Spamhaus, MXToolbox blacklist checks and DMARC/SPF record lookups, so the manual step is one click rather than copy-and-paste.

Yes. Once the page has loaded the analyser needs no network at all, so it can be used on an isolated machine or an incident-response workstation with no internet access. Only the external reputation links need connectivity, and those open in a new tab when you choose to click one.

Free, no account, no rate limit, no paid tier and no analysis quota. There is nothing to meter because there is no backend doing work on your behalf — the computation happens on your own machine.

SPF publishes, in DNS, which servers may send mail for a domain; the receiver checks the connecting IP against that list. DKIM attaches a cryptographic signature to the message so the receiver can verify it was not altered and that it came from a domain holding the matching key. DMARC ties the two to the visible From: address and tells receivers what to do when neither aligns.

SPF proves a server was allowed to send. DKIM proves the message is intact and signed. Only DMARC connects either fact to the name the recipient actually sees.

This is the single most misunderstood part of email authentication. DMARC does not pass simply because SPF or DKIM passed. It passes only if a passing mechanism is also aligned with the domain in the visible From: header.

SPF authenticates the envelope sender in Return-Path, which is often a completely different domain belonging to a bulk sending platform. DKIM authenticates the domain in the signature's d= tag. If neither matches the From: domain, DMARC fails even though both SPF and DKIM report pass. Relaxed alignment accepts a matching organisational domain (mail.example.com against example.com); strict requires an exact match. This analyser computes both and names the mechanism that carried the pass.

Almost always because SPF checked a different domain from the one you can see. SPF validates Return-Path, not the From: address your client displays.

An attacker registers attacker-domain.com, publishes a perfectly valid SPF record for it, sends from an authorised server, and puts anything they like in the visible From:. SPF passes for attacker-domain.com and the recipient sees a spoofed name. That is exactly the gap DMARC alignment closes, and why a bare SPF pass proves very little on its own.

ARC — the Authenticated Received Chain — exists to solve forwarding. When a mailing list or forwarding rule modifies a message, adding a footer or rewriting a subject, it breaks the DKIM signature, and the new sending IP breaks SPF. A legitimate message then looks like a forgery.

ARC lets each intermediary record, cryptographically sealed, the authentication results it saw before it made changes, so the final recipient can choose to trust that chain. If a message failed DMARC but carries a valid ARC chain from a service you trust, that is usually forwarding rather than an attack.

It means the message carried no DKIM signature at all — not that a signature failed. Those are very different: dkim=fail means someone signed it and the signature did not validate, which is a real problem; dkim=none just means nobody signed it.

Plenty of small and internal senders still do not sign. It matters when the domain publishes a DMARC policy, because without DKIM the message depends entirely on SPF alignment — and SPF is the mechanism that breaks the moment anyone forwards it.

Because more than one party signed the message, which is normal. A sending platform often signs with its own domain while the customer's domain signs too, and mailing lists add their own signature on the way through.

What matters for DMARC is whether any valid signature has a d= domain aligned with the From: domain. A platform signature that validates perfectly but is not aligned does nothing for DMARC — a distinction this tool makes explicit rather than showing a single pass or fail.

They are the DMARC policy the domain owner published, telling receivers what to do when a message fails. p=none means take no action, just report — the monitoring mode almost everyone starts in. p=quarantine means treat failures as suspicious, usually delivering to junk. p=reject means refuse outright.

A domain sitting on p=none indefinitely gets DMARC reports but no protection, because a spoof of that domain is still delivered normally.

Because forwarding breaks authentication by design. The forwarding server sends from its own IP, so SPF for the original domain fails. If it modifies the message at all — a footer, a subject tag, a re-encoded body — the DKIM signature no longer validates. With both broken, DMARC fails.

This is the most common cause of an alarming result on a message that is entirely genuine, which is why the analyser looks for ARC and for forwarding patterns in the Received: chain and says so explicitly rather than just reporting failure.

From: is the address shown to the recipient. Return-Path is the envelope sender, where bounces go, and is what SPF validates. They are set independently.

Legitimate bulk senders deliberately differ: a newsletter shows the brand in From: while bounces go to the sending platform. The mismatch only becomes evidence of a spoof when nothing else ties the message to the From: domain — no aligned DKIM, and a DMARC failure.

BIMI displays a brand's logo beside a message in supporting clients. It is a consequence of good authentication rather than a control in its own right: a domain must be at DMARC enforcement before BIMI applies at all.

So a BIMI logo is weak positive evidence — it implies enforced DMARC — but its absence proves nothing, since most legitimate senders have not set it up.

The From: header has two parts: the display name your client shows in large friendly letters, and the actual address, which is often hidden entirely on mobile. Display-name spoofing puts something trustworthy in the first part while the second is attacker-controlled — a display name reading Microsoft Account Team with an address at a free webmail provider.

A particularly deceptive variant puts a whole fake email address into the display name, so the client shows what looks like an address while the real one stays hidden. This analyser inspects display names for embedded addresses, brand names that do not match the sending domain, and lookalike characters.

A domain registered to be visually confusable with a real one. Simple versions substitute characters that look alike in common fonts — rn for m, 1 for l, 0 for O — producing rnicrosoft.com or paypa1.com.

The sophisticated version uses internationalised domain names to swap in characters from other scripts, such as a Cyrillic а for a Latin a, which can be pixel-identical. Those appear in headers as punycode beginning xn--. This tool flags punycode, mixed-script domains and common substitutions against well-known brands.

Almost never for a good reason. RFC 5322 permits exactly one, but mail clients and security gateways disagree about which to display when there are two — and attackers exploit that: the gateway authenticates one, the client shows the other.

The same trick is used with duplicated Subject and Date. Any duplicate of a header that should be unique is treated as a high-severity finding here, because it has essentially no legitimate cause.

Not by itself — it is completely normal for legitimate bulk mail. Newsletters, ticketing systems and transactional platforms use a bounce address on their own infrastructure so bounces are processed automatically, so Return-Path points at the platform while From: shows the brand.

It becomes a problem only when nothing else ties the message to the From: domain: an unrelated Return-Path, no aligned DKIM, and a DMARC failure together mean the mismatch is the spoof rather than an administrative detail.

That your reply will go somewhere other than the apparent sender. There are legitimate uses — a no-reply sender directing responses to a support desk, or a mailing list.

It is also the standard mechanism in business email compromise: the attacker spoofs a supplier's From: address but sets Reply-To to a domain they control, so the conversation continues with them. If a message discusses payment details and carries a Reply-To on an unrelated domain, treat it as hostile until proven otherwise.

Message-ID is generated by the system that first accepted the message, and its right-hand side is conventionally that system's domain. When it bears no relation to the sending domain it often means the message was composed somewhere other than it claims.

It is soft evidence rather than proof — plenty of legitimate platforms generate IDs on their own domain — so this tool reports it as a low-weight signal that matters mainly when it coincides with other findings.

BEC is fraud by impersonation rather than malware: a message that appears to come from an executive, a supplier or a lawyer, asking for a payment or a change of bank details. There is usually no attachment and no link, so content scanners find nothing.

The header signatures are consistent: a display name matching someone real, a sending domain that is a near-miss lookalike or an unrelated free provider, a Reply-To pointing somewhere the attacker controls, and a fresh sending domain with no DKIM alignment. Individually each is mild; together they are the pattern.

A Date: in the future, or far away from the first Received: timestamp, is worth noticing. Most often it is a benign clock problem on the sending machine, or a message that sat in an outbox before being sent.

It is occasionally deliberate: dating a message in the future pushes it to the top of a sorted mailbox, and dating it in the past can bury it. The analyser flags a meaningful gap between the claimed Date and what the first server recorded.

They come from X-Forefront-Antispam-Report. SCL is the Spam Confidence Level: -1 allow-listed, 0–1 not spam, 5–6 spam, 9 high confidence spam. BCL is the Bulk Complaint Level from 0 to 9 — how much a bulk sender is complained about; a high BCL with a low SCL is typically legitimate but unwanted marketing. PCL is the Phishing Confidence Level.

SFV records why the verdict was reached — SFV:SPM spam filtering, SFV:SKA allow-listed, SFV:BLK blocked sender. This analyser decodes all of them.

X-Spam-Status and X-Spam-Score carry a numeric total plus the rules that fired. The default threshold is 5.0, though administrators change it. What is useful is not the number but the rule names: they tell you why. SPF_FAIL is an authentication problem, BAYES_99 means the content resembles known spam, URIBL_BLOCKED means a link was on a blocklist.

A borderline score driven entirely by cosmetic rules is a different problem from one driven by authentication failures.

Normal delivery is seconds. A hop over a minute usually means queuing, greylisting or a busy relay; over an hour typically means the receiving server deferred the message and retried.

Long delays are far more often a deliverability problem than a security one — greylisting of an unknown sender is the classic cause. The analyser highlights the slowest hop and the total transit time, so you can see whether a complaint about slow mail is real and which server caused it.

A spam defence where the receiving server temporarily rejects mail from a sender it has not seen before, on the theory that real mail servers retry and much bulk spam software does not. The legitimate sender retries minutes later and is accepted.

In a header this shows as a single large delay at one hop with normal timings either side — a very recognisable shape once you know it, and the usual explanation for "the first email from this supplier took twenty minutes".

Work through the header in order. Does SPF pass and align? Is there a DKIM signature whose d= matches your From: domain? Does DMARC pass? Is there an SCL or SpamAssassin score, and which rules fired? Is the sending IP one you control?

In practice the majority of cases are unaligned authentication — mail sent through a platform that authenticates its own domain rather than yours — followed by reputation problems on a shared sending IP.

List-Unsubscribe, List-Id, Precedence: bulk and Feedback-ID identify a message as bulk or mailing-list traffic. Their presence is a good sign rather than a bad one — they are what responsible bulk senders add, and Gmail and Yahoo now require one-click unsubscribe for high-volume senders.

The analyser reports them as context: they explain an unaligned Return-Path and tell you the message is marketing rather than personal correspondence.

It means at least one server-to-server handover happened in plaintext, so the message was readable by anything on the path at that point. Modern hops record something like (using TLSv1.3 with cipher …) in the Received: line; a hop with no such note either did not use TLS or did not record it.

It is a confidentiality concern rather than an authenticity one — it says nothing about whether the sender is genuine — and internal hops between servers in the same datacentre are the usual innocent explanation.

It starts at 100 and subtracts weighted penalties for each finding, with authentication and spoofing findings weighted far more heavily than hygiene issues. It is also capped by the worst single finding, so one critical problem cannot be diluted by a lot of clean results.

The score is a triage aid, not a ruling. Every contributing finding is listed with its weight so you can see how the number was reached and disagree with it. A message can score badly for entirely innocent reasons — forwarding, most commonly — and a targeted attack from a correctly configured domain can score well.

No, and no header tool's verdict deserves that. Headers tell you about transport and authentication; they say nothing about whether the content is a scam. The most dangerous message most organisations receive is a genuine, fully authenticated email from a real supplier whose mailbox has been compromised — it will pass every check here with full marks.

Use the verdict to triage and to explain a decision, not to make it.

Preserve the original message with headers intact — forwarding normally strips them, so use "forward as attachment" or export the .eml. Report it to whoever handles security where you work, and to the impersonated brand if there is one, since most large organisations run an abuse mailbox.

If it is your own domain being spoofed, the header will usually show why it succeeded: no DMARC policy, or one still at p=none. That is the thing to fix, and it fixes the whole class of attack rather than the one message.

Yes, and it is one of the best uses. Send a message from your platform to any mailbox you control, open the received copy, and paste the headers here. You will see exactly what a recipient's server concluded — whether SPF aligned, which domain DKIM signed, and whether DMARC passed on the strength of the right mechanism.

That is considerably more reliable than checking your DNS records in isolation, because it tests the path your mail actually takes.

Because it never left your organisation. A message between two mailboxes on the same tenant may traverse a single server, so there is one Received: line, no SPF check (no external IP to validate) and often no DKIM (nothing needed signing for an external party).

Sparse headers on internal mail are normal. The same sparseness on a message claiming to be from an external domain is a genuine red flag, and the analyser distinguishes the two cases.