Where do I find the raw header?

Outlook: File > Properties > Internet headers. Thunderbird: Ctrl+U (source). Gmail: message menu > Show original. Apple Mail: View > Message > All Headers. Paste the entire header area up to the first blank line.

Is my data transmitted?

No. The pasted text is only evaluated for display and not stored permanently. There is no DNS or other network query.

How do I read the Received chain?

From bottom to top: the bottom Received line is the first hop (connecting server), each line above it a later hop up to the target system. The delay per step shows where the mail lost time.

Why is my mail marked as spam, what does the header say?

The telling parts are the Authentication-Results (did SPF/DKIM/DMARC pass?), the receiver's spam headers (X-Spam-Status, SCL) and whether the connecting IP had clean reverse DNS. A dmarc=fail or a high SCL usually explains the classification directly.

Does the tool check the DKIM signature cryptographically?

No. It shows what is in the header, including the Authentication-Results of the receiving server. A real signature check would need the complete raw message with the body.

Why is there no TLS for some hops?

The header only reveals for visible hops whether TLS was used (for example with ESMTPS). If the note is missing, that hop did not record it; a safe conclusion of 'unencrypted' is not possible.

Email Header Analyzer

Paste a raw email header and read the delivery path with SPF, DKIM and DMARC results.

Every email carries its full delivery history in its header: which servers it passed through, how long each step took and how the receiving system rated SPF, DKIM and DMARC. This analyzer turns the raw header, often hundreds of lines long, into a readable overview and helps with questions like why was this mail filed as spam or is this message really from the stated sender.

What this tool checks

The input is the raw header, pasted as text. There is no network query, everything is evaluated locally. It shows: the Received chain in chronological order with the delay per hop and the connecting public IP, the Authentication-Results with SPF, DKIM, DMARC, ARC, iprev and compauth in plain text, the DKIM-Signature headers with the signing domain, selector, algorithm and expiry time, the sender identity (From, Return-Path, Reply-To, Message-ID) and the receiver's spam headers (X-Spam-*, SCL).

Reading the result

The Received chain reads from bottom to top: the bottom line is the first hop, the top line the last. A green check per authentication method means pass, a warning fail or softfail. Marked as errors are multiple From headers (an RFC violation and a classic phishing pattern), a contradiction between From and Return-Path and an expired DKIM expiry date. Suspicious time jumps between hops (a long delay or a clock running backwards) and a spam classification by the receiving system appear as a note.

Background

The structure of the header follows RFC 5322 (among other things exactly one From). The Received trace fields are described in RFC 5321 section 4.4, the format of Authentication-Results in RFC 8601, the ARC header chain in RFC 8617. The individual results come from SPF (RFC 7208), DKIM (RFC 6376) and DMARC (RFC 7489). A cryptographic check of the DKIM signature is not possible, that would need the complete raw message including the body; the analyzer shows the result the receiving server recorded.

Common problems and how to fix them

dmarc=fail in the Authentication-Results. Either the mail really is forged, or a legitimate sending path has neither SPF alignment nor an aligned DKIM signature. Compare the signing d= domain of the DKIM-Signature with the From domain; if they differ, set up DKIM for your own domain at the sending service.
spf=softfail or spf=fail, but DKIM pass. Common after a forward: SPF breaks, DKIM survives it. As long as DMARC passes via DKIM, delivery is saved; the SPF record of the origin domain should still cover all direct sending paths.
Large delay between two Received hops. Shows where the mail was stuck: greylisting (typically 5 to 30 minutes), an overflowing queue or a slow virus or spam scanner. The hop with the jump names the responsible server.
Return-Path and From from different domains. Normal for newsletters and ticketing systems (the provider's bounce address). For personal mail a warning sign, then check the Received chain and the Authentication-Results closely.
Multiple From headers. No valid setup produces this. Treat the message with caution; many clients show only the first or last From, which is used deliberately for deception.

Common questions

Where do I find the raw header?: Outlook: File > Properties > Internet headers. Thunderbird: Ctrl+U (source). Gmail: message menu > Show original. Apple Mail: View > Message > All Headers. Paste the entire header area up to the first blank line.
Is my data transmitted?: No. The pasted text is only evaluated for display and not stored permanently. There is no DNS or other network query.
How do I read the Received chain?: From bottom to top: the bottom Received line is the first hop (connecting server), each line above it a later hop up to the target system. The delay per step shows where the mail lost time.
Why is my mail marked as spam, what does the header say?: The telling parts are the Authentication-Results (did SPF/DKIM/DMARC pass?), the receiver's spam headers (X-Spam-Status, SCL) and whether the connecting IP had clean reverse DNS. A dmarc=fail or a high SCL usually explains the classification directly.
Does the tool check the DKIM signature cryptographically?: No. It shows what is in the header, including the Authentication-Results of the receiving server. A real signature check would need the complete raw message with the body.
Why is there no TLS for some hops?: The header only reveals for visible hops whether TLS was used (for example with ESMTPS). If the note is missing, that hop did not record it; a safe conclusion of 'unencrypted' is not possible.