Email Header Analyzer

Problem: The Header Is the Only Verifiable Record

When a message claims to be from a bank, a supplier or your own finance team, the visible sender line is decoration. It is a string in the message, and any sender can put any string there. The only part of the message that a receiving mail server is not free to invent is the header block, because every hop appends to it and none of them can remove what an earlier hop wrote. That is why the header is what an incident responder reaches for, and it is also why the header is hard to read: it is a plain-text audit trail written for machines, at one in the morning, by whoever configured the mail server in 2019.

The usual way to cope is to paste it into an assistant and ask what it means. That is where things go wrong. A language model has no way to reconstruct a folded header line, to subtract two timestamps in different time zones, or to tell whether a pass belongs to the domain in the From line or to a lookalike domain the sender happens to control. It will produce a fluent paragraph, and on a message that failed DMARC it will still find a way to sound reassuring. This tool does the opposite. It parses the record, does the arithmetic, and tells you which mechanism decided the outcome.

What Alignment Means, and Why Pass Is Not Enough

Almost every header carries a line that says dkim=pass, and almost every piece of advice online stops there. That reading is wrong, and it is wrong in the direction that matters to you. DKIM only proves that whoever holds the private key for the domain in the d= tag signed the message. It says nothing about whether that domain is the one in the From line. A criminal who owns evil.example can sign their own mail perfectly, and the resulting header will read dkim=pass. The question DMARC asks, and the question that actually decides whether the mail is trustworthy, is whether the domain that signed it is aligned with the domain the message is pretending to be from. Alignment is a domain comparison, and it is a one-line rule. Relaxed alignment accepts a parent or subdomain match; strict alignment demands an exact match. Get this wrong and you will congratulate a phishing message for passing authentication.

This tool evaluates alignment for you, on both SPF and DKIM, and reports the two domains side by side whenever they disagree. A dkim=pass with From: bank.com and d=: evil.example.net is the single most useful thing to see in a header, and it is the thing a field-by-field viewer hides behind three screens of scrolling.

Reading the Received Chain as a Timeline

Each Received line is written by the server that accepted the message and appended its own name, the address it came from, the protocol and the time. The lines run newest at the top, so read them downward to travel backwards through time. The useful part is not the list of servers, it is the gaps. Subtract one timestamp from the next and you have the time the message spent inside that hop. When a customer says a critical message did not arrive for six hours, the answer is almost always sitting in one of those gaps, and it is usually a queue at the sending side rather than anything to do with the recipient.

The tool builds the timeline in the order the message travelled, labels every hop with the server that received it and where it came from, and attributes the delay to the specific hop that held the message longest. It flags a delay against two thresholds that matter in practice: anything over five minutes is visible to the recipient, and anything over an hour is the kind of thing that ends up in a support ticket. Separately, it flags the originating address when that address is private or loopback, because a message claiming to come from a mail server with no public address did not travel the way the chain suggests.

The Fields That Lie

Some of the useful signal is not in the authentication results at all. The Return-Path domain is the domain that handles bounces, and it is written by the sending infrastructure rather than by whoever wrote the message, so when it disagrees with the From domain you are looking at mail sent through a service nobody named. The Reply-To domain is where a reply actually goes, which is why business email compromise works the way it does: a message that looks like it came from your chief financial officer can be wired to collect a reply at an unrelated address, and the header shows it. There is nothing subtle about that, and almost nothing checks for it by default.

Look at the display name too, rather than only at the address. Email clients render the part before the at sign as ordinary text, and lookalike characters from other alphabets survive that rendering intact. A Cyrillic a in the word paypal looks identical to the Latin one in most fonts, which is a cheap way to defeat a reader who is checking the domain and a filter that is not. This tool compares the scripts character by character and names the offending code point, so you get the finding rather than a hunch.

Two more fields are worth reading. The subject line is the cheapest place to hide a payment instruction or an executable attachment name from a filter that only reads the envelope, so a decoded subject carrying a URL or an extension such as .exe or .xlsm is reported on its own. And a serious bulk sender is required to publish one-click unsubscribe headers, so their absence is reported as the compliance gap it is rather than left as something you have to know to look for.

What This Cannot Tell You

It is worth being blunt about the boundary, because a tool that overstates itself is worse than no tool. This page reads the header you paste, and it makes no network requests at all, so nothing you paste is stored, logged or sent anywhere. It cannot check whether the sending address is on a blocklist, because that means querying Spamhaus and the other reputation databases, which is server-side work and cannot be done from a browser without handing your data to a third party. It cannot look at the links or the attachments, because it never reads the body. And it cannot tell you whether the message will be filtered, because the deciding factors there are your sender reputation and the recipient's history, neither of which appears in the header.

So the verdict is precise about what it covers. It tells you whether the sending infrastructure was authorised by the domain in the From line, whether the visible identity and the replying identity point at the same organisation, and where a delay was introduced. Those three answers settle the large majority of the questions people paste a header in order to ask.

Frequently Asked Questions

How do I get the raw headers in Gmail and Outlook?

In Gmail, open the message, click the three-dot menu at the top right of the message, choose Show original, then click Download original or copy the block under the subject line. In Outlook for Windows, open the message, click the three dots, choose View, then View message details. On Outlook.com the same option sits under the More actions menu. Any of those gives you the same block this tool expects.

Does it matter that DKIM passed if the From domain is different?

Very much so. A pass tells you the signing key belongs to the domain in the d= tag, nothing more. DMARC treats the message as authenticated only when that domain is aligned with the domain in the From line, under either relaxed or strict alignment. A message with From: bank.com and dkim=pass header.d=evil.example.net is the standard shape of a spoofed message, and the pass in it is real: evil.example.net really did sign it.

What do the SPF softfail and fail results mean?

A fail means the sending address is not authorised to send for that domain at all. A softfail means the policy exists but does not end in a hard all rule, so the receiving server is signalling doubt without rejecting outright. Neither is the same as a pass. Gmail commonly reports softfail for mail sent from a network the domain owner has not published, which is why alignment is checked separately rather than treating any pass-like value as authentication.

What is the ARC chain and why is it shown?

ARC, from RFC 8617, exists for forwarded mail. When a forwarder breaks SPF or DKIM in transit it signs a seal recording the authentication result it saw, so a later receiver can still trust what the first hop found. Each seal carries an instance number counting up from one and a chain validity value: none on the first link, pass when the chain so far validated, fail when it did not. This tool reports the instance numbers and the cv values in order and does not attempt to validate the seals themselves, because that needs the signing keys.

Which hop is responsible for a delay?

The one with the largest gap before its timestamp, measured from the previous hop, or from the Date header for the first hop. A long gap at the first hop means the sending side queued the message. A long gap in the middle means an intermediate relay held it. A long gap at the last hop usually means a filtering or scanning step before delivery.

Does it check whether the sender IP is on a blocklist?

No, and deliberately so. A blocklist check means sending your data to a reputation service, and the tool makes no network requests at all. For the live reputation of a domain or address, use the DNS lookup tool alongside this one.

Does it send or store the headers I paste?

No. There is no fetch call in this page, so the headers never leave your browser. If you want the conclusion rather than the analysis, copy the plain text report and paste it wherever you need it.

My DMARC result says none. Is that a failure?

No. A result of none means the sending domain has not published a DMARC record, so there is no policy to evaluate against and the receiving server cannot pass or fail it. That is a weaker position than a pass, because nothing is being enforced, but it is a different thing from a fail. Where an aligned identifier did pass, this tool will say so rather than treating the whole header as undeterminable.

Can I paste a full email or an .eml file?

Yes. The parser stops at the first blank line, which is where the header block ends and the body begins, so everything below it is ignored. A message with a MIME body, quoted-printable encoding or an attachment comes through unchanged above that line.

My message is a forwarded email. Should I still trust the result?

Treat it with care. Forwarding rewrites the chain and usually adds ARC seals, so the newest authentication result describes the forwarder rather than the original sender. The From domain and the earliest Received line still describe the origin, and the earliest hop is the one to look at when the question is who actually sent this.