How to Read Email Headers (With Examples)

Email headers contain the routing and authentication metadata for a message. They are often the first place to look when troubleshooting spoofing, phishing, or deliverability issues.

A good header review can tell you how a message travelled, whether SPF, DKIM, and DMARC passed, and which systems handled it.

• Email Header Analysis

You can analyse headers and DNS records together using tools like DNS Pro.

• SPF
• DKIM
• DMARC

If you're analysing suspicious emails, Google also provides guidance on header analysis in their official Gmail documentation.

• Official Gmail header documentation

Below is a simplified real-world example of an email header:

Authentication-Results: mx.google.com;
 spf=pass (google.com: domain of sender@example.com designates 1.2.3.4 as permitted sender) smtp.mailfrom=sender@example.com;
 dkim=pass header.d=example.com;
 dmarc=pass (p=reject) header.from=example.com

Received: from mail.example.com (mail.example.com. [1.2.3.4])
 by mx.google.com with ESMTPS id abc123
 for <user@gmail.com>;
 Mon, 03 Apr 2026 10:00:00 +0000

Received: from app.internal (app.internal [10.0.0.5])
 by mail.example.com with ESMTP id def456;
 Mon, 03 Apr 2026 09:59:50 +0000

From: "Example Sender" <sender@example.com>
Return-Path: <sender@example.com>
Reply-To: support@example.com
Message-ID: <123456789@example.com>
Date: Mon, 03 Apr 2026 09:59:45 +0000
Subject: Test email

Understanding how to break this down is key to troubleshooting.

• Authentication-Results
• Received
• From
• Return-Path
• Reply-To
• Message-ID
• Date
• Subject

The Authentication-Results header shows how the receiving server evaluated authentication.

From the example:

spf=pass ...
dkim=pass ...
dmarc=pass ...

This tells us:

• SPF passed — the sending IP was authorised
• DKIM passed — the message signature is valid
• DMARC passed — alignment and policy checks succeeded

This is usually the fastest way to assess legitimacy.

If any of these fail, you may need to investigate the underlying DNS records and configuration.

The Received headers show the path the email took between systems.

From the example:

Received: from app.internal (10.0.0.5)
 by mail.example.com

Received: from mail.example.com (1.2.3.4)
 by mx.google.com

Read these from bottom to top:

• The message originated from an internal system (10.0.0.5)
• It was handed to the public mail server (mail.example.com)
• Then delivered to the receiving provider (Google)

If this chain looks inconsistent, such as unexpected IPs or unusual routing paths, it may indicate spoofing or relay issues.

The structure of these headers is defined in RFC 5322.

• RFC 5322

These fields serve different purposes.

• From is the visible sender address
• Return-Path is the envelope sender used for bounce handling

In the example:

From: sender@example.com
Return-Path: sender@example.com

These match, which is generally a good sign.

If they differ, it may still be legitimate, for example when using third-party senders, but it should be reviewed carefully.

• DMARC alignment

• SPF pass, fail, or softfail results
• DKIM signature validity
• DMARC alignment and policy outcome
• Unexpected IPs or hosts in the Received chain
• Mismatch between From and Return-Path
• Suspicious Reply-To addresses

• SPF or DKIM failures combined with DMARC fail
• Received chain that includes unknown or unrelated servers
• Return-Path domain unrelated to the From domain
• Reply-To pointing to a different domain
• Missing or malformed Message-ID

• Start with Authentication-Results to assess pass or fail quickly
• Review Received headers from bottom to top
• Check From versus Return-Path alignment
• Look for anomalies in IPs or domains
• Validate DNS records if needed such as SPF, DKIM, and DMARC
• Confirm whether failures are due to misconfiguration or malicious activity

If you want to validate this topic in practice, these DNS Pro tools are the fastest next step.

• Email Header Analysis
• Email Security Check
• DMARC Checker