Email Header Analysis: How to Trace the Source of Any Email

Every email you receive carries a hidden trail of metadata that reveals its true origin, the servers it passed through, and whether it is legitimate or a forgery. This metadata is stored in the email headers, and learning to read them is one of the most valuable skills for identifying phishing, spam, and spoofed emails.

In this guide, you will learn how to access email headers in every major email client, how to interpret each header field, and how to use headers to trace an email back to its source.

What Are Email Headers?

Email headers are lines of metadata prepended to every email message. They are normally hidden from view in your email client, but they contain critical information about the email's journey from sender to recipient.

Think of headers like the postmarks on a physical letter. Just as a letter picks up stamps at each post office it passes through, an email acquires header lines at each mail server that handles it.

Headers include:

• The sender and recipient addresses
• The subject line
• Timestamps at each server hop
• Authentication results (SPF, DKIM, DMARC)
• The IP addresses of every server that handled the message
• Server software versions and configurations

How to View Email Headers

Gmail

1. Open the email.
2. Click the three-dot menu in the upper right corner of the message.
3. Select "Show original."
4. Gmail displays the raw message with all headers, plus a summary of authentication results at the top.

Outlook (Web)

1. Open the email.
2. Click the three-dot menu at the top of the message.
3. Select "View" then "View message source" (or "View message details" in some versions).

Apple Mail

1. Open the email.
2. Go to View menu then Message then All Headers.
3. The headers appear above the message body.

Thunderbird

1. Open the email.
2. Go to View then Headers then All.
3. Or press Ctrl+U to view the full source.

Once you have the raw headers, you can paste them into our Trace Email tool for automated analysis, or read them manually using the guide below.

Understanding Email Headers

Headers are read from bottom to top. The bottom-most headers were added first (by the sending server), and the top-most headers were added last (by your receiving server). This is counterintuitive but essential to understand.

The Key Headers

From

From: John Smith <[email protected]>

This is the display name and address shown in your email client. This field can be trivially forged. Anyone can set any From address. Never trust the From header alone as proof of who sent an email.

Return-Path (Envelope From)

Return-Path: <[email protected]>

This is the actual envelope sender address used during SMTP transmission. Bounce messages (non-delivery receipts) go to this address. It is harder to forge than the From header but still not definitive proof of origin.

Received Headers

Received: from mail-server.example.com (mail-server.example.com [203.0.113.25])
        by mx.recipient.com with ESMTPS id abc123
        for <[email protected]>;
        Mon, 20 Jan 2026 14:32:05 -0800 (PST)

These are the most important headers for tracing an email. Each mail server that handles the message adds its own Received header at the top. Reading from bottom to top gives you the complete route:

1. from: The server that sent the message to this hop.
2. by: The server that received the message at this hop.
3. with: The protocol used (SMTP, ESMTP, ESMTPS for encrypted).
4. for: The recipient address.
5. timestamp: When this server processed the message.

The IP address in square brackets is particularly valuable because it is set by the receiving server (not the sending server), making it difficult to forge. The bottom-most Received header with a public IP address is typically the true originating server.

Authentication-Results

Authentication-Results: mx.recipient.com;
       spf=pass (sender IP is 203.0.113.25) smtp.mailfrom=example.com;
       dkim=pass header.d=example.com header.s=selector1;
       dmarc=pass (p=REJECT) header.from=example.com

This header is added by your receiving mail server and summarizes the results of three email authentication checks. This is the single most useful header for determining legitimacy.

Understanding SPF, DKIM, and DMARC

SPF (Sender Policy Framework)

SPF verifies that the sending server's IP address is authorized to send email for the domain in the Return-Path. The domain owner publishes a DNS TXT record listing all IP addresses and servers allowed to send on their behalf.

• spf=pass: The sending server is authorized. Good sign.
• spf=fail: The sending server is NOT authorized. Strong indicator of spoofing.
• spf=softfail: The sending server is probably not authorized, but the domain owner has not set a strict policy.
• spf=neutral: The domain owner has not expressed an opinion about this server.
• spf=none: The domain has no SPF record at all.

DKIM (DomainKeys Identified Mail)

DKIM uses public-key cryptography to verify that an email was sent by the claimed domain and has not been modified in transit. The sending server adds a digital signature to the email headers, and the receiving server verifies it against a public key published in DNS.

• dkim=pass: The signature is valid. The email was genuinely sent by the claimed domain and has not been altered.
• dkim=fail: The signature does not verify. Either the email is forged or it was modified in transit (some mailing lists modify messages, breaking DKIM signatures).

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC ties SPF and DKIM together and tells receiving servers what to do when authentication fails. It checks that the domain in the From header aligns with the domains authenticated by SPF and DKIM.

• dmarc=pass: Both alignment and authentication succeeded. The email is almost certainly legitimate.
• dmarc=fail with p=REJECT: The domain owner has instructed servers to reject unauthenticated messages. If you still received it, either it passed authentication or your server is not enforcing DMARC.
• dmarc=fail with p=QUARANTINE: Failed messages should be sent to spam.
• dmarc=fail with p=NONE: The domain owner is only monitoring, not enforcing.

Tracing an Email Step by Step

Let us walk through a practical example. Suppose you receive a suspicious email claiming to be from your bank.

Step 1: View the Full Headers

Access the headers using the instructions above for your email client.

Step 2: Check Authentication Results

Look at the Authentication-Results header first. If you see:

spf=fail
dkim=fail
dmarc=fail

The email is almost certainly fraudulent. Stop here and report it as phishing.

Step 3: Trace the Received Headers

Read the Received headers from bottom to top. Identify the first public IP address in the chain. Private IP ranges (10.x.x.x, 172.16-31.x.x, 192.168.x.x) are internal and can be skipped.

Step 4: Look Up the Originating IP

Take that IP address and use our WHOIS Lookup tool to find out who owns it. If the email claims to be from Chase Bank but the originating IP belongs to a hosting provider in a different country, that is a red flag.

You can also use our Trace Email tool to automate this entire process. Paste in the raw headers and get an instant analysis of the email's origin, authentication status, and risk assessment.

Step 5: Check for Header Forgery

Forged emails often have telltale inconsistencies:

• The From domain does not match the DKIM signing domain
• The originating IP does not match the claimed sending domain
• Timestamps are out of order or in impossible time zones
• The Return-Path domain does not match the From domain
• There are extra Received headers that do not make logical sense

Common Phishing Indicators in Headers

Mismatched Domains

From: [email protected]
Return-Path: <[email protected]>

The From says "paypal.com" but the Return-Path uses "paypa1-security.com" (with a numeral 1 instead of the letter l). This is a classic phishing technique.

Failed Authentication

Authentication-Results: spf=fail; dkim=none; dmarc=fail

A legitimate email from a major company like PayPal, Google, or Microsoft will always pass SPF, DKIM, and DMARC. Failure on any of these for a well-known domain is a strong phishing indicator.

Suspicious Originating Server

Received: from smtp.legitimate-bank.com (actually-a-vpn.somehost.ru [185.x.x.x])

The HELO/EHLO hostname claims to be "smtp.legitimate-bank.com" but the actual reverse DNS and IP address point to a completely different server. The information in parentheses (added by the receiving server) is what you should trust, not the self-reported hostname.

Unusual X-Headers

Many email systems add custom headers prefixed with "X-":

X-Mailer: PHPMailer 5.2.27
X-Originating-IP: [185.x.x.x]

If an email from your bank was sent using PHPMailer (a PHP library commonly used in web applications), that is suspicious. Banks use enterprise email systems, not PHP scripts on shared hosting.

Email Header Analysis Best Practices

Always Check Authentication First

The Authentication-Results header gives you the fastest, most reliable assessment. If SPF, DKIM, and DMARC all pass and the domains align, the email is very likely legitimate.

Do Not Trust Self-Reported Information

Any header information reported by the sending server (HELO hostname, From address, initial Received header) can be forged. Trust information added by your receiving server and intermediate servers you recognize.

Use Automated Tools for Complex Headers

Emails that pass through mailing lists, forwarding services, or multiple security gateways can have extremely complex headers with dozens of Received lines. Our Trace Email tool can parse these automatically and present the information in a clear, visual format.

Preserve Original Headers for Reporting

If you need to report a phishing email to your IT department, law enforcement, or a service like PhishTank, always include the full original headers. Screenshots of the email body are not sufficient for investigation.

Key Takeaways

• Email headers reveal the true origin and route of every message
• Read Received headers from bottom to top to trace the path
• Authentication-Results (SPF, DKIM, DMARC) is your fastest legitimacy check
• The From header can be trivially forged and should never be trusted alone
• Use our Trace Email tool for automated header analysis
• Mismatched domains and failed authentication are strong phishing indicators

Related Articles:

• WHOIS Privacy Guide: Protecting Your Domain Registration Data
• Network Security Basics: Protecting Your Home Network
• VPN vs Proxy: Which Is Better for Privacy in 2026?