Email Header Analysis: Trace the Origin of Any Email

What Email Headers Are and Why They Matter

Every email carries two distinct parts: the visible message you read and a set of hidden metadata called headers. Headers are appended by every mail server that handles the message, creating a complete audit trail from sender to recipient. They reveal the originating IP address, the mail servers it passed through, authentication results (SPF, DKIM, DMARC), timestamps at each hop, and much more.

Email headers are indispensable for:

• Tracing the true origin of a phishing or spam email
• Diagnosing why a legitimate message was flagged as spam
• Investigating email spoofing where the "From" address is forged
• Confirming whether a message was actually sent by the claimed domain
• Understanding transit delays by comparing timestamps at each hop

Most email clients hide headers by default. In Gmail, open a message, click the three-dot menu, and select "Show original." In Outlook, open the message properties and look for "Internet headers." The raw header block will look like a wall of technical text — but once you know what to look for, it tells a clear story.

Reading Received Headers: Tracing the Mail Path

The most important headers for tracing email origin are the "Received:" headers. Each mail server that handles the message prepends a new Received header, so you read them from bottom to top — the oldest (closest to the origin) is at the bottom, and the most recent (your mail server) is at the top.

A typical Received header looks like:

Received: from mail.attacker.com (mail.attacker.com [198.51.100.45])
        by mx.gmail.com with ESMTP id abc123
        for <victim@gmail.com>;
        Fri, 4 Apr 2026 10:23:14 -0700 (PDT)

This tells you: the server called mail.attacker.com with IP 198.51.100.45 connected to Gmail's mail server and delivered the message. The IP address in brackets is the critical piece — it cannot be forged because it is recorded by the receiving server from the actual TCP connection. The hostname in parentheses, however, is whatever the sending server claims to be — it can be forged.

Take the IP from the bottom-most Received header and look it up using our IP lookup tool to find the true geographic origin, ISP, and organization behind the email.

Authentication Headers: SPF, DKIM, and DMARC Results

Modern mail servers add an "Authentication-Results" header that summarizes whether the message passed SPF, DKIM, and DMARC checks. This is one of the most useful headers for quickly determining whether an email is legitimate.

Authentication-Results: mx.google.com;
  dkim=pass header.i=@paypal.com header.s=pp-dkim1;
  spf=pass (google.com: domain of service@paypal.com designates 66.211.169.3
             as permitted sender) smtp.mailfrom=service@paypal.com;
  dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=paypal.com

Understanding the results:

• dkim=pass: The cryptographic signature is valid — the message was not tampered with, and it was signed by the claimed domain's private key.
• spf=pass: The sending IP is authorized by the domain's SPF DNS record.
• dmarc=pass: The message passes the domain's authentication policy.
• dmarc=fail: A red flag — the message may be spoofed or sent from an unauthorized server.
• spf=softfail: The sending IP is not in the SPF record but the domain hasn't enforced a hard failure policy.

A phishing email claiming to be from your bank will often show dmarc=fail or missing authentication entirely — use our HTTP headers tool for additional header inspection capabilities.

Detecting Email Spoofing

Email spoofing is the practice of forging the "From" address to make a message appear to come from a trusted source. It is the foundation of most phishing attacks. Headers reveal the discrepancy between what is claimed and what is real.

Key indicators of spoofing:

• From vs. Return-Path mismatch: The "From" header is what you see in your email client. The "Return-Path" (also called envelope-from or MAIL FROM) is where bounces are sent and what SPF checks. If they belong to different domains, it is a strong spoofing signal.
• Reply-To redirect: Phishers often set the Reply-To address to their own domain while keeping a legitimate-looking From address. Replying sends your response to the attacker.
• DMARC failure: If the message claims to be from a major domain like PayPal or Microsoft but DMARC fails, the domain's authentication policy has not been satisfied — almost certainly a spoof.
• Unexpected originating IP: Look up the originating IP with our IP lookup tool. If a message claiming to be from a US bank originates from an IP in Eastern Europe or a residential ISP, that is suspicious.
• X-Originating-IP: Some services include the actual client IP of the person who sent the message — this can reveal the attacker's location even when they route through legitimate relays.

Analyzing Delays and Diagnosing Delivery Issues

Headers also serve a practical operational purpose: diagnosing why a message took hours to arrive or was delayed. Each Received header includes a timestamp. Comparing timestamps between consecutive hops reveals exactly where the delay occurred.

For example, if the first Received header has a timestamp five minutes after the second-to-last one, there was a five-minute processing delay at that particular mail server. Common causes of delay include:

• Greylisting: The receiving server temporarily rejected the message to force a retry, which is a common anti-spam technique. Legitimate mail servers retry; spam bots often do not.
• Content filtering: The message was queued while antivirus or spam scanning ran.
• DNS lookup failure: A mail server could not resolve a hostname, causing a timeout before retrying.
• High server load: The destination mail server was overloaded.

For persistent delivery failures, cross-reference the sending IP in our IP lookup tool and check it against known blacklists. A blacklisted IP will cause most receiving servers to reject or heavily delay messages.

Frequently Asked Questions