How to Read Email Headers to Detect Phishing

The "From" address you see in an email can be faked in about 10 seconds. Email headers — the hidden metadata that travels with every message — tell the real story. Learning to read headers gives you the ability to verify whether an email genuinely came from the claimed sender, which server processed it, and whether it passed authentication checks. This is the most reliable method for detecting phishing that visual inspection alone cannot catch.

How to Access Email Headers

Every email client stores headers differently. Here is how to find them in the major platforms:

Gmail

1. Open the email
2. Click the three dots (⋮) next to the reply button
3. Select "Show original"
4. Gmail also shows a summary with SPF, DKIM, and DMARC results at the top

Outlook (Web)

1. Open the email
2. Click the three dots (⋯) in the top-right corner
3. Select "View" → "View message source"

Apple Mail

1. Open the email
2. Go to View → Message → All Headers

Thunderbird

1. Open the email
2. Go to View → Headers → All

Key Header Fields Explained

From

The display address — this is what you see in your inbox. It can be freely set by anyone and is the easiest field to forge. Never rely on this alone.

Return-Path (Envelope From)

The actual address that bounced messages go to. In legitimate email, this usually matches or is related to the From address. In phishing, it often does not.

From: Apple Support <noreply@apple.com>
Return-Path: <bounce-7391@mail-server.cheaphosting.xyz>

This mismatch is a strong indicator of forgery. The displayed From claims to be Apple, but the Return-Path reveals the email actually originated from a server called cheaphosting.xyz.

Received Headers

Each server that handles the email adds a "Received:" header. They stack from bottom (first server) to top (last server before your inbox). Reading from bottom to top traces the email's journey.

Received: from mail-yw1-f169.google.com (mail-yw1-f169.google.com [209.85.128.169])
  by mx.example.com with ESMTPS
  for <you@example.com>;
  Fri, 27 Mar 2026 14:32:01 -0700

Key things to check in Received headers:

• Do the server names make sense? An email "from Apple" should pass through Apple's mail servers (e.g., *.apple.com or Apple's email service provider), not a random hosting provider.
• Do the IP addresses match the claimed domains? Use a WHOIS lookup (e.g., at whois.domaintools.com) to verify that the IP belongs to the claimed organization.
• Are there time jumps? Large gaps between Received timestamps can indicate the email was queued on an unusual server.

Authentication-Results

This is the most useful header for quick phishing detection. Your email provider adds it after checking three authentication protocols:

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

Three passes = high confidence the email is legitimate. Here is what each means:

• SPF=pass: The sending server's IP address is authorized by the domain's DNS records to send mail on its behalf.
• DKIM=pass: The email contains a valid cryptographic signature proving it was not altered in transit and was sent by an authorized server.
• DMARC=pass: The domain's DMARC policy was satisfied, meaning both SPF and/or DKIM aligned with the From domain.

Failures are concerning:

• SPF=fail: The sending server is not authorized by the claimed domain.
• DKIM=fail: The cryptographic signature is missing, invalid, or does not match.
• DMARC=fail: The email failed the domain's authentication policy. Many domains set DMARC to p=reject or p=quarantine, meaning failures should be blocked or sent to spam.

Message-ID

A unique identifier generated by the sending server. Legitimate emails from major services have Message-IDs that match the sender's domain:

Message-ID: <CAB1xyz123@mail.gmail.com>

A phishing email claiming to be from Gmail but with a Message-ID like <abc@unknown-server.ru> is suspicious.

Practical Example: Analyzing a Phishing Email

Let us walk through a real phishing email header analysis. An email claims to be from "PayPal Security" about unauthorized account access.

Step 1: Check Authentication-Results

Authentication-Results: mx.google.com;
  spf=softfail (google.com: domain of transitioning sender@paypa1.com does not designate 185.234.72.11 as permitted sender);
  dkim=none;
  dmarc=fail (p=NONE) header.from=paypal.com

Three red flags: SPF softfail, no DKIM signature, and DMARC failure. The Return-Path domain is paypa1.com (with the number 1 instead of the letter l), while the From claims paypal.com.

Step 2: Check the Received chain

Received: from vps-8472.hostinger.com ([185.234.72.11])
  by mx.google.com with ESMTP

The email came from a Hostinger VPS, not PayPal's mail infrastructure. PayPal uses its own dedicated mail servers.

Step 3: Check the Message-ID

Message-ID: <5f3a1b@vps-8472.hostinger.com>

Confirms the email originated from the Hostinger VPS, not PayPal.

Verdict: This is a phishing email. Three independent header checks all point to the same conclusion.

Quick Method: Use IsThisAScam for Header Analysis

If reading raw headers feels overwhelming, you can paste the full email (including headers) into IsThisAScam.to. The tool automatically parses authentication results, checks sender reputation, analyzes the email content for phishing patterns, and provides a clear verdict.

Common Mistakes When Reading Headers

• Trusting the From address. This is the most forged field. Always verify with authentication results.
• Reading Received headers top-to-bottom. They should be read bottom-to-top for chronological order.
• Ignoring softfail results. SPF softfail still means the server was not fully authorized. Treat it with suspicion.
• Assuming HTTPS means safe. An email linking to an HTTPS phishing site is still a phishing email.