How to Read and Analyze Raw Email Headers

1. What are Email Headers? The Hidden Story Behind Every Message

Every email you've ever received contains a hidden treasure trove of information: the email headers. While you see the friendly "From," "To," "Subject," and "Date" fields in your email client, the raw headers contain dozens of additional fields that tell the complete story of your email's journey across the internet.

Think of email headers as the flight data recorder of your message. They record:

• Exactly which servers handled the email and in what order
• Authentication results proving (or disproving) the sender's identity
• Timestamps showing how long each hop took
• Technical details about the message format and encoding
• Anti-spam scores and filtering decisions

For email administrators, marketers, and security professionals, reading headers is an essential skill. Headers help you diagnose delivery problems, investigate spoofing attempts, prove email authenticity, and understand why legitimate messages sometimes end up in spam folders.

2. Headers vs. Body: Understanding the Separation

Every email message has two distinct parts separated by a blank line:

The Header Section

The header comes first and contains metadata about the message. Headers use a "field: value" format, with each header on its own line:

From: "Company Name" 
To: customer@gmail.com
Subject: Your Weekly Newsletter
Date: Tue, 2 Jun 2026 10:30:00 -0400
Message-ID: <abc123@mail.example.com>
Received: from mail.example.com (192.0.2.45) by mx.google.com...

The Body Section

After the headers, a single blank line separates the headers from the message body. The body contains the actual content the recipient reads—text, HTML, images, and attachments.

Why This Separation Matters

Understanding this separation is crucial for troubleshooting. When you "show original" or "view source" of an email, you're seeing the complete message with headers and body. Email clients hide the headers by default because they're technical—but when something goes wrong, headers provide the answers.

3. How to View Headers in Gmail, Outlook, and More – A Client-by-Client Guide

Different email clients hide headers in different places. Here's how to access them in the most popular platforms:

Gmail (Web)

1. Open the email you want to analyze
2. Click the three dots (More) menu next to the Reply button
3. Select "Show original"
4. A new tab opens showing the full raw message with headers

Outlook (Desktop)

1. Double-click the email to open it in its own window (not the reading pane)
2. Go to File → Properties
3. Look for the "Internet headers" box at the bottom of the Properties window
4. Select all text, copy, and paste into a text editor for analysis

Outlook.com / Office 365 (Web)

1. Open the email
2. Click the three dots (Actions) menu
3. Select "View" → "View message details"
4. A popup shows the full headers

Apple Mail (macOS)

1. Open the email
2. Go to View → Message → Raw Source
3. Or use the keyboard shortcut: Command + Option + U

Yahoo Mail

1. Open the email
2. Click "More" (three dots next to Spam/Delete buttons)
3. Select "View Raw Message"

4. Understanding Header Format and Syntax – Reading the Technical Language

Email headers follow a specific syntax defined in internet standards (RFC 5322). Once you understand the pattern, headers become easy to read.

Basic Format

Each header consists of a field name, a colon, a space, and a value:

Field-Name: value

Multi-Line Headers

Some header values are too long for a single line. When this happens, subsequent lines start with whitespace (space or tab):

Received: from mail.example.com (mail.example.com [192.0.2.45])
        by mx.google.com with ESMTPS id abc123
        for ;
        Tue, 2 Jun 2026 10:30:05 -0400 (EDT)

Folding Whitespace

That leading whitespace isn't part of the value—it's a continuation marker. When parsing headers, you should join lines by removing the line break and whitespace.

Common Field Naming Conventions

• Standard fields: From, To, Subject, Date, Message-ID
• Trace fields: Received, Return-Path
• Authentication fields: DKIM-Signature, Authentication-Results
• Content fields: Content-Type, Content-Transfer-Encoding
• Custom fields: X-* (e.g., X-Spam-Status, X-Mailer)

5. The Most Important Header Fields Explained – Your Troubleshooting Toolkit

While emails contain many headers, a handful are most important for everyday troubleshooting and analysis.

From

Shows the displayed sender address. Important warning: This field is easily forged. Don't trust it alone—always check authentication results.

From: "Company Newsletter" 

To / Cc / Bcc

Recipient addresses. Note that Bcc addresses don't appear in headers sent to other recipients.

Subject

The email's subject line. Spammers often exploit this, so unusual subjects warrant suspicion.

Date

When the email was sent, according to the sender's mail server. Timezone information is included.

Date: Tue, 2 Jun 2026 10:30:00 -0400

Message-ID

A globally unique identifier assigned by the first mail server. Every email has a different Message-ID. This is useful for tracking specific emails and for threading conversations.

Message-ID: <abc123.456789@mail.example.com>

In-Reply-To / References

Used for email threading. These headers contain the Message-ID of previous messages in the conversation.

Return-Path (or Envelope-From)

The address where bounce messages (delivery status notifications) are sent. Often different from the From header, especially for mailing lists.

Return-Path: 

Reply-To

When present, this tells email clients where replies should be sent—useful for newsletters or customer support addresses.

Sender

Indicates the actual sender when the From header shows a different address (common in mailing lists).

Content-Type

Describes the format of the email body. Common values: text/plain (plain text), text/html (HTML email), multipart/alternative (both plain and HTML).

Content-Transfer-Encoding

How the body is encoded for transmission (e.g., quoted-printable, base64, 7bit).

6. Authentication Headers: SPF, DKIM, and DMARC Results – Verifying Sender Identity

Authentication headers are your primary defense against spoofing and phishing. They record the results of checks that verify the email actually came from who it claims to come from.

Authentication-Results

This header is added by the receiving mail server and summarizes the results of all authentication checks. It's usually the first thing to check when analyzing an email's authenticity.

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of example.com designates 192.0.2.45 as permitted sender) smtp.mailfrom=example.com;
       dkim=pass header.i=@example.com;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com

In this example, all three authentication methods passed—the email is almost certainly legitimate.

SPF Results (in Authentication-Results)

• pass: The sending IP is authorized in the domain's SPF record
• fail: The sending IP is NOT authorized—likely spoofed or misconfigured
• softfail: The domain says it's probably not authorized (~all condition)
• neutral: The domain didn't state a policy
• none: No SPF record exists for the domain
• permerror: The SPF record is malformed (e.g., too many DNS lookups)

DKIM Results

• pass: The DKIM signature is valid and matches the domain
• fail: The signature doesn't verify (message was altered or signed with wrong key)
• none: No DKIM signature present
• permerror: The DKIM signature is malformed

DMARC Results

• pass: SPF or DKIM passed AND the domain in the From header aligns
• fail: Neither SPF nor DKIM passed with alignment
• bestguesspass: Would have passed with a stricter DMARC policy

DKIM-Signature Header

The actual DKIM signature is stored in its own header. Key fields include:

• v= Version (usually 1)
• a= Signing algorithm (e.g., rsa-sha256)
• c= Canonicalization method
• d= Signing domain (this is critical)
• s= Selector (points to where the public key is published in DNS)
• t= Timestamp of signature
• bh= Body hash (proves body wasn't altered)
• h= Headers that were signed
• b= The actual signature

7. Tracing Email Routes with Received Headers – Following the Breadcrumbs

Received headers record every hop an email takes from the sender's computer to your inbox. Analyzing them helps identify delivery delays, routing problems, and suspicious relays.

The Anatomy of a Received Header

Received: from mail.example.com (mail.example.com [192.0.2.45])
        by mx.google.com with ESMTPS id abc123
        for ;
        Tue, 2 Jun 2026 10:30:05 -0400 (EDT)

• from: The server that sent the email (or the claimed sending host)
• by: The server that received the email (adding this header)
• with: The protocol used (ESMTP, LMTP, HTTP, etc.)
• id: An identifier for the connection or transaction
• for: The recipient (not always present)
• timestamp: When this hop occurred

Reading Received Headers in Order (Bottom to Top)

Received headers are added at the top of the header stack. Therefore, to trace the email's path from sender to receiver:

1. Start at the bottom-most Received header – This is the originating server
2. Work your way up – Each subsequent header shows the next hop
3. The top-most Received header – Shows the final receiving server (your email provider)

Example Trace

Received: from mx.google.com (209.85.220.41) by outlook.com (Bottom: Your receiving server's hop)
Received: from mail.example.com (192.0.2.45) by mx.google.com (Middle: Google's hop)
Received: from localhost (127.0.0.1) by mail.example.com (Top: Sender's server)

Reading from bottom to top: localhost (sender's application) → mail.example.com (sender's outbound server) → mx.google.com (Google's inbound) → outlook.com (your inbox).

Identifying Originating IP Address

For troubleshooting and security investigations, you often need the original sender's IP. Look at the bottom-most Received header—it typically contains the true originating IP. However, spammers may forge this, so cross-reference with authentication results.

Detecting Delivery Delays

Compare timestamps between consecutive Received headers. Large gaps (minutes or hours) indicate bottlenecks:

• Several minutes: Greylisting delay (common for new senders)
• 30+ minutes to hours: Mail queue congestion or throttling
• Multiple hours or days: Mail server issues or intentional queuing

8. How to Identify Spoofing and Phishing Using Headers – Protecting Yourself and Your Users

Phishing emails are designed to look legitimate, but headers almost always reveal the deception if you know what to look for.

Red Flag #1: Authentication Failures

Any email claiming to be from a major company (bank, shipping carrier, government agency) that fails SPF, DKIM, or DMARC is almost certainly fraudulent. Legitimate companies invest in proper email authentication.

Authentication-Results: mx.google.com;
       spf=fail (google.com: domain of paypal.com does not permit 203.0.113.88)
       dkim=fail header.i=@paypal.com

Red Flag #2: Discrepancies Between Header Fields

Compare the From, Return-Path, and DKIM signing domain (d=). In legitimate emails, these typically match or are closely related. In spoofed emails, they often differ completely:

From: "PayPal" 
Return-Path: bounce@spammer-site.ru
DKIM-Signature: d=spammer-site.ru

Red Flag #3: Unusual Received Paths

An email claiming to be from a US bank but whose Received headers show originating IPs in Eastern Europe or Asia is highly suspicious.

Red Flag #4: Missing or Forged Date Headers

Spammers sometimes omit the Date header or use implausible dates (e.g., from the future or far past).

Red Flag #5: Suspicious Reply-To

If the Reply-To address doesn't match the From domain, be suspicious—especially if it's a free webmail address (gmail.com, yahoo.com, etc.) while the From is a corporate domain.

Step-by-Step Spoofing Investigation

1. Check Authentication-Results – any failures are immediate red flags
2. Find the bottom-most Received header to identify originating IP
3. Look up the originating IP's geolocation (is it plausible for the claimed sender?)
4. Compare From, Reply-To, Return-Path, and DKIM d= for inconsistencies
5. Check Message-ID domain – does it match the claimed sender?
6. Use SPF and DKIM checkers to verify the domain's authentication records

9. A Step-by-Step Troubleshooting Flow – From Problem to Solution

When emails aren't arriving or are going to spam, follow this systematic troubleshooting process using email headers.

Step 1: Verify Authentication

Look at Authentication-Results. If SPF, DKIM, or DMARC fail, that's likely why the email was filtered. Work with the sender to fix their authentication configuration.

Step 2: Check for Explicit Spam Headers

Many email providers add headers indicating why a message was classified as spam:

• Gmail: X-Gmail-Labels (includes "Spam" if filtered)
• Outlook.com: X-Forefront-Antispam-Report (shows SCL - Spam Confidence Level)
• SpamAssassin: X-Spam-Status (shows score and triggering rules)

Step 3: Analyze Received Timestamps for Delays

If emails arrive much later than expected, identify which hop caused the delay by comparing timestamps between consecutive Received headers.

Step 4: Check for Blacklist References

Some spam headers mention blacklists that triggered filtering:

X-Spam-Status: Yes, score=7.3 required=5.0 tests=DKIM_SIGNED,DKIM_INVALID,SPF_FAIL,RBL_SPAMHAUS

Step 5: Verify Content-Type and Encoding

If emails display as garbled text or raw code, check Content-Type and Content-Transfer-Encoding. Incompatible encodings can cause display problems.

Step 6: Use Online Header Analyzers

For complex cases, paste headers into online analyzers like:

• Google's Messageheader Tool (toolbox.googleapps.com)
• MXToolbox Email Header Analyzer
• WhatIsMyIP.com Email Header Analysis

10. Real-World Header Analysis Examples – Putting It All Together

Let's analyze real header scenarios you might encounter in the wild.

Example 1: Legitimate Newsletter

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of newsletter.example.com designates 192.0.2.45 as permitted sender);
       dkim=pass header.i=@newsletter.example.com;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=newsletter.example.com
Return-Path: bounce+123456@mail.newsletter.example.com
From: "Weekly Update" 
DKIM-Signature: v=1; a=rsa-sha256; d=newsletter.example.com; s=selector1;

Analysis: All authentication passed. Different Return-Path is normal for bulk senders. This email is legitimate.

Example 2: Phishing Attempt

Authentication-Results: mx.google.com;
       spf=fail (google.com: domain of chase.com does not permit 203.0.113.88);
       dkim=neutral (no signature)
From: "Chase Bank" 
Return-Path: verify@phishing-site.ru
Received: from mail.phishing-site.ru (203.0.113.88) by mx.google.com

Analysis: SPF fails, no DKIM, Return-Path domain doesn't match From, originating IP in suspicious location. This is definitely a phishing email.

Example 3: Delayed Delivery

Received: from mx.google.com (209.85.220.41) by outlook.com; Tue, 2 Jun 2026 15:30:00 -0400
Received: from mail.example.com (192.0.2.45) by mx.google.com; Tue, 2 Jun 2026 10:30:00 -0400
Received: from localhost (127.0.0.1) by mail.example.com; Tue, 2 Jun 2026 10:28:00 -0400

Analysis: The email was sent at 10:28 but didn't reach outlook.com until 15:30—a 5-hour delay. The gap occurred between mail.example.com and Google (10:30 to 15:30). The sender should investigate why Google held their message for 5 hours (possibly greylisting, reputation issues, or content filtering).

Example 4: Forwarded Email with ARC

ARC-Authentication-Results: i=1; mx.google.com;
       spf=pass (google.com: domain of lists.example.com designates 192.0.2.100 as permitted sender);
       dkim=pass header.i=@lists.example.com;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=lists.example.com
ARC-Message-Signature: i=1; a=rsa-sha256; d=google.com; s=arc-20160816;
ARC-Seal: i=1; a=rsa-sha256; d=google.com; s=arc-20160816;

Analysis: ARC headers preserve authentication results through a forwarder (in this case, a mailing list). Despite being forwarded, the authentication chain remains intact, and the email should be delivered normally.