Email Header Analyzer

Every relay prepends its own Received line, so in the raw headers the top line is the last hop and the bottom line is the first. This tool reverses them so the message reads from sender to recipient.

It is the gap between the timestamp on that Received line and the timestamp on the previous, older one. A large gap identifies the relay that held the message. Server clocks drift, so treat extreme values as a clock problem first.

No. The host name after from is what the connecting client announced and the sender controls it. The IP address in square brackets is what the receiving server observed, so it is the more reliable half.

From spf=, dkim=, dmarc=, arc= and compauth= inside Authentication-Results, the leading result word of Received-SPF, and the signing domain d= of DKIM-Signature. These are written by the receiving server, so they only mean something if you trust that server.

Yes. RFC 2047 encoded-words such as =?UTF-8?B?...?= are decoded for display. If the browser cannot handle the charset, the original string is left as it is.

No. Parsing runs entirely in your browser. Headers contain internal host names and recipient addresses, so nothing is sent to or stored on a server.

It is harmless. The header block ends at the first blank line and everything after it is ignored. Pasting only the headers is still the better habit.

It shows where the time went. The hop with the largest delay is the first thing to look at. Because clock skew distorts the differences, check the server clocks before drawing conclusions from an extreme value.

No. SPF only checks that the sending IP is allowed for the envelope sender domain. It says nothing about the content, and it does not validate the From address shown to the reader, so display-name spoofing survives an SPF pass.

Either the message was not relayed, or only part of the header block was pasted. The other headers and the authentication results are still listed.