Email header analyzer

How this tool works

Copy the complete headers of a message from your mail client and paste them into the box. The server parses them and builds the report; the message body is not needed. The tool is free and requires no account.

Every mail server that handles a message adds a Received: line to the top of the headers, recording the server it received the message from, its own name, the protocol, often the connecting IP address, and a timestamp. By the time the message reaches you, the headers contain a chain of these lines, newest first. The analyzer reads them in order, reverses the chain so it runs from the origin to your mailbox, extracts the sending host and IP from each line, and computes the delay between consecutive timestamps.

It then reads the Authentication-Results: header that your receiving server added, which records the outcome of its SPF, DKIM and DMARC checks, and presents each result with the domain it was evaluated against. Finally it identifies the originating IP, the first public address in the chain, and looks it up: country and city estimate, the autonomous system that announces it, its reverse DNS name and a link to the full IP lookup and blacklist check.

Read the From, Return-Path, Reply-To, Message-ID and Date lines of the pasted block alongside the report; together with any provider-specific spam-score lines they complete the picture.

How to read the result

The hop list

Each row is one server that handled the message, from the origin at the top to your mailbox at the bottom. The columns show the host that passed the message on, the host that received it, the protocol, the timestamp and the delay since the previous hop.

The first hop is the most interesting one. If it shows a public IP with a hostname belonging to a mail provider, the message was sent through that provider and the address tells you which one, not who the sender is. If the first hop shows the IP of a home or business connection, the sender's mail client connected directly to a server that recorded the client address, and the IP lookup gives you an approximate location and the ISP.

The last hops are your own provider's servers. Everything between is transit: forwarding services, mailing lists, spam filters and relays. A message that was forwarded from another mailbox shows the forwarding mailbox's provider as an extra group of hops in the middle.

Delays reveal where a message sat. A few seconds per hop is normal. Minutes at a single hop usually mean greylisting or a spam scan. Hours can mean a server that was down, a queue, or a wrong clock, which also produces negative delays, since each server stamps its own local time.

Authentication results

A message can pass SPF and DKIM for one domain while the From line shows another. That is exactly what DMARC alignment catches, and why the DMARC line is the one to trust when they disagree.

Origin IP block

The country and city are estimates from a geolocation database and describe the server, or the sender's connection, at the time of sending. The ASN tells you what kind of network it is: a mail provider, a hosting company or a consumer ISP. A direct-to-mailbox message whose origin is a hosting network with no reverse DNS and a DMARC fail is the typical profile of spam or phishing.

What to do next

You suspect phishing or forgery

1. Compare the From domain with the DMARC result. A fail, or a pass for a completely different domain than the one in the From line, means the visible sender is not what it claims.
2. Check the Reply-To and Return-Path headers. Phishing often shows a trusted From and an unrelated Reply-To.
3. Look at the origin IP's network and blacklist status. A hosting network or a listed address supports the suspicion.
4. Do not click links in the message. Report it through your provider's phishing report option, which sends the full headers to them automatically.

You want to know who sent an anonymous or harassing message

1. Identify the first public IP in the chain and its network. If it belongs to a webmail provider, the headers end there; only the provider holds the account's connection records, and they release them only on a legal request.
2. If the first hop is a consumer ISP address, the WHOIS lookup gives the ISP's abuse contact. The ISP can identify the subscriber from the IP and the exact timestamp with time zone, again only through a legal process.
3. Keep the original message with headers intact. Forwarding strips or rewrites them; use the export or "save as" function of your client.

Your own mail is being marked as spam

1. Send a message to a mailbox you control at a large provider and analyze its headers.
2. Fix any SPF fail by adding the sending server to your domain's SPF record; check the record with the DNS lookup. Fix a DKIM fail by enabling signing at your mail provider or server and publishing the selector's key.
3. Publish a DMARC record once SPF and DKIM pass, starting with a policy of none and reporting turned on.
4. Confirm the sending IP has a forward-confirmed reverse DNS name and is not on a blocklist.

Getting the headers from common clients

1. Gmail (web): open the message, click the three-dot menu, choose Show original, then Copy to clipboard.
2. Outlook (desktop): open the message in its own window, File, Properties, and copy the Internet headers box. In Outlook on the web, open the message menu, View, View message source.
3. Apple Mail: select the message, View, Message, All Headers, or Raw Source for the complete message.
4. Yahoo Mail: open the message, More, View raw message.
5. Thunderbird: View, Headers, All, or View, Message Source.
6. Mobile apps: most do not expose headers; open the message in the provider's web interface instead.

Paste everything from the first header line down to the blank line that precedes the body. Including the body does no harm, but it is not needed.

Reading the Received chain yourself

A Received line looks like Received: from mail.example.net (mail.example.net [203.0.113.10]) by mx.yourprovider.com with ESMTPS id abc123; Tue, 1 Oct 2024 10:15:22 +0000. The from part is the sending server as it introduced itself, with its real hostname and IP in parentheses as seen by the receiver; the by part is the server that wrote the line. Reading these from the bottom of the headers upward follows the message from origin to destination. The analyzer does this for you, but knowing the format lets you spot a line that was written by the sender rather than by a server: a Received line that claims an implausible server, or one whose timestamp is out of order with the rest.

Limits of this tool

• Headers below the first trusted hop can be forged. The sender can insert fake Received lines; only lines added by your provider and by servers it received from are reliable.
• Webmail and most providers do not reveal the sender's device address. The origin IP is often the provider's server, which is shared by millions of users.
• Geolocation of the origin IP is an estimate at city level at best, and describes the server or connection, not the person.
• The authentication results come from the header written by your receiving server. If your provider does not add an Authentication-Results header, or strips it, the tool cannot evaluate SPF, DKIM or DMARC and reports them as not available. The tool does not re-run the checks itself.
• Timestamps come from each server's own clock. Negative or implausible delays usually mean a clock is wrong, not that the message traveled back in time.
• Forwarding, mailing lists and some security gateways rewrite headers, which can break SPF and DKIM for legitimate mail and hide the original path.
• The tool parses headers in standard format. Headers copied from a client that reflows or translates them, or a message exported as a screenshot, cannot be analyzed.
• Private IP addresses in the chain are internal hops and are not looked up.