Free Email Header Analyzer

An email header tells you who really sent a message, where it actually came from, every server it touched on the way, and whether it survived authentication along the way. The body is what someone wrote. The header is what the protocol recorded. They don't always agree — that's the whole reason analyzers like this one exist.

This page combines the analyzer (paste headers or drop a `.eml` file at the top) with a full read-through of what each field means, how to recognize a spoof attempt by eye, and how to think about the answers you get. If you arrived because an email looked suspicious, the analyzer above gives you a verdict in seconds. If you want to learn enough to do it yourself, keep reading.

What an email header actually contains

Every email message has two parts: a header block and a body, separated by a single blank line. The header block is plain text, one field per line, formatted as `Field-Name: value`. Most of the famous fields (From, To, Subject, Date) are written by the sender's mail client. Almost everything else is added by mail servers as the message moves through the network.

RFC 5322 (which replaced RFC 2822, which replaced RFC 822) is the spec that defines the format. It's not a complicated spec — fields can fold onto multiple lines if a value gets long, certain field names are reserved, and the order doesn't matter except for `Received:` lines, which servers prepend to the top as they handle the message. That last detail is why `Received:` headers read newest-first when you scroll down a raw email.

The headers most worth knowing:

How to find email headers in your mail client

Every mail client buries this somewhere. Here are the paths for the five clients people search for most. Once you have the raw text, paste it into the box at the top of this page.

Gmail (web)

• Open the message.
• Click the three-dot menu in the upper-right of the message (next to the Reply arrow).
• Choose "Show original." A new tab opens with the raw message.
• Copy everything in the "Original Message" block, or click "Download Original" to grab the `.eml`.

Outlook (Microsoft 365, web + new desktop)

• Open the message in its own window (double-click it).
• Go to File → Properties.
• Scroll to Internet headers — that's the header block. Select all + copy.
• For the full `.eml` instead: drag the message out of Outlook onto your desktop. That saves it as `.msg` — rename to `.eml` if your tool needs `.eml`, or use the analyzer's paste mode with the visible headers.

Apple Mail (macOS + iPadOS)

• Open the message.
• Go to View → Message → All Headers (or press Cmd+Shift+H).
• Select the now-visible header text and copy. Alternatively View → Message → Raw Source gives you the full `.eml`.

Yahoo Mail (web)

• Open the message.
• Click the More menu (three dots).
• Choose View raw message. Copy everything.

Thunderbird

• Open the message in its own window.
• Go to View → Headers → All to show every header inline.
• For the raw source: View → Message Source (Ctrl+U).

Reading the Received: chain (with a worked example)

The `Received:` headers are the most useful field in any message. Each one is stamped by an MTA (mail transfer agent — basically any mail server) as the message arrives. The newest server stamps the topmost `Received:` and the originating server is at the bottom. Read bottom-up to see the chronological path.

A typical line looks like this:

Received: from mail-pf1-f175.google.com (mail-pf1-f175.google.com. [209.85.210.175])
        by mx.example.com with ESMTPS id abc123
        for <you@example.com>; Wed, 17 Jan 2024 14:23:01 -0500

Decoded:

• `from mail-pf1-f175.google.com (...)` — what the previous server claimed to be. The hostname before the parens is the HELO/EHLO it announced. Inside the parens is what the receiving server resolved via reverse-DNS, plus the bracketed IP `[209.85.210.175]`. The receiver-verified parts are trustworthy; the HELO is forgeable.
• `by mx.example.com` — the server adding this line.
• `with ESMTPS` — the protocol. `SMTP` is plain text, `ESMTP` is Extended SMTP without TLS, `ESMTPS` adds TLS, `ESMTPSA` adds TLS plus authentication, `HTTP` shows up for webmail-injected mail.
• `id abc123` — the receiving server's queue ID. Useful when correlating with mail server logs.
• `for <you@example.com>` — the SMTP envelope recipient (sometimes omitted for privacy).
• `; Wed, 17 Jan 2024 14:23:01 -0500` — when this server received the message. Compare timestamps across hops to spot delays.

If you see a long gap between two hops (say, 47 minutes), it usually means the next server in line greylisted the message (temporarily refused it on first try to filter spam). Spammers don't retry; legitimate senders do. Greylisting delays are normal.

SPF, DKIM, DMARC — and what failure modes actually mean

The `Authentication-Results:` header is where the receiving server records what happened when it checked the sender's published authentication policies. The three checks most worth understanding:

SPF (Sender Policy Framework)

SPF answers: "Is the IP that just delivered this message allowed to send mail for the return-path domain?" The receiving server takes the return-path domain (the envelope sender, NOT the From: address), looks up its SPF record in DNS, and checks whether the connecting IP is listed. Results:

DKIM (DomainKeys Identified Mail)

DKIM answers: "Was this message cryptographically signed, and does the signature verify?" The sender's MTA signs selected headers and the body with a private key, and publishes the matching public key in DNS at `<selector>._domainkey.<domain>`. The receiver fetches the public key and verifies. If anything in the signed portion changed in transit, the signature fails.

Failure causes, in rough order of frequency:

• Footer injection — a corporate gateway or mailing-list software added a disclaimer or unsubscribe footer after signing.
• Body re-encoding — a server along the way converted line endings or character encoding.
• Public key missing — the selector record was never published, was removed, or has a typo. Check it with our DKIM Record Checker.
• Signing the wrong headers — the sender included headers in the signature that get rewritten downstream (Subject often).

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC sits on top of SPF and DKIM. It asks one specific question: "Does the domain in the From: header line up with the domain that SPF and/or DKIM verified?" If at least one of them aligns, DMARC passes. The published DMARC policy (`p=none`, `p=quarantine`, or `p=reject`) tells receivers what to do when DMARC fails.

Three things commonly cause DMARC failure even when SPF/DKIM individually pass:

• Subdomain alignment — your From: is `marketing.example.com` but you sign with `example.com`. If your DMARC record uses `adkim=s` (strict), this fails. Switch to `adkim=r` (relaxed).
• Different organizations — your ESP signs with their own domain (sendgrid.net) instead of yours. Most ESPs let you configure custom DKIM — turn it on.
• Different return-path — your mail goes through a relay that uses its own bounce address. SPF passes for the relay's domain but doesn't align with your From:.

When you receive DMARC reports from receivers, our DMARC Report Analyzer breaks them down per-source. Before publishing a new DMARC record, validate it with our DMARC Record Checker.

ARC — when forwarded mail looks like it failed (but didn't)

ARC stands for Authenticated Received Chain. It exists because forwarding breaks authentication: when a mailing list, .edu alias, or corporate forwarding rule relays a message, the original SPF/DKIM signatures often break (SPF because the relay's IP isn't in the original sender's SPF record; DKIM if the relay modifies the body). DMARC then fails. But the message is legitimate.

ARC fixes this. Each forwarder along the path adds three headers — `ARC-Authentication-Results`, `ARC-Message-Signature`, `ARC-Seal` — sealing what the auth state was when it received the message. The final receiver can validate the chain and choose to honor the original auth results, even though SPF/DKIM technically broke at the relay.

If you see ARC headers in a message and `Authentication-Results` shows DMARC failed, look at the ARC chain. A `cv=pass` seal on the latest ARC instance means a forwarder vouched for the message and the receiver can trust the original sender. ARC adoption isn't universal yet — Google, Microsoft, and Yahoo support it; smaller receivers often don't.

Spotting a spoofed email by reading the headers

Phishing works because most people only read From: and Subject. A few minutes with the headers reveals the most common attacks. Here's a real-style example — what you'd see in a spoof targeting PayPal users:

From: "PayPal Security Team" <noreply@paypal-security.tk>
Reply-To: support-team-29481@gmail.com
Return-Path: <bounce@paypal-security.tk>
Subject: Urgent: Your account has been limited
Authentication-Results: mx.google.com;
        spf=fail (google.com: domain of bounce@paypal-security.tk
            does not designate 185.234.219.77 as permitted sender)
            smtp.mailfrom=bounce@paypal-security.tk;
        dkim=none;
        dmarc=fail (p=NONE sp=NONE dis=NONE)
            header.from=paypal-security.tk

Five red flags in those nine lines:

• Display name says "PayPal" but domain is `paypal-security.tk` — PayPal's real email comes from `paypal.com` or `paypal.de` etc. The .tk TLD is free, anonymous, and disproportionately used for phishing.
• Reply-To is a Gmail address — totally inconsistent with a corporate sender. Replying would route your response to the attacker, not to PayPal.
• Return-Path is on the spoofed domain — meaning bounces go to the attacker, where they'll be ignored.
• SPF failed — the sending IP isn't in the spoofed domain's SPF record. Spammers rarely bother configuring SPF.
• DKIM is `none` — no signature, so no cryptographic proof of origin.

Any one of these is suspicious. All five together is definitively a phishing attempt. The analyzer at the top of this page surfaces each of these as a separate flagged finding so you don't have to spot them yourself.

Complete header glossary

Every field you'll encounter in a typical message, plus what each piece of a DKIM-Signature actually means.

Address headers

Identity + tracing

Authentication headers

Decoding a DKIM-Signature header

DKIM signatures are a soup of `key=value` tags. The important ones:

List-* headers (mailing lists)

X-* headers (vendor-specific)

Anything starting with `X-` is non-standard, added by a specific vendor. A short list of ones the analyzer decodes:

• `X-Spam-Status`, `X-Spam-Score`, `X-Spam-Flag` — SpamAssassin verdict + numeric score (≥5 = spam by default).
• `X-Forefront-Antispam-Report` — Microsoft Defender breakdown. Includes `CAT:` (category), `SCL:` (spam confidence 0-9).
• `X-MS-Exchange-Organization-SCL` — Microsoft Spam Confidence Level (-1 trusted, 0-4 clean, 5-6 likely spam, 7-9 high-confidence spam).
• `X-Gm-Spam`, `X-Gm-Phishy` — Google's spam/phishing flags.
• `X-Mailer` — software that composed the message (Outlook, iPhone Mail, Mailchimp, etc.).
• `X-Originating-IP` — the IP of the user who composed the message, when set.

Privacy — your headers stay in your browser

Email headers carry sensitive information: recipient lists, internal server names, originating IPs, queue IDs, and sometimes user identifiers in `X-` headers. Pasting them into a third-party SaaS analyzer means handing all of that over.

This tool runs entirely in your browser tab. Parsing is JavaScript executing on your machine. The `.eml` file you drop in is read into the browser's memory, not uploaded. There is no network request to our servers when you analyze a message. The only time we touch the network is if you toggle on the optional "compare against live DNS records" feature — and that only fetches the public SPF and DMARC records for the sender's domain via standard DNS-over-HTTPS, which any DNS lookup does.

When you export the analysis as JSON or plain text, the file is generated in your browser and downloaded to your machine via a blob URL. We never see the contents.