Reading Email Headers: The Complete Guide to Spotting Phishing

The Hidden Data in Every Email You Receive

Every email you receive contains two distinct layers: the visible body that you read, and the hidden headers that contain the email's complete routing history, authentication results, originating server information, and technical metadata. Most email clients hide headers by default because they're technical and most users don't need them. But for anyone investigating potential phishing, headers are irreplaceable — they contain the ground truth about where an email actually came from, regardless of what the visible "From" field claims.

Phishing emails are crafted to look legitimate in the visible body. The logo is right, the formatting matches the brand, and the language sounds official. Headers tell a completely different story. A phishing email pretending to be from your bank, sent from a compromised server in another country, will show that originating server's IP address in the headers — completely unrelated to your bank's infrastructure.

How to Access Email Headers in Any Client

Every major email client provides a way to view the full raw headers. The location varies by client:

• Gmail: Open the email → click the three-dot menu (⋮) in the top right → "Show original" → the full headers appear in a new tab
• Outlook (desktop): Open the email → File → Properties → Internet headers section at the bottom
• Outlook (web): Open email → three-dot menu → "View" → "View message source"
• Apple Mail: View → Message → All Headers (or Shift+Command+H)
• Thunderbird: View → Headers → All
• ProtonMail: Open email → More options → "View headers"
• Yahoo Mail: More options → View Raw Message

The raw headers appear as a dense block of text above the message body. An email header analyzer tool can parse this automatically and present the key fields in a human-readable format.

Understanding the Received Header Chain

The most forensically valuable headers are the Received: headers. Each mail server that the email passes through on its journey adds a new Received: header at the top of the existing chain. Reading them correctly requires understanding that they're read bottom-to-top: the bottom-most entry is where the email originated, and the top-most entry is the final delivery to your inbox.

A genuine email from Google's Gmail infrastructure would show a Received chain like:

• Bottom: Received: from mail-ej1-f68.google.com (IP: 209.85.218.68) — the originating Gmail server
• Middle: Received: from mx1.recipient-domain.com — your mail server receiving it
• Top: Received: by your-mail-server.com; delivered to your inbox

A phishing email claiming to be from Google but actually originating from a compromised server in Vietnam would show a Vietnamese IP address at the bottom — completely disconnected from any Google infrastructure. This disconnect alone is definitive evidence of spoofing.

SPF: Sender Policy Framework Explained

SPF allows domain owners to publish a record in DNS specifying which IP addresses are authorized to send email on their behalf. When your mail server receives an email claiming to be from paypal.com, it looks up PayPal's DNS records for an SPF record and checks whether the sending IP address is in the authorized list.

The Authentication-Results: header in your email will show the SPF verdict:

• SPF pass: The sending IP is explicitly authorized by the domain's SPF record. Good indicator of legitimacy.
• SPF fail (hard fail): The sending IP is explicitly NOT authorized — -all in the SPF record. Strong indicator of spoofing or unauthorized sending.
• SPF softfail (~all): The IP isn't authorized but the domain hasn't configured strict enforcement. Common for misconfigured legitimate senders, but suspicious for major brands.
• SPF neutral (?all): The domain explicitly takes no position. Unhelpful for authentication purposes.
• SPF none: The domain has no SPF record at all. Slightly suspicious for major established brands, common for small domains.
• SPF permerror: The SPF record has syntax errors. Could indicate the domain was hastily configured for phishing.

DKIM: DomainKeys Identified Mail

DKIM adds a cryptographic digital signature to outgoing emails. When a mail server sends an email, it signs the message content using a private key that only the sending organization controls. The corresponding public key is published in the organization's DNS records. Receiving mail servers use this public key to verify the signature.

A valid DKIM signature proves two things simultaneously: first, that the email was sent by a server authorized by the domain; second, that the email content has not been modified in transit (even a single character change invalidates the signature). If DKIM fails, the email was either spoofed or tampered with after sending.

Look for dkim=pass or dkim=fail in the Authentication-Results header. The d= tag shows which domain the DKIM key belongs to — this should match the From address domain for a legitimate email.

DMARC: The Policy That Ties Everything Together

DMARC (Domain-based Message Authentication, Reporting, and Conformance) sits on top of SPF and DKIM and tells receiving mail servers what policy to apply when either check fails. It also requires "alignment" — the domain in the From address must match the domain that passed SPF or DKIM, preventing attackers from passing SPF on their own domain while spoofing a different brand's From address.

DMARC policies in order of strictness:

• p=none: Take no action on failed emails; just send reports. Often used during initial deployment while monitoring results.
• p=quarantine: Send failed emails to the spam folder. Common middle-ground policy.
• p=reject: Reject failed emails entirely — they never reach the recipient. The strongest protection against domain spoofing.

Check the Authentication-Results header for dmarc=pass, dmarc=fail, or dmarc=none. An email claiming to be from a major financial institution that shows dmarc=fail is definitively a phishing attempt.

IP Geolocation and Reputation Analysis

The originating IP address visible in the bottom-most Received: header can reveal the physical location of the sending server. Commercial geolocation databases can pinpoint IP addresses to the country, city, and sometimes the data center hosting provider. An email claiming to be from your US-based bank but originating from an IP address hosted by a Russian or Chinese cloud provider is immediately suspicious.

IP reputation databases track which IP addresses have been used for spam, phishing, or malware distribution. An originating IP with a poor reputation across multiple threat intelligence feeds dramatically increases the probability that the email is malicious. Dedicated email header analyzers automatically check the originating IP against these databases and flag high-risk IPs.

Complete Header Analysis Checklist

When investigating a suspicious email, work through this checklist systematically:

• Does the From: address domain match the Reply-To: domain? Phishing emails often use a legitimate-looking From address but route replies to the attacker's address.
• Does the Return-Path: domain match the From: domain? Mismatches indicate spoofing or third-party sending infrastructure not aligned with the claimed sender.
• Do all originating IP addresses belong to infrastructure consistent with the claimed organization?
• Did SPF pass, and was it a hard pass (not softfail)?
• Did DKIM pass with the correct signing domain?
• Did DMARC pass?
• Are the Received header timestamps consistent and chronological?
• Are there any unexpected relay servers in the chain that shouldn't be handling email for this sender?
• Does the Message-ID header domain match the sending organization's domain?