Email Header Analyzer

In Gmail, open the message, use the three-dot menu and choose Show original. In Outlook on the web, open the three-dot menu and choose View message source; in the desktop client it is File, then Properties, and the box labelled Internet headers. In Apple Mail, turn on View, then Message, then All Headers. Copy the whole block and paste it in — a complete message works too, since everything after the first blank line is ignored.

Each server that handles a message adds a Received header at the top with the time it took the message, so the list runs backwards. Reversing it gives the real order, and the gap between one timestamp and the next is how long the message waited to be accepted by that server. A hop of a minute or more is where the delay lives. Do check for clock skew first: if one server is set wrong, the delays around it are meaningless, which is why a hop stamped before the previous one is reported rather than shown as a negative number.

The fields the sender writes can be faked, including From, Reply-To, Date and any Received lines invented to make a route look longer. Headers added after the message left the sender’s control are useful only within a trust boundary. Start with the topmost normal Authentication-Results entry, then check whether its authserv-id names a mail system you trust. Earlier entries are older claims, not independent proof; if the chain starts at a hostile server, so can its record.

It records what the receiving server concluded when it ran SPF, DKIM and DMARC. spf=pass means the sending server was authorised for the envelope domain. dkim=pass means a signature verified, so the signed parts arrived unaltered. dmarc=pass means one of those passed for a domain that matches the From address a reader sees — which is the part that ties authentication to the identity being claimed. This tool shows each verdict with what it means in practice; it reports the receiver’s conclusion rather than re-running the checks.

Because DMARC also requires alignment. SPF checks the envelope sender in Return-Path, which for mail sent through a provider is usually a bounce address on the provider’s own domain. That passes SPF for the provider while the From header shows yours, so the two do not align and DMARC fails anyway. DKIM signing with your own domain is the more robust half, since DKIM alignment survives forwarding while SPF does not.

It sets a body length, so the signature covers only the first l bytes. Anything appended after that point verifies exactly as before, which means someone can add content to a signed message without breaking the signature. It exists to survive mailing lists that append footers, and it is why this tool flags it: a signature that says pass over an unknown fraction of the body is weaker than one that covers all of it.

That is RFC 2047 encoding. Header fields are ASCII, so any other script is base64 or quoted-printable encoded with its charset named in front. Clients decode it before display, which is why the encoded form only shows up in a log, a ticket or a copied header block. This tool decodes it, including the legacy charsets — Shift_JIS, GB2312, Big5 and the ISO-8859 family — that still appear in mail from older systems.

Sometimes. The bottom Received header records the address the first receiving server saw, which for a message sent from a mail client is often the sender’s network. But when the message came from a webmail interface that address belongs to the provider, and a sender who controls their own server can write earlier Received headers saying anything at all. Only the hops added by servers you trust are evidence, and the addresses in them are frequently private ranges that identify nothing outside that network.

No. The parsing runs in your browser, and nothing is sent anywhere. That matters more here than for most tools, because a header block routinely contains the recipient’s address, internal hostnames, queue ids and private address ranges. There is also a redaction toggle that masks mailbox names and address literals in whatever you copy or download, for when the result has to go into a shared ticket.

Forwarding breaks authentication: SPF fails because the forwarder is not on the original domain’s list, and mailing lists often break DKIM by rewriting the subject or appending a footer. ARC lets an intermediary record what it saw before it made those changes, and seal that record, so the final receiver can decide whether to trust it. Several ARC sets simply mean the message passed through several such intermediaries — it is the normal shape for anything that arrived via a list.

It means the name shown before the address contains an address of its own, and it is not the one the message came from. Since most clients show only the display name, a message can appear to be from a bank while actually being sent from an unrelated mailbox. It is the cheapest spoof there is, it needs no compromised infrastructure, and it is invisible until you look at the raw From header.

They look at opposite ends of the same problem. The checker reads what a domain publishes in DNS — its SPF chain, DMARC policy and DKIM keys — and judges the configuration. This tool reads one delivered message and reports what actually happened to it. Use the checker while setting a domain up, and this one when a specific message went wrong. The signature cards link across, so a signing domain found here can be checked there in one click.