Email Header Analyzer: Read Headers, Fix Delivery

What Is an Email Header?

An email header is a block of structured text that precedes the message body. Per RFC 5322 §2.1, every Internet mail message consists of a header section and an optional body, separated by a blank line. The header contains fields — name-colon-value pairs — that record the message's origin, routing path, recipient addresses, authentication results, and delivery timestamps.

Email clients hide this block by default because it is not intended for human reading in its raw form. A typical header runs 30–80 lines for a simple transactional message and over 100 lines for a message that passed through multiple security gateways. The information is machine-written as the message transits each mail server; by the time it arrives in an inbox, the header is a complete audit trail of exactly what happened to that message.

Two rules apply before you read any header:

• Headers accumulate from bottom to top. The sending server writes the first Received: line. Every subsequent server prepends its own Received: entry. To follow the message path from origin to destination, read the Received: lines starting from the bottom of the header and working upward.
• The From: address users see is not the same as the envelope sender. The display From: field (defined in RFC 5322 §3.6.2) can contain any text — it is what your email client displays as the sender name. The actual SMTP envelope sender used during mail delivery is recorded in the Return-Path: field, and that is what SPF validates against. These two values can be completely different domains.

ℹ️ Note: Phishing emails exploit the gap between the display From: and the actual Return-Path:. An email header analyzer surfaces this mismatch immediately, which is why it is the first tool security teams reach for when investigating a suspicious message.

Email Header Fields: Every Field Explained

The table below covers every significant field you will encounter in a standard header. Authentication-related fields are defined by their governing RFCs.

The single most diagnostic field is Authentication-Results:. It is added by the receiving mail server — not by the sender — so it cannot be forged. It records the definitive SPF, DKIM, and DMARC verdicts for the message as the receiving infrastructure evaluated them.

How to Copy Email Headers from Gmail, Outlook, and Apple Mail

This is the step where most users get stuck. Email clients bury the raw header behind non-obvious menus. The exact steps below are current as of 2026.

Gmail

1. Open the message you want to inspect.

2. Click the three-dot menu (⋮) at the top-right corner of the message pane — to the right of the reply arrow, not the top-of-page toolbar.

3. Select "Show original." Gmail opens a new browser tab showing the full, unprocessed message source including all headers and the body.

4. Click "Copy to clipboard" at the top of that tab. Gmail copies the complete raw text.

💡 Tip: The "Show original" tab in Gmail shows a summary row at the top that lists SPF, DKIM, and DMARC results directly. If all three show "PASS," the message is authenticated. You can then narrow your investigation to spam scoring or content issues rather than authentication.

Outlook — Desktop Application (Windows)

1. Double-click the message to open it in its own window. The reading pane does not expose the header option — the separate window is required.

2. Click File in the ribbon, then click Properties.

3. The "Internet headers" box at the bottom of the Properties dialog contains the complete raw header text.

4. Click inside the box, press Ctrl+A to select all, then Ctrl+C to copy.

Outlook — Web (OWA / Microsoft 365)

1. Open the message. Click the three-dot menu (⋯) at the top-right of the reading pane.

2. Select "View message details." A dialog opens with the full header block.

3. Copy the entire contents of the text area.

Apple Mail (macOS)

1. Click to select the message in your inbox (do not open it in a separate window).

2. From the menu bar, choose View → Message → All Headers.

3. The raw header block appears above the message body in the reading pane. Select all and copy.

ℹ️ Note: Mobile email clients — iOS Mail, Gmail for Android — do not expose raw headers through their standard UI. To inspect a message received on mobile, forward it to yourself and view it via a desktop client, or open Gmail in a full desktop browser session.

How to Use the Email Header Analyzer

With the raw header copied, the analysis itself takes under 30 seconds.

1. Open the Email Header Analyzer. No account or login is required.

2. Paste the complete header text into the input field. Include everything from the first Received: line through the Subject: and Message-ID: fields. Do not paste the message body — only the header block.

3. Click Analyze. The tool parses the header according to RFC 5322 and RFC 8601 and returns structured results in under a second.

4. Review the results panel. The analyzer surfaces:

   • Authentication results — SPF, DKIM, and DMARC pass/fail for this specific message, extracted from the Authentication-Results: field.
   • Originating IP address — pulled from the bottom-most Received: line, which is stamped by the first receiving server and cannot be forged.
   • Hop trace — every mail server the message passed through, listed in chronological order with timestamps.
   • Total delivery time — calculated from the earliest to latest timestamp in the Received: chain.
   • Spam verdict — extracted from X-Spam-Status: or equivalent if present in the header.

The tool flags anomalies inline: authentication failures display in red, large hop delays are highlighted, and missing mandatory fields are called out explicitly.

What Your Results Mean: Diagnosing Common Problems

Authentication Failures (SPF, DKIM, DMARC)

The Authentication-Results: field records a result keyword for each check. Per RFC 7208 §2.6 for SPF and RFC 6376 §3.5 for DKIM, the result values and their meanings are:

A DMARC result of fail means the message did not pass either an aligned SPF check or an aligned DKIM check, as required by RFC 7489 §4.2. Receiving servers enforcing p=reject will silently discard these messages. Use the SPF Checker to verify your domain's SPF record syntax, and the DMARC Checker to confirm policy configuration.

⚠️ Warning: spf=pass in the Authentication-Results: header does not mean the display From: address is legitimate. SPF only validates the Return-Path: domain. A spoofed message can pass SPF while displaying a completely different From: address. DMARC alignment is the check that ties these two identities together — do not rely on SPF alone to determine sender legitimacy.

Delivery Delays

Each Received: hop includes a timestamp. To identify where a message was delayed, compare the timestamp of each hop against the one immediately below it. The gap between two consecutive entries is the time the message spent at the first server in that pair before the next hop accepted it.

Received: from smtp.sender.com by mx1.receiver.com; Mon, 30 Jun 2026 10:00:05 +0000
Received: from mx1.receiver.com by mx2.receiver.com; Mon, 30 Jun 2026 10:07:42 +0000

In this example, the 7-minute gap between smtp.sender.com → mx1.receiver.com and mx1.receiver.com → mx2.receiver.com points to mx1.receiver.com as the bottleneck. The most common causes of multi-minute gaps between hops:

• Greylisting — the receiving server temporarily rejected the first delivery attempt (code 451), expecting legitimate senders to retry. Standard retry happens in 5–15 minutes.
• Content scanning — antivirus or data-loss-prevention (DLP) scanning introduces latency at a specific gateway before the message is passed to the next hop.
• DNS resolution failure — the receiving server could not resolve the sending domain's reverse DNS or encountered a timeout, triggering a retry cycle.
• Sending queue backlog — the originating MTA had a delivery backlog and did not attempt the next hop immediately after composition.

Spoofing Indicators

A spoofed or phishing message typically shows one or more of the following patterns in the raw header:

• From: domain ≠ Return-Path: domain — the displayed sender address and the envelope sender are on different domains, which is the most reliable single indicator of a forged sender.
• dmarc=fail in Authentication-Results: — the message cleared neither SPF+alignment nor DKIM+alignment, meaning the receiving server already determined it does not originate from the claimed domain.
• Originating IP not in the sending domain's MX infrastructure — the bottom-most Received: line shows an IP that does not belong to the mail servers the claimed From: domain is known to use. Cross-reference the IP against the sender's MX records using the MX Lookup tool.
• DKIM-Signature: d= tag domain ≠ From: domain — the DKIM signature was applied by a different domain than the display sender, indicating the message was relayed through infrastructure the From: domain does not control.

# Spoofed header pattern (anonymized example):
From: billing@legitimate-bank.com
Return-Path: <noreply@unrelated-domain.ru>
Authentication-Results: mx.google.com;
  spf=pass (sender IP authorized for unrelated-domain.ru);
  dkim=fail (key not found in DNS);
  dmarc=fail (p=REJECT sp=REJECT dis=REJECT) header.from=legitimate-bank.com

In this pattern, SPF passes because unrelated-domain.ru has a valid SPF record authorizing its sending IP. DMARC fails because unrelated-domain.ru does not align with legitimate-bank.com. The receiving server enforcing p=REJECT would discard this message.

Reading Headers Manually with the Command Line

When you want to inspect headers without a browser tool, parse a downloaded .eml file directly from the command line:

# Print only the header section of a saved .eml file
# The blank line between header and body acts as the delimiter
sed '/^$/q' message.eml

# Count the total number of server hops
grep -c "^Received:" message.eml

# Extract all timestamps from Received: headers for manual delay analysis
grep "^Received:" message.eml | grep -oE '[A-Z][a-z]{2}, [0-9]+ [A-Z][a-z]{2} [0-9]{4} [0-9:]{8} [+-][0-9]{4}'

# Check SPF/DKIM/DMARC results from the Authentication-Results: header
grep -A5 "^Authentication-Results:" message.eml

For real-time testing of your own outbound mail, send a test message to a Gmail address, then use Gmail's "Show original" → header summary table to verify the three authentication results. For platform-independent analysis, paste the raw header into the Email Header Analyzer.

Frequently Asked Questions

Next Steps

To verify that your own outbound messages pass authentication before checking headers, run your sending domain through the SPF Checker and confirm your DMARC policy with the DMARC Checker.

If your headers show SPF failures on mail you send, see the SPF Record Explained guide for record syntax and mechanism reference. For deploying a DMARC policy from p=none through to p=reject, see the DMARC Policy Enforcement guide.

For a complete pre-send checklist covering SPF, DKIM, DMARC, MX records, and blacklist status in one pass, see the Email Deliverability Triage Checklist.

Browse all email guides on DNSnexus.

Related Guides

• SPF Record Explained
• DMARC Policy Enforcement Guide
• Email Deliverability Triage Checklist
• Google & Yahoo Bulk Sender Requirements