# How I read email headers when a message looks suspicious

A beginner-friendly guide to email headers, delivery hops, SPF, DKIM, DMARC, timestamps, and using an Email Header Analyzer safely.

- Date: 2026-09-27
- URL: https://ilham.dev/posts/how-to-read-email-headers/
- Markdown: https://ilham.dev/posts/how-to-read-email-headers/index.md
- Tags: email, security, headers, tools
- Reading time: 4 min


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](/tools/email-header-analyzer/) helps parse the raw header
into something easier to read.

## The simple idea

Think of an email as two parts:

```text
visible message + delivery metadata
```

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

A raw header can look messy:

```text
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](/tools/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:

```text
From: Example Billing <billing@example.com>
```

The bounce address may be in `Return-Path`:

```text
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:

```text
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:

```text
spf=pass
```

or:

```text
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:

```text
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:

```text
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.