Email Header Analysis: How to Trace an Email's Origin, Verify Authentication, and Spot Spoofing

$2.77 billion. That's how much Americans reported losing to business email compromise in 2024 alone, according to the FBI's Internet Crime Complaint Center. The median loss per incident was $50,000—and nearly all of those attacks started with an email that looked legitimate but wasn't.

The information needed to detect most of these attacks is sitting right inside every email you receive. It's in the headers—a block of metadata that most people never look at, recording every server the email passed through, whether the sender's identity was verified, and where in the world the message actually originated.

Most "how to read email headers" guides give you a screenshot of Gmail's "Show original" button, define what "Received" means, and stop there. That's like teaching someone to read a map without explaining what the symbols mean or where they're trying to go. This guide goes further: the actual mechanics of email authentication, which providers strip sender IP data (and which don't), why 89% of malicious emails pass SPF/DKIM/DMARC checks, and what header analysis can and cannot reveal.

What Email Headers Actually Are

Every email has two parts: the body (what you read) and the headers (what mail servers read). Headers are metadata lines added by each server that handles the message, forming a chain of custody from sender to recipient. They're defined by RFC 5322 (message format) and RFC 5321 (SMTP protocol), and they've been a core part of email since the early 1980s.

Think of headers like the stamps and routing labels on a physical package. When a letter goes through the postal system, each sorting facility stamps it with a date, location, and forwarding record. Email headers work the same way. Every mail transfer agent (MTA) that touches the message prepends a Received: header recording when it got the message, where it came from, and what protocol it used.

Headers also carry authentication results. Did the sending server have permission to send from that domain? Was the message signed cryptographically? Did it match the domain's published email policy? All of this is recorded in headers before the message reaches your inbox.

Anatomy of an Email Header

A typical email contains 15–40 header lines. The critical ones for analysis fall into three categories: routing headers, authentication headers, and identity headers.

Routing Headers (Received)

The Received: headers form the email's delivery chain. Each MTA that processes the message prepends one. They record the server hostname, IP address, protocol used (ESMTPS means encrypted, ESMTP means plaintext), and timestamp. Since each server prepends its header above the existing ones, you read them bottom to top to trace the chronological path.

A typical email passes through 3–5 servers. Corporate emails routed through security gateways (Proofpoint, Mimecast, Barracuda) may have 6–8 hops. The bottom-most Received: header usually shows the originating server—though this is where provider IP stripping matters (more on that below).

Authentication Headers

The receiving mail server performs authentication checks and records the results:

• Authentication-Results: — the comprehensive results header showing SPF, DKIM, and DMARC verdicts in one place
• Received-SPF: — whether the sending server's IP is authorized by the domain's SPF record
• DKIM-Signature: — the cryptographic signature added by the sending server
• ARC-Authentication-Results: — preserved authentication results from previous hops (used when emails are forwarded through mailing lists)

Identity Headers

These identify the sender, but they're the easiest to forge:

• From: — the display address the recipient sees. Can be set to anything by the sender.
• Return-Path: — the envelope sender (where bounces go). Set during the SMTP session, not by the email client.
• Reply-To: — where replies are directed. Often different from From: in phishing emails.
• X-Originating-IP: — the sender's actual IP address (if the mail server includes it). Some providers add this, most strip it.

How to Find Email Headers

Every email client hides headers by default. Here's how to reveal them in the major providers:

Once you have the raw headers, you can paste them into our Email Header Analyzer to automatically parse the routing chain, verify authentication, and geolocate the sending servers.

Reading Email Headers: Step-by-Step Walkthrough

Here's a real-world header set (sanitized) from a corporate email sent through Microsoft 365. Let's walk through what each section reveals.

Reading bottom to top, here's what the headers tell us:

1. First hop (bottom Received): The sender's machine at local IP 192.168.1.105 connected from public IP 73.42.118.203 to Microsoft's Exchange Online server. The X-Originating-IP confirms this. This IP could be geolocated to find the sender's approximate location.
2. Second hop: Microsoft routed the email internally between Exchange Online servers (the IPv6 addresses starting with 2603:10b6 are Microsoft's data center IPs).
3. Third hop (top Received): Microsoft's outbound server at 40.107.22.83 delivered to Google's MX server using encrypted SMTP (ESMTPS).
4. Authentication: All three checks passed—DKIM verified the cryptographic signature, SPF confirmed that Microsoft's server was authorized to send for contoso.com, and DMARC passed with a policy of REJECT (meaning unauthenticated emails would be rejected, not just flagged).

This is what a clean, legitimate email looks like. Now let's understand the authentication system that produced those results.

Email Authentication: SPF, DKIM, and DMARC

Email was designed in the 1970s without any sender verification. The SMTP protocol lets anyone claim to be anyone—just like you can write any return address on an envelope. SPF, DKIM, and DMARC were bolted on decades later to fix this.

SPF (Sender Policy Framework)

SPF (RFC 7208) works at the server IP level. The domain owner publishes a DNS TXT record listing which IP addresses and servers are authorized to send email for that domain. When a mail server receives a message claiming to be from @example.com, it looks up example.com's SPF record and checks whether the sending server's IP is on the list.

SPF's limitation: it checks the envelope sender (Return-Path), not the display address (From). An attacker can set a Return-Path of [email protected] (which passes evil.com's SPF) while displaying From: [email protected]. The email passes SPF but the visible sender is spoofed. This is exactly why DMARC was created.

DKIM (DomainKeys Identified Mail)

DKIM (RFC 6376) adds a cryptographic signature. The sending server signs specific headers and the message body with a private key. The corresponding public key is published in DNS. The receiving server retrieves the public key, verifies the signature, and confirms the message wasn't altered in transit.

DKIM's limitation: it verifies integrity (the message wasn't tampered with), but it doesn't verify the visible sender. The DKIM signature can be valid for evil.com while the From: header shows [email protected]. Again, DMARC addresses this.

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

DMARC (RFC 7489) ties SPF and DKIM together with a critical requirement: alignment. For DMARC to pass, either SPF or DKIM must pass and the authenticated domain must match (or be a subdomain of) the visible From: address. This closes the gap that SPF and DKIM leave open.

DMARC also introduces a policy mechanism. Domain owners publish one of three policies:

• p=none — Monitor only. Report authentication failures but deliver the email normally. This is the starting point for domains rolling out DMARC.
• p=quarantine — Send failed emails to spam/junk. The email is delivered but flagged.
• p=reject — Block the email entirely. The most protective policy, but risky to deploy without thorough testing because legitimate emails that fail authentication (forwarded messages, mailing lists) will also be blocked.

ARC and BIMI: The Newer Layers

ARC (Authenticated Received Chain, RFC 8617) was introduced in 2019 to solve a real problem: email forwarding breaks DKIM signatures. When a mailing list modifies a message (adding a footer, changing the Subject line), the DKIM signature becomes invalid. ARC allows intermediate servers to cryptographically attest that authentication was valid when they received the message, preserving the chain of trust even after modification.

BIMI (Brand Indicators for Message Identification) is the latest addition. It lets domains that have deployed DMARC with a reject or quarantine policy display their brand logo next to authenticated emails. Gmail rolled out BIMI support with blue checkmarks in May 2023. It's not an authentication mechanism itself—it's a visual indicator that authentication is already in place.

Why Authentication Fails: The 89% Problem

If SPF, DKIM, and DMARC are supposed to prevent email spoofing, why do the majority of phishing emails still get through? There are four main reasons:

1. Compromised Legitimate Accounts

According to research from Egress, 44% of phishing emails in 2024 were sent from compromised legitimate accounts. When an attacker gains access to a real employee's email account, every email they send passes SPF, DKIM, and DMARC perfectly—because it is coming from an authorized server for that domain. Header analysis still works here: the Received: headers will show the correct sending infrastructure, but the content and behavior will be malicious.

This is the hardest attack to detect through headers alone. The authentication is technically correct. Only behavioral analysis (unusual sending patterns, anomalous content, suspicious links) can catch these.

2. Lookalike Domains

An attacker registers contoso-inc.com (note the hyphen) and sets up proper SPF, DKIM, and DMARC records for it. Emails from [email protected] pass every authentication check because the attacker legitimately controls that domain. The protection only works against impersonation of the exact domain (contoso.com), not visually similar ones.

In headers, you'd spot this by checking whether the From: domain exactly matches what you expect. But in practice, recipients rarely scrutinize the domain—especially on mobile, where email clients often show only the display name ("John Smith, CEO") rather than the full email address.

3. Domains Without DMARC

Despite years of advocacy, many domains still have no DMARC record at all, or run with p=none (monitoring only, no enforcement). Without DMARC enforcement, SPF and DKIM failures don't trigger any blocking action. The email arrives normally, and the authentication failure is silently logged—if anyone is even watching the reports.

4. Forwarding Chain Breakage

Mailing lists, email forwarding rules, and security gateways all modify messages in ways that can break DKIM signatures and change the envelope sender (breaking SPF). ARC was designed to mitigate this, but adoption is still inconsistent. The result: legitimate emails fail authentication, training recipients to ignore authentication warnings.

Which Email Providers Strip Sender IP Addresses

One of the most common reasons people analyze email headers is to find the sender's IP address. But here's what most guides don't tell you: most major webmail providers strip the sender's IP from outgoing headers. If the email was sent through Gmail, you'll find Google's server IPs—not the sender's home or office IP.

The practical implication: if someone sends you a phishing email from a Gmail account, header analysis will tell you it came from Google's servers. You'll see the authentication results and the delivery path between Google and your mail server, but you won't get the attacker's IP from the headers — capturing it directly would mean getting the sender to click a link from an IP Logger tool. For emails from Office 365 corporate accounts or self-hosted mail servers, the sender's IP is usually available and can be geolocated to city-level accuracy.

Tracing an Email's Origin: What's Actually Possible

With the limitations above in mind, here's what email header analysis can and cannot tell you, depending on the scenario:

Scenario 1: Phishing email from a free webmail provider

Headers will show: which provider sent it (Gmail, Yahoo, etc.), authentication results, delivery timestamps, receiving server chain. Headers won't show: the sender's IP address, physical location, or identity. Your best investigative move: report to the provider's abuse team and analyze the email's links/attachments, not the headers.

Scenario 2: Suspicious email from a corporate/business domain

Headers will show: the full delivery chain including sender IP (if using Exchange/O365), complete authentication results, whether the domain's DMARC policy is enforced, any relay servers the message passed through. This is where header analysis is most valuable. If SPF or DKIM fail while DMARC shows p=none, the domain owner isn't enforcing authentication—and the email might be spoofed.

Scenario 3: BEC (Business Email Compromise) investigation

In a BEC investigation, headers are critical evidence. Compare the headers of the suspicious email with known-good emails from the same sender. Look for:

• Different sending infrastructure — If legitimate emails from the CEO come through Office 365 and the suspicious one came through a different SMTP server, that's a red flag.
• Authentication failures — Even partial failures (SPF pass but DKIM fail, or DMARC pass with relaxed alignment) are worth investigating.
• X-Originating-IP changes — If the sender's IP is present and suddenly geolocates to a different country, escalate immediately.
• Reply-To mismatch — A classic BEC technique: the From: shows the CEO's address, but Reply-To points to an attacker-controlled account.
• Timezone inconsistencies — The Date: header shows when the sender's client claims the email was composed. If it's 3 AM in the sender's known timezone, that's suspicious.

Scenario 4: Tracing harassing or threatening emails

If the sender used a free webmail provider (Gmail, Outlook.com, Yahoo), the headers alone won't identify them. The provider has the sender's IP in their internal logs but won't disclose it without a legal process (subpoena or court order). Document the headers and the email content, report to the provider's abuse department, and if the threats are credible, provide the full headers to law enforcement—they can compel the provider to disclose the sender's IP through legal channels.

For any of these scenarios, our Email Header Analyzer will automatically parse the routing chain, geolocate visible IPs, and display authentication results in a readable format.

Frequently Asked Questions

Sources: Statistics cited in this article are sourced from FBI IC3 2024 Annual Report, Darktrace Half-Year Threat Report 2024 (via KnowBe4), Egress Email Security Report, RFC 7208 (SPF), RFC 6376 (DKIM), RFC 7489 (DMARC), and RFC 8617 (ARC).