b2KIT

Email Header Analyzer

Parse and analyze email headers to trace delivery path, check SPF/DKIM/DMARC, and detect spoofing indicators.

Tested tool guide Tested browser tools Checked August 16, 2026

What Email Header Analyzer does and how it behaves

Paste a raw email header to turn its Received fields, sender identities, timestamps, and authentication records into a readable delivery and trust summary. The analyzer reconstructs the apparent relay path and highlights reported SPF, DKIM, and DMARC outcomes or suspicious inconsistencies. A common mistake is treating every header line as independently trustworthy. Messages can arrive with forged fields, and authentication results are meaningful only when they were added by a receiver you trust. Header contents are processed in the browser and are not uploaded.

How the result is produced

1

Delivery path

The analyzer reads the Received fields that mail servers prepend as a message travels. Because each new entry is normally added above earlier entries, the raw header presents the newest hop first. The resulting view helps connect reported host names, IP addresses, protocol details, and timestamps while making gaps or abrupt changes easier to notice.

2

Authentication evidence

Authentication-Results and related fields are parsed to expose recorded SPF, DKIM, and DMARC outcomes. The analyzer also compares identities such as the visible From address, envelope sender, and DKIM signing domain where those values appear. It reports evidence contained in the header; a recorded result is not necessarily a fresh DNS lookup or an independent cryptographic verification.

Good uses

  • Review a suspicious message for mismatched sender domains, unexpected relays, or authentication failures before responding.
  • Trace where a delayed message appears to have spent time by comparing timestamps across its Received entries.
  • Inspect a delivered campaign message to see which SPF, DKIM, and DMARC results the receiving system recorded.

Limits and checks

  • Received lines below the first trusted mail system may have been supplied or forged by the sender, so the apparent earliest hop is not conclusive.
  • SPF authenticates an envelope-sender or related identity, while the address shown in From can be different; an SPF pass alone does not validate the visible author.
  • Authentication-Results is trustworthy only when added by a mail system whose boundary you recognize. Attackers can insert look-alike result fields before delivery.

Common questions

Can the analyzer prove who sent an email?

No. It can organize routing claims and authentication evidence, but headers do not establish a person's identity. A trusted receiver's DKIM or DMARC result can support a conclusion about domain authorization and alignment. It does not prove which individual composed the message, and forwarded or modified mail can complicate otherwise legitimate results.

Does a DMARC pass mean the message is safe?

No. A DMARC pass indicates that the receiver reported acceptable domain alignment through SPF or DKIM. It does not inspect whether the message is truthful, harmless, or wanted. A malicious sender can authenticate a domain they control, and a compromised legitimate account can send authenticated phishing mail.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools