Every email carries its own flight recorder. Hidden above the message you read is the full forensic record: every server it passed through, when, what each one thought of the sender, and which security checks passed or failed. When something goes wrong — delays, spam placement, a suspicious message — the headers usually contain the entire answer.

Most people never look, because raw headers are genuinely ugly. Five concepts fix that.

Getting the headers

Gmail: open the message → three-dot menu → Show original.
Outlook: open the message → … → View → View message source.

You’ll get a wall of text. Copy all of it — and either read on, or paste it into our free Email Header Analyzer, which renders the verdicts and the route as a table, in your browser, nothing uploaded.

1. The Received chain reads bottom-to-top

Each server that handles a message stamps a Received: header on top of the existing ones. So the bottom Received is the origin — the server closest to the sender — and the top is the final delivery. Read it bottom-up and you have the route.

Two things to extract:

The origin. Does the first hop make sense for the claimed sender? An invoice “from your bank” that originates at a residential ISP in another country has already told you everything.
The timestamps. Subtract each hop from the next. The route should take seconds. A gap of minutes or hours at one hop is where your “email was slow” mystery lives — typically greylisting (a deliberate first-attempt rejection forcing a retry), rate limiting, or an overloaded queue.

2. Authentication-Results is the verdict line

Near the top you’ll find the receiving server’s own scorecard:

Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=example.com;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

This is the receiver telling you, in one line, how SPF, DKIM and DMARC scored the message. For your own mail, this line is the ground truth of your setup — send yourself a test and read it. The classic find: dkim=pass but on header.d=yoursendingtool.com instead of your domain — a valid signature that does nothing for your alignment.

3. From vs Return-Path: the two-sender trick

From: is what the recipient sees; Return-Path is the envelope address the SMTP conversation actually used. They legitimately differ (most sending platforms route bounces through their own domain) — but the combination of a mismatched Return-Path, a Reply-To pointing at a third, unrelated domain, and failing authentication is the standard anatomy of a phish.

4. The minor headers that talk

Message-ID — its domain should roughly match the sending org.
X-Mailer / User-Agent — what software sent it; bulk tools announce themselves here.
Received-SPF — SPF’s working notes, useful when the verdict line is terse.
A hop with tls or ESMTPS in its Received line was encrypted in transit; whether your own domain enforces that is a separate check — our MTA-STS & TLS-RPT Checker reads the policy in one pass.

The five-minute diagnostic, assembled

Delivery mystery? Pull headers and ask, in order: where did it originate (bottom Received) → where did it stall (timestamp gaps) → what did the receiver verify (Authentication-Results) → do the sender identities agree (From / Return-Path / Reply-To / Message-ID)? To identify any mystery server along the way, our DNS Lookup resolves it both directions.

That’s the whole skill. The flight recorder was always on — postmasters just know where the panel is.