How to Read Email Headers, Trace Delivery Hops, and Verify SPF, DKIM & DMARC

Every time you receive an email, your email client only shows you a friendly snapshot: the sender's display name, the subject, the date, and the body text. But behind that visible interface lies a detailed technical audit log known as the RFC 5322 Email Headers.

Email headers tell the complete, unvarnished story of where an email originated, every server (MTA) it passed through on the internet, how many seconds or minutes it spent queued at each relay, and whether the sender's cryptographic identity was verified or spoofed.

In this guide, you will learn how to read raw email headers, trace hop-by-hop delivery routing, and verify the security trifecta: SPF, DKIM, and DMARC.

1. How to Extract Raw Headers from Common Email Clients

Before analyzing an email, you must view its raw source text:

Google Gmail / Google Workspace

1. Open the email message in your web browser.
2. In the top-right corner of the message pane, click the More options menu (three vertical dots next to the Reply button).
3. Select "Show original".
4. A new tab opens displaying the raw RFC 5322 source. Click "Copy to clipboard" or copy all text in the box.

Microsoft Outlook & Office 365

1. Double-click the email so it opens in its own separate window.
2. Click File > Properties (in the Info tab).
3. At the bottom of the Properties dialogue, look for the Internet headers text box.
4. Click inside, press Ctrl+A (or Cmd+A on macOS) to select all, and copy.

Apple Mail (macOS)

1. Select the email in Apple Mail.
2. From the top application menu bar, choose View > Message > Raw Source (Keyboard shortcut: Option + Command + U).
3. Select all and copy.

2. The Golden Rule: Read Received Headers from Bottom to Top

The most crucial header for tracking email delivery is the Received: header.

Whenever an intermediate Mail Transfer Agent (MTA) receives an email, it prepends a new Received: line to the very top of the message header stack.

This means:

• The bottom-most Received: header represents the first hop (the client or server where the message was initially composed and submitted).
• The top-most Received: header represents the final hop (the receiving mailbox server that placed the message into your inbox).

Received: by mx.google.com ... [Hop 3: Final Delivery to Inbox]
Received: from relay.security-scanner.com ... [Hop 2: Intermediate Spam Filter]
Received: from mail.company.com ... [Hop 1: Original Sending Mail Server]

To trace an email's route, always read chronologically from the bottom upward.

3. Anatomy of a Received Header Line

A standard Received: header adheres to this format:

Received: from mail4.github.com (mail4.github.com. [192.30.252.204])
        by mx.google.com with ESMTPS id o14-20020a17090b39ce00b00290bbff817csi1829474pjg
        for <recipient@example.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Tue, 20 Oct 2026 14:15:28 -0700 (PDT)

Here is what each component reveals:

1. from mail4.github.com [192.30.252.204]: The hostname and IP address of the sending machine that connected to this hop.
2. by mx.google.com: The receiving mail server handling the incoming connection.
3. with ESMTPS: The protocol used. The S suffix indicates that Transport Layer Security (TLS) was active during the transfer.
4. for <recipient@example.com>: The target envelope recipient address.
5. Timestamp (Tue, 20 Oct 2026 14:15:28 -0700): The exact date, time, and UTC offset when the server accepted the message.

4. Diagnosing Email Delivery Delays

Why did an email arrive 45 minutes late? The headers contain the answer.

By calculating the difference in timestamp between consecutive Received: headers, you can pinpoint the exact server responsible for the delay:

In the table above, the delay did not occur inside the sender's internal network or inside the recipient's mailbox system. The 42-minute delay occurred while queued at outbound.relay-cluster.net trying to deliver to mx.recipient-mail.com. Common causes include:

• Greylisting on the recipient MX requiring a retry cycle.
• Sender IP rate limiting / throttling.
• Network connection timeouts.

Using the KitWharf Email Header Analyzer, these hop delays are calculated automatically and presented on a visual timeline.

5. The Security Trifecta: SPF, DKIM, and DMARC

Modern mailbox providers (Google, Yahoo, Microsoft) strictly evaluate the Authentication-Results: header to protect users against phishing and business email compromise (BEC).

1. SPF (Sender Policy Framework)

• What it does: The domain owner publishes a DNS TXT record listing all IP addresses permitted to send mail for that domain.
• Example record: v=spf1 ip4:192.30.252.0/22 include:_spf.google.com -all
• Common results:
  • pass: The sending IP is explicitly authorized in DNS.
  • softfail (~all): The IP is likely not authorized, but the domain owner advises accepting with scrutiny.
  • fail (-all): The IP is definitely not authorized. Mail should be rejected or marked as spam.

2. DKIM (DomainKeys Identified Mail)

• What it does: The sending server generates a cryptographic digital signature using an asymmetric private key. The signature hash is attached to the email in a DKIM-Signature: header.
• Verification: The receiving server queries the sender's DNS for the public key (using the selector s= and domain d=) to decrypt and verify that the message body and headers were not altered in transit.
• Common results:
  • pass: Signature is cryptographically authentic and untampered.
  • fail: The message body or headers were modified, or the DNS key is invalid.

3. DMARC (Domain-based Message Authentication)

• What it does: Ties SPF and DKIM together by enforcing Domain Alignment.
• The Alignment Rule: It is not enough for SPF or DKIM to pass; the domain verified by SPF or DKIM must match the visible domain shown in the From: header.
• Policies: Domain owners can set p=none (monitoring only), p=quarantine (send to junk folder on failure), or p=reject (block delivery completely on failure).

6. Spotting Email Spoofing & Phishing

Attackers frequently try to spoof reputable organizations (e.g., PayPal, Apple, your corporate CEO). Here are the primary header red flags to look for:

1. Return-Path vs. From Mismatch:
   • If the visible From: says support@paypal.com, but the envelope Return-Path: says update@attacker-vps.net, be on high alert.
2. DMARC / SPF Failure:
   • Any message where dmarc=fail and spf=fail has an exceptionally high probability of being spoofed.
3. Suspicious Reverse DNS (PTR):
   • If a server identifies itself as mail.microsoft.com, but its actual IP address resolves to a residential broadband ISP or an obscure VPS provider, the connection is untrustworthy.

Test Your Headers 100% In-Browser

Ready to inspect an email header? Use the KitWharf Email Header Analyzer to parse delivery hops, view transit delays, and verify SPF, DKIM, and DMARC status with zero server uploads and total privacy.