How I read email headers when a message looks suspicious

An email header is the technical history of a message. It can show where the message claimed to come from, which servers handled it, and whether authentication checks passed.

The visible email body can be misleading. Headers are where I look when I need more context.

The Email Header Analyzer helps parse the raw header into something easier to read.

The simple idea

Think of an email as two parts:

visible message + delivery metadata

The visible message is what you read. The metadata is the header.

A raw header can look messy:

Received: from mail.example.com ...
Authentication-Results: ... spf=pass dkim=pass dmarc=pass
From: Example <billing@example.com>
Subject: Invoice
Date: ...

The analyzer groups this information so you do not have to read it as one giant block of text.

Step 1: get the original header

Most email apps have an option like:

• show original;
• view source;
• view message details;
• show raw message.

Copy the full header. Do not copy only the visible sender and subject. The useful technical fields are usually hidden by default.

Be careful with privacy. Email headers can contain addresses, server names, IPs, and tracking information. Avoid pasting sensitive real emails into tools you do not trust.

Step 2: paste into the analyzer

Open Email Header Analyzer and paste the raw header.

The tool will parse important sections such as:

• Received hops;
• From and Return-Path;
• authentication results;
• timestamps;
• delays between hops.

This makes the delivery path easier to inspect.

Step 3: compare From and Return-Path

The visible sender is usually the From header:

From: Example Billing <billing@example.com>

The bounce address may be in Return-Path:

Return-Path: <bounce@mailer.example.net>

They do not always have to match exactly. Many legitimate email platforms send on behalf of a domain. But if the visible sender says one company and the technical sender is unrelated, I look more carefully.

Step 4: read Received headers from bottom to top

Received headers show the servers that handled the message.

A confusing detail: new Received lines are usually added at the top. That means the earliest hop is often near the bottom.

So I read the chain roughly from bottom to top:

origin server -> intermediate servers -> my mail provider

I look for strange hops, unexpected domains, or time gaps.

Step 5: check SPF

SPF checks whether the sending server is allowed to send mail for a domain.

You may see:

spf=pass

or:

spf=fail

SPF pass is a good sign, but not a complete guarantee. SPF checks one part of email authentication. It does not prove the email body is safe.

Step 6: check DKIM

DKIM is a cryptographic signature added by the sender’s mail system.

You may see:

dkim=pass

Plain meaning:

The message has a valid DKIM signature for the signing domain.

This helps show that parts of the email were not changed after signing.

Again, pass does not mean “definitely safe”. It means that specific authentication check passed.

Step 7: check DMARC

DMARC ties SPF and DKIM to the visible sender domain policy.

You may see:

dmarc=pass

This is usually the most useful high-level authentication result.

If DMARC fails for a message claiming to be from a bank, payment provider, or company account, be careful.

Step 8: look at timing

Headers include timestamps for each hop. The analyzer can help show delays.

A delay does not automatically mean something is malicious. Email can be delayed for normal reasons. But timing can help explain why a message arrived late or where it waited.

Step 9: do not trust one signal alone

A suspicious email is judged from multiple signals:

• sender domain;
• reply-to address;
• links in the email;
• SPF, DKIM, DMARC results;
• attachment type;
• message content;
• urgency or pressure tactics;
• whether you expected the email.

Headers help, but they are not the only thing to inspect.

My email header checklist

When an email looks suspicious, I check:

1. What is the visible From address?
2. What is the Return-Path?
3. What domains appear in Received hops?
4. Did SPF pass?
5. Did DKIM pass?
6. Did DMARC pass?
7. Is the reply-to address different or strange?
8. Are there unexpected delays or relays?
9. Do the links and attachments make sense?

The main lesson is simple:

The email body tells you what the sender wants you to believe. The header shows more of how the message actually travelled.