Email Header Analyzer

How to get the full headers of an email

Your mail app hides the headers and shows only From, To, Subject and Date. The full set is a block of plain text above the message body. This is where to find it in the common mail apps:

1. Gmail: Open the message, click the three dots next to Reply and choose Show original. Copy the full text, or click Download original to get an .eml file.
2. Classic Outlook: Open the message in its own window, choose File > Properties and copy everything in the Internet headers box.
3. New Outlook and Outlook on the web: Open the message, choose More actions > View > View message details and copy the text.
4. Apple Mail: Select the message and choose View > Message > All Headers, then copy the headers shown above the message.
5. Yahoo Mail: Open the message, click More (the three dots) and choose View raw message, then copy the text from the page that opens.
6. Paste into the analyzer: Paste the text into the box above and click Analyze, or drop the saved .eml file onto the box.

Copy the whole block, not just a few lines: the analyzer needs the Received lines and the Authentication-Results headers, and both sit near the top.

How to save an email as an .eml or .msg file

To also check the DKIM body hash and hash the attachments, give the analyzer the whole message file instead of pasted headers. Save one file per message:

How to read Received lines

Every mail server that accepts a message usually writes a Received line and puts it at the top of the headers. So the list is a stack: the topmost line is the last hop, written by the server that delivered the message to your mailbox, and the lowest line is the first hop, usually the sender's own outgoing server. The analyzer turns the stack around and numbers the hops in the order the message traveled.

A typical line reads from relay.example.com (relay.example.com [198.51.100.25]) by mx1.example.net with ESMTPS; Wed, 14 Oct 2026 09:13:19 -0700. The part after from is the name the sending server announced, followed by the IP address the receiving server actually saw. The part after by is the receiving server. The keyword after with names the protocol: ESMTPS means the hop was encrypted with TLS, ESMTPSA means it was encrypted and the sender logged in. The date after the semicolon is the time on the receiving server's clock when it accepted the message, which the analyzer converts to UTC so that time zones line up.

The trust boundary matters more than any single line. The lines your own provider wrote are reliable, because the sender cannot write them. Everything below the point where your provider first accepted the message was written before it reached you, and a sender can add invented Received lines there to suggest a different origin.

What SPF, DKIM, DMARC and ARC results mean

The receiving server records its checks in an Authentication-Results header. Its first word is the authserv-id, the name of the server that ran the checks. Then come the verdicts:

• SPF checks whether the IP address that handed over the message is allowed to send for the domain in the envelope sender (smtp.mailfrom), which is the bounce address and not the visible From.
• DKIM checks a cryptographic signature from the domain in header.d over selected headers and the body. A pass means those parts were not changed after signing, apart from the whitespace changes the relaxed canonicalization allows.
• DMARC passes when SPF or DKIM passed for a domain aligned with the visible From domain (header.from), either the same domain or, in relaxed mode, a subdomain of it. It is the check that ties the result to the address a reader actually sees.
• ARC lets a forwarder, such as a mailing list, record the results it saw before it changed the message, so the final receiver can still judge the original checks, if it trusts that forwarder.

Pass means the check held. Fail means it did not. Softfail and neutral are weaker SPF results: the domain owner chose not to make the rule strict. None means the domain publishes no SPF or DMARC record, or, for DKIM, that the message was not signed, and temperror or permerror mean the check could not be completed. Trust the verdicts in the topmost Authentication-Results header written by your own provider; a header lower down, or one with an authserv-id you do not recognize, may have been added before the message reached you.

What headers can and cannot prove

Headers are good at two things: the route a message took after it reached your provider, and whether its signed parts changed on the way. The Received lines written by your provider and its Authentication-Results cannot be forged by the sender, and a DKIM signature that still verifies shows the signed parts are unchanged.

Headers are weak on everything the sender's own software writes. From, Date, Subject and Message-ID are filled in by the sending program and can say anything. Received lines below your provider's first hop can be invented. And no header shows who sat at the keyboard: a DKIM pass for example.com shows that the message was signed with a key that example.com publishes, not which person typed it.

When a dispute needs more than an analyzer

An analyzer tells you what the headers say today, on your screen. When an email matters in a dispute, the other side may ask whether your copy is complete and unchanged, and a screenshot of an analysis does not answer that.