How To: Read an Email Header

In short. You are looking for mismatches. Walk the same fields on two messages that look identical in the inbox.

Open the headers first if you have not already.

Reading order

1. Authentication-Results — spf=, dkim=, dmarc=. In this simulator, genuine mail is pass/pass/pass and hostile mail is fail/fail/fail.
2. Return-Path versus From — same organisation, or a stranger carrying a familiar name?
3. Reply-To — would a reply leave the brand?
4. Received — a known mail host, or unknown / a lookalike?
5. DKIM-Signature — d= matching From, or missing / signed by someone else?

Real headers are noisier (ARC, extra hops, none). The game is simplified. A single fail is still a reason to slow down.

Example: Meridian

Both messages claim From: "Meridian Bank" <alerts@meridianbank.example>.

Statement (safe)

Return-Path: <alerts@meridianbank.example>
Reply-To: alerts@meridianbank.example
DKIM-Signature: ... d=meridianbank.example
Authentication-Results: spf=pass; dkim=pass; dmarc=pass
Received: from mail.meridianbank.example

Verify account (phish)

Return-Path: <bounce@mer1dian-alerts.example>
Reply-To: help@mer1dian-alerts.example
Authentication-Results: spf=fail; dkim=fail; dmarc=fail
Received: from unknown (mailer.mer1dian-alerts.example)

Same brand chip. Different envelope, Reply-To, authentication, and Received host. The digit 1 in mer1dian is the lookalike.

The same pattern shows up on invoices:

• Genuine Paperclip — Return-Path: accounts@paperclipdirect.example, pass results.
• Spoofed “final notice” — same From, Return-Path: pay@paperclip-secure.example, fail/fail/fail.

If DMARC already fails, you do not need the rest to quarantine. Extra fields explain why the From line is a lie — that is spoofing.