How to Read Email Headers (And What They Tell You)

Email headers are the routing log attached to every message — they record every server the email passed through, the real sender address, authentication results (SPF, DKIM, DMARC), and timestamps. Your inbox only shows you the friendly display name; the header shows you everything the servers saw. Whether you received a suspicious email and want to trace it, or you’re a developer debugging delivery failures, the header has the answer.

Where to find email headers

Every major client exposes the full header, but the menu path differs:

• Gmail — Open the email → three-dot menu (top-right) → Show original. The raw source opens in a new tab.
• Outlook (web) — Three-dot menu → View → View message source.
• Outlook (desktop) — File → Properties → scroll to the Internet headers box.
• Apple Mail — View → Message → All Headers.
• Thunderbird — View → Headers → All.

If you have a .eml file, open it directly in the EML viewer to see the headers alongside the message body without needing a mail client. For .msg files (Outlook format), the MSG viewer shows headers too.

The key headers explained

From:

The display name and address the sender chose. This field can be freely forged — it is what appears in your inbox, but it carries no authentication on its own.

From: "PayPal Support" <support@paypal.com>

Return-Path:

Where bounce messages (delivery failures) are sent. Because bounce handling is automated, this address is harder to fake convincingly. When From: is spoofed, Return-Path: often reveals the actual sending domain.

Return-Path: <bounce@mail.actualsender.com>

Reply-To:

Where your reply goes if it differs from From:. Phishing emails frequently set this to an address the attacker controls so that victim replies land in their inbox, not the impersonated brand’s.

Received:

One line per server hop, stacked newest-first. Each line records the receiving server, the server it accepted the message from, and a timestamp. Reading from the bottom up traces the message’s full route from origin to your inbox. This is the most important header for tracing delivery.

Message-ID:

A unique identifier assigned by the originating mail server. The domain after the @ usually reveals the true sending server — even when From: names a different domain.

Message-ID: <abc123@mail.actualsender.com>

X-Originating-IP: / X-Forwarded-For:

The original client IP address, written by some servers (Google Workspace, Yahoo Mail, and others include it). Not universally present and can be forged by a rogue server, but useful when it appears.

Authentication-Results:

The receiving server’s verdict on three authentication checks:

Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=actualsender.com;
  dkim=pass header.d=actualsender.com;
  dmarc=pass

Date:

When the sender’s client submitted the message. Compare this with the timestamps on Received: lines to spot unusual delays — a gap of hours between hops may indicate queuing problems or a grey-listed server.

X-Spam-Score: / X-Spam-Status:

Set by the receiving server’s spam filter. Format and thresholds vary by provider (SpamAssassin, Postfix, etc.), but a high score or Yes status means the filter flagged the message before it reached your inbox.

How to spot a spoofed or phishing email

Three header checks catch the majority of spoofed messages:

1. From: domain ≠ Return-Path: domain. A legitimate transactional email from paypal.com will have a Return-Path: that also resolves to paypal.com or a known PayPal delivery partner. A mismatch is a strong red flag.
2. Authentication-Results: shows spf=fail or dkim=fail. The message claims to be from a domain it has no authority to send from, or the message was modified after signing.
3. Reply-To: points to a different domain than From:. Your reply goes somewhere unexpected — usually the attacker’s inbox.

A real spoofed-header example:

From: "PayPal" <security@paypal.com>
Return-Path: <bounce@mail347.phishingdomain.ru>
Reply-To: <collect@freemail.example>
Authentication-Results: spf=fail; dkim=none

This message claims to be from PayPal. The Return-Path: is a Russian domain with no connection to PayPal. SPF failed — meaning PayPal’s DNS records do not list that server as authorised. DKIM is absent entirely. All three checks fail. Treat any email with this pattern as a phishing attempt.

Reading Received: headers in order

Received: lines stack newest-first. To trace the message’s route, read from the bottom up. The bottom line is the first hop — the originating server. Here is a three-hop example:

Received: from mail.yourprovider.com (mail.yourprovider.com [203.0.113.10])
        by mx.recipient.com with ESMTP; Fri, 28 Aug 2026 09:05:12 +0000

Received: from relay.sendingdomain.com (relay.sendingdomain.com [198.51.100.44])
        by mail.yourprovider.com with ESMTP; Fri, 28 Aug 2026 09:04:58 +0000

Received: from client.sendingdomain.com (unknown [192.0.2.7])
        by relay.sendingdomain.com with ESMTP; Fri, 28 Aug 2026 09:04:41 +0000

Reading bottom to top:

1. Hop 1 (bottom): The sender’s client at 192.0.2.7 handed the message to relay.sendingdomain.com at 09:04:41.
2. Hop 2 (middle): The relay passed it to mail.yourprovider.com at 09:04:58 — a 17-second transit, normal.
3. Hop 3 (top): Your provider delivered it to the final mail server at 09:05:12 — 14 seconds more. Total delivery: 31 seconds.

Any hop showing a delay of many minutes is worth investigating — it often points to a greylist hold, a delivery retry, or a misconfigured relay.

Extract email addresses from headers or logs

If you are working with email data at scale — parsing header dumps, mail server logs, or exported .eml files — and need to pull every address out into a list, the email address extractor does that in seconds. Paste or drop in your text; it finds every valid address. Nothing is uploaded — the extraction runs in your browser.

Last updated: 2026-08-28.