Email Header Analyzer

What an email header tells you

Every email arrives with dozens of headers describing its path, identity, and how various filters scored it. The body is what the recipient reads; the headers are the metadata everyone but the recipient cares about. Spam filters, deliverability auditors, and forensic investigators all start by reading headers.

Paste raw headers here and the tool extracts the parts that matter: the sender's claimed identity, the actual delivery path (every server that handled the message), authentication results (SPF/DKIM/DMARC pass/fail), and anti-spam scores when present. All parsing happens in your browser — nothing is uploaded.

The Received chain — reading delivery path backwards

Every mail server that handles a message prepends its own Received: header. The result is a stack of headers showing the message's path in reverse chronological order — the topmost is the most recent (the receiving server), the bottom-most is the origin. Reading them from bottom to top traces the message from sender to receiver.

Each Received line typically contains: from <claimed-name> (<real-name> [<ip>]), by <receiving-server>, with <protocol>, and a timestamp. The "claimed name" comes from the SMTP HELO/EHLO greeting — anyone can claim anything. The "real name" is the reverse-DNS lookup the receiving server did against the connecting IP — that's verifiable. When claimed and real disagree, that's a flag.

Authentication-Results — pass/fail for SPF/DKIM/DMARC

The receiving server inserts an Authentication-Results: header summarizing what it found:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@stripe.com header.s=stripe header.b=abc123;
       spf=pass (google.com: domain of bounce@stripe.com designates 54.x.x.x as permitted sender) smtp.mailfrom=bounce@stripe.com;
       dmarc=pass (p=REJECT sp=NONE dis=NONE) header.from=stripe.com

The three verdicts can be pass, fail, softfail, neutral, none, or temperror / permerror. For legitimate mail, all three should be "pass"; anything else is grounds for spam-folder placement under modern policies.

Headers worth scanning for

• From, Reply-To. The "From" can be cosmetically anything — receivers display this. "Reply-To" overrides where responses go. Phishing often uses lookalike From + real Reply-To pointing to attacker domain.
• Return-Path / envelope-from. The actual bounce address used in the SMTP MAIL FROM command. This is what SPF authenticates against — NOT the displayed From.
• Message-ID. Unique identifier set by the originating server. Format: <random@domain>. Useful for log correlation and tracing conversations across threads.
• X-Mailer, User-Agent. What client composed the message. Suspicious if a "company support" email comes from a random IP using Outlook Express 6.
• X-Spam-Score, X-Spam-Status. Anti-spam engine scores. Each receiver uses their own; reading these helps you understand why a message was filtered.
• List-Unsubscribe, List-Unsubscribe-Post. One-click unsubscribe headers required by Gmail/Yahoo as of 2024 for bulk senders. Missing = spam folder.

Common spoofing patterns to spot

• Mismatched From and Return-Path. Real mail from a domain has matching (or aligned) values. A From of @yourbank.com with a Return-Path of @bounce-7821.suspicious.tk is a giant flag.
• SPF / DKIM / DMARC all failing or absent. Major senders have all three. Authentication results showing "none" or "fail" across the board suggests the sender doesn't control the claimed domain.
• Received chain doesn't include the claimed sender's infrastructure. If the From is @google.com, the chain should include Google's mail servers. If the message originated from a random VPS, it's not really from Google.
• Recent domain registration. Not in headers directly, but easy to check separately — phishing domains are often <1 month old at time of send.
• Lookalike domains. @paypa1.com, @arnazon.com, Unicode lookalikes. Read the domain character-by-character on suspicious messages.