Somebody forwards you a suspicious email and asks whether it is real. The body is designed to fool you — the logo is right, the tone is right. The headers are not designed to fool you, because most attackers do not bother. That is where the answer is.

Paste any raw headers into the Email Header Analyzer and it will parse them locally in your browser. Nothing is uploaded.

Getting the raw headers

The headers are hidden by default in every mail client, and each one buries them somewhere different:

  • Gmail — open the message, three-dot menu, Show original.
  • Outlook (web) — three-dot menu, View, View message details.
  • Outlook (desktop) — File, Properties, read the Internet headers box.
  • Apple Mail — View, Message, All Headers.
  • Thunderbird — Ctrl+U for the source.

Copy everything from the top down to the first blank line. That blank line separates headers from body.

Read Received lines bottom to top

This catches everyone once. Received: headers are stacked in reverse: each server that handles the message adds its line at the top. So the oldest hop — the origin — is at the bottom, and the most recent is first.

Received: from mx.yourcompany.com by imap.yourcompany.com; Tue, 12 Aug 2026 09:14:22 +0000
Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47])
        by mx.yourcompany.com; Tue, 12 Aug 2026 09:14:19 +0000
Received: by mail-wr1-f47.google.com with SMTP id abc123; Tue, 12 Aug 2026 09:14:18 +0000

Read from the bottom: originated at Google's outbound servers, handed to your MX, delivered to your mailbox. Three hops, four seconds, consistent domains. Unremarkable — which is what legitimate mail looks like.

What is worth noticing: a hop in a country with no business reason to be involved, a gap of hours between two hops, or a bottom Received line whose hostname has nothing to do with the claimed sender.

Bear in mind that only the hops after the message entered infrastructure you trust are reliable. Anything below that can be fabricated, because the sender controls it. The first trustworthy line is the one added by your own mail provider.

Authentication-Results is where the answer usually is

Modern providers add a summary header after running the checks:

Authentication-Results: mx.yourcompany.com;
       spf=pass (sender IP is 209.85.221.47) smtp.mailfrom=realsender.com;
       dkim=pass header.d=realsender.com;
       dmarc=pass action=none header.from=realsender.com

Three verdicts. What matters is not just whether they pass, but which domains they passed for.

Look at this instead:

Authentication-Results: mx.yourcompany.com;
       spf=pass smtp.mailfrom=bounce.marketing-blast.ru;
       dkim=none;
       dmarc=fail action=quarantine header.from=yourbank.com

SPF passed — for marketing-blast.ru. DKIM is absent. And the From: the recipient sees says yourbank.com. That mismatch between smtp.mailfrom and header.from is exactly what DMARC exists to catch, and here it caught it.

A pass on its own means very little. A pass for the wrong domain is a finding.

Return-Path versus From

Return-Path: is the envelope sender — where bounces go, and what SPF actually checks. From: is the display address your recipient reads.

These legitimately differ all the time. Marketing platforms and ticketing systems routinely use their own bounce domain while displaying yours. So a mismatch is not proof of anything by itself — but combined with a DMARC failure it is close to conclusive.

The rest of the headers

Message-ID — a unique identifier assigned at origin, usually ending in the sending system's domain. If a message claims to be from a large provider but carries a Message-ID from an unrelated host, that is worth a second look.

Reply-To — a favourite trick. The From: shows the real company; Reply-To: quietly points at an attacker-controlled inbox. Your reply, and everything in it, goes to them. Always check this one on anything asking for information.

X- headers — non-standard, provider-specific. Spam scores, filtering verdicts, internal routing notes. Sometimes revealing, always inconsistent.

A thirty-second triage

  1. Read Authentication-Results. Did DMARC pass, and for which domain?
  2. Compare header.from against smtp.mailfrom. Do they align?
  3. Check Reply-To against From. Different? Why?
  4. Read the bottom Received line. Does the origin make sense for the claimed sender?
  5. Glance at the timestamps for implausible gaps.

That will resolve most cases. What it will not resolve is a message sent from a genuinely compromised account — everything aligns, everything passes, because as far as the protocol is concerned it is real mail. At that point you are looking at behaviour and content, not headers.

Common questions

Can email headers be faked?
Anything added before the message reached infrastructure you control can be forged. Headers added by your own provider — including Authentication-Results — are trustworthy.

Why do I read Received lines bottom to top?
Each server prepends its line, so the oldest hop ends up last in the list.

Does SPF pass mean the email is genuine?
No. It means the sending server was authorised for the envelope domain, which may be nothing like the From: the recipient sees.

Is it safe to paste headers into an online tool?
Depends on the tool. Ours parses them in your browser and uploads nothing — but headers can contain internal hostnames and recipient addresses, so it is a fair question to ask of anything you paste into.

Where to go next