How to Read Email Headers

Understand what the envelope of the email means.

North Engineer

04 Mar 2026 — 6 min read

Email headers tell the complete story of a message's journey from sender to your inbox. They reveal the servers involved, authentication results, spam scores, and timestamps at each hop. Understanding how to read them is essential for troubleshooting delivery problems, verifying sender authenticity, and investigating suspicious messages.

Most people never look at email headers. That's unfortunate, because they contain information that's invisible in the normal email view—information that can tell you whether a message is legitimate or a phishing attempt.

Accessing Email Headers

Before we can read headers, we need to see them. Every email client hides them by default.

Gmail (Web):
Open the message → Click the three dots menu → Select "Show original"

Outlook (Desktop):
Open the message → File → Properties → Look in the "Internet headers" box

Outlook (Web):
Open the message → Click the three dots → View → View message details

Apple Mail:
View menu → Message → All Headers (or press ⌘⇧H)

Thunderbird:
View menu → Headers → All

Android & iOS Mail:
Unfortunately, these do not provide header access. You'll need to access the message to a desktop client or use a third-party app.

The Structure of Email Headers

Headers follow a simple format: Header-Name: value. Each header occupies one or more lines, with continuation lines starting with whitespace.

From: North Engineer <the@north.engineer>
To: recipient@example.com
Subject: Test message
Date: Mon, 3 Feb 2026 10:30:00 -0500

Critical concept: Headers are added in reverse chronological order. The most recent header is at the top, and the original headers from the sender are at the bottom. To trace an email's path, read from bottom to top.

Essential Headers

From, To, Subject, Date

These are the headers you see in your email client's normal view:

From: North Engineer <the@north.engineer>
To: recipient@example.com
Cc: another@example.com
Subject: Project Update
Date: Mon, 3 Feb 2026 10:30:00 -0500

Important: The "From" header is trivially easy to forge. Never trust it alone as proof of sender identity. That's why authentication headers exist.

Message-ID

A unique identifier for the message, typically generated by the sending server:

Message-ID: <abc123.456@mail.forthright.engineer>

This should be globally unique. The format usually includes a random string, the date/time, and the sending server's domain. Message-IDs are useful for tracking replies (via the In-Reply-To and References headers) and for identifying duplicate messages.

Received Headers

These are the most important headers for tracing an email's path. Each server that handles the message adds a Received header at the top, creating a chain you can follow.

Received: from mail-sor-f41.google.com (mail-sor-f41.google.com [209.85.220.41])
        by mx.example.com with ESMTPS id abc123
        for <recipient@example.com>;
        Mon, 3 Feb 2026 10:30:05 -0500 (EST)

Breaking this down:

from mail-sor-f41.google.com - The server that sent to this one (with its claimed identity and actual IP)
by mx.example.com - The server that received and added this header
with ESMTPS - The protocol used (ESMTPS means encrypted SMTP)
for <recipient@example.com> - The intended recipient at this hop
The timestamp shows when this server received the message

Reading the chain: Start at the bottom Received header (the origin) and work up to the top (your mail server). You can see every server the message passed through and how long each hop took.

Authentication-Results

This header summarizes SPF, DKIM, and DMARC verification results:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@north.engineer header.s=selector1 header.b=abc123;
       spf=pass (google.com: domain of the@north.engineer designates 192.0.2.1 as permitted sender) smtp.mailfrom=the@north.engineer;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=north.engineer

What to look for:

dkim=pass - The DKIM signature verified correctly
spf=pass - The sending IP was authorized
dmarc=pass - Both SPF/DKIM passed AND aligned with the From domain

If any of these show fail, investigate further. Legitimate senders occasionally have misconfigured authentication, but failed authentication on important messages should raise suspicion.

DKIM-Signature

The actual cryptographic signature added by the sending server:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=north.engineer; s=selector1; t=1706968200;
        h=from:to:subject:date:message-id:mime-version;
        bh=base64bodyHash;
        b=base64signature

Key fields:

d= - The signing domain (should match or align with the From address)
s= - The selector (identifies which key to look up in DNS)
h= - List of headers that were signed (these can't be modified without breaking the signature)
t= - Timestamp when the signature was created

X-Spam Headers

Most mail servers add spam scoring headers. The format varies by system:

SpamAssassin:

X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,SPF_PASS autolearn=ham
X-Spam-Score: -2.1

Google:

X-Gm-Spam: 0
X-Gm-Phishy: 0

Lower scores mean the message is more likely legitimate. The tests= field shows which rules triggered.

Return-Path

The address where bounce notifications should be sent:

Return-Path: <bounces@north.engineer>

This is set by the sending server and may differ from the From address. Mailing lists, for example, set Return-Path to their bounce handler while keeping your address in From.

X-Originating-IP

Some mail services add the IP address of the client that submitted the message:

X-Originating-IP: [192.0.2.50]

This can reveal the geographic location of the sender, which is useful for detecting account compromises—if someone in your company supposedly sent an email but the originating IP is in a different country, that's a red flag.

ARC Headers for Forwarded Mail

When email passes through intermediaries (mailing lists, forwarding services), ARC headers preserve the original authentication state:

ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass header.d=forthright.engineer;
       spf=pass smtp.mailfrom=forthright.engineer;
       dmarc=pass header.from=forthright.engineer

The i= value shows the hop number. Each forwarder increments this and adds their own ARC headers. This allows the final recipient to see that the message was properly authenticated before it was forwarded.

Practical Analysis: Tracing an Email's Journey

Here's how to analyze headers step by step:

1. Find the origin:
Scroll to the bottom of the headers. The first Received header (from the bottom) shows where the message originated.

2. Trace the path:
Work upward through the Received headers. Note each server and timestamp. Calculate the time between hops—unusual delays might indicate queueing issues or suspicious routing.

3. Check authentication:
Look at Authentication-Results. All three (SPF, DKIM, DMARC) should pass for legitimate business email. Consumer email sometimes lacks DKIM, but corporate/transactional email should have it.

4. Verify the sender:
Compare the From header with the d= domain in DKIM-Signature and the DMARC alignment. They should match or be subdomains of each other.

5. Check for anomalies:

Does the originating IP make geographic sense?
Are there unexpected servers in the path?
Do timestamps progress logically?
Are spam scores elevated?

Red Flags in Email Headers

Authentication failures on "important" emails:
If your bank or employer supposedly sent an email but DKIM/SPF/DMARC fail, be very suspicious.

Mismatched domains:
The From address says security@bigbank.com but DKIM is signed by d=randomserver.com.

Multiple Received headers from consumer ISPs:
Legitimate corporate email doesn't typically bounce through residential internet providers.

Missing or minimal headers:
Professional email infrastructure adds consistent headers. Sparse headers might indicate a hastily configured phishing operation.

Timestamps that don't make sense:
A message that shows it spent 3 days bouncing between servers before arriving is suspicious.

Tools for Header Analysis

For complex headers, online analyzers can help visualize the path:

Google Admin Toolbox: https://toolbox.googleapps.com/apps/messageheader/
MXToolbox: https://mxtoolbox.com/EmailHeaders.aspx
Mail Header Analyzer: https://mha.azurewebsites.net/

These tools parse the headers and display them in a more readable format, showing the path graphically and highlighting potential issues.

Closing Thoughts

Email headers are the audit trail of electronic communication. They can't be easily forged at scale because each legitimate server in the chain adds its own Received header and authentication results.

Learning to read them takes practice, but it's a skill that pays off. When you receive a suspicious message, the headers will tell you whether it's genuine faster than any other method. When email isn't being delivered, the headers show you exactly where in the chain it's failing.

The next time someone tells you they sent an important email that you never received, ask for the headers. The answer is usually in there.

Footnotes:

[1] Internet Message Format (RFC 5322): https://datatracker.ietf.org/doc/html/rfc5322
[2] Email Authentication Best Practices: https://support.google.com/a/answer/81126
[3] Microsoft Message Header Analyzer: https://mha.azurewebsites.net/