Email Header Analysis: How to Trace and Investigate Suspicious Emails

Email headers tell the complete story of a message's journey from sender to recipient. They reveal the true origin IP address, every server the message passed through, whether authentication checks passed or failed, and what spam filters scored the message. When a user reports a suspicious email or when you are investigating a security incident, reading headers is often the fastest way to determine whether a message is legitimate, spoofed, or part of a phishing campaign. This guide explains every relevant header field and walks through a complete forensics workflow.

Accessing Full Email Headers

The message body and standard display hide most headers. To investigate, you need the raw RFC 2822 message source.

Gmail: Open the message > three-dot menu > Show original. The full headers appear, or click "Copy to clipboard" to paste into an analysis tool.

Outlook (desktop): Open the message > File > Properties. Internet headers are in the lower pane.

Outlook Web App: Open the message > three-dot menu > View > View message source. Or: open the message, click the three-dot at the top right > View message details.

Apple Mail: View menu > Message > All Headers, or Command+Shift+H.

Thunderbird: View > Message Source (Ctrl+U / Cmd+U).

Once you have the raw headers, paste them into Google Admin Toolbox Message Header Analyzer (toolbox.googleapps.com/apps/messageheader) or MXToolbox Email Header Analyzer (mxtoolbox.com/EmailHeaders.aspx) for a visual representation of the delivery path and timing.

Understanding the Received Header Chain

Every SMTP server that handles a message adds a Received: header at the top of the existing header block. Headers are added in reverse chronological order — the most recent hop is at the top, the original sending server is at the bottom.

Example Received chain (simplified)

Received: from mail.yourcompany.com (mail.yourcompany.com [203.0.113.10])
        by mx.recipient.com with ESMTPS id abc123
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384)
        for <user@recipient.com>; Mon, 09 Mar 2026 14:23:11 +0000

Received: from [192.168.1.45] (unknown [192.168.1.45])
        by mail.yourcompany.com with ESMTP id xyz789
        for <user@recipient.com>; Mon, 09 Mar 2026 14:23:09 +0000

Received: from smtp.sendingservice.com (smtp.sendingservice.com [198.51.100.20])
        by [192.168.1.45] with ESMTPSA id def456;
        Mon, 09 Mar 2026 14:23:07 +0000

Reading from bottom to top:

1. The originating server smtp.sendingservice.com at IP 198.51.100.20 handed the message to an internal relay at 192.168.1.45
2. The internal relay forwarded to mail.yourcompany.com at 203.0.113.10
3. Your mail server delivered to mx.recipient.com over TLS 1.3

What to check in Received headers

Originating IP address: Find the bottom-most Received: header added by a server outside your control. The IP in brackets [...] is the true origin. Run a reverse DNS lookup and WHOIS query on it:

# Reverse DNS
dig -x 198.51.100.20

# WHOIS
whois 198.51.100.20

Compare the hostname and ASN to what you would expect. A message claiming to be from payroll@bigcorp.com that originated from a residential IP in an unexpected geography is suspicious regardless of what the From: header says.

Timing analysis: Each Received: header includes a timestamp. Large gaps between hops (hours instead of seconds) can indicate the message sat in a queue due to delivery problems, or in some cases indicate manipulation.

Encryption: Look for with ESMTPS (TLS encrypted) vs. with SMTP (plaintext) in each hop. An unencrypted hop in the middle of the chain means the message content was exposed at that point.

Authentication Results Header

The Authentication-Results: header is added by the receiving mail server and summarizes the outcome of SPF, DKIM, and DMARC checks.

Example

Authentication-Results: mx.google.com;
  dkim=pass header.i=@sendingdomain.com header.s=selector2026 header.b=AbCdEfGh12;
  spf=pass (google.com: domain of envelope@sendingdomain.com designates 198.51.100.20 as permitted sender)
       smtp.mailfrom=envelope@sendingdomain.com;
  dmarc=fail (p=REJECT sp=REJECT dis=REJECT) header.from=yourcompany.com

Interpreting each result

dkim=pass: The message was signed with the private key for sendingdomain.com, selector selector2026, and the signature verified. This means sendingdomain.com's infrastructure sent the message.

dkim=fail: The signature verification failed. This means either the message was tampered with after signing, or the signing key no longer matches the public key in DNS (key rotation issue).

spf=pass: The sending IP (198.51.100.20) is authorized to send on behalf of sendingdomain.com per its SPF record.

dmarc=fail (p=REJECT): Despite SPF and DKIM passing for sendingdomain.com, neither aligns with yourcompany.com (the From: header domain). The sender is using someone else's infrastructure to spoof yourcompany.com. The p=REJECT means the domain owner has told receivers to reject these messages — if the receiving server respects DMARC (which it should), this message should not have been delivered.

Seeing dmarc=fail in a message that reached the inbox means either the receiving server does not enforce DMARC, or the message was forwarded through a system that bypasses DMARC checks.

X-Spam Headers

Spam filters add headers showing their scoring and decision. The format varies by spam filter software.

SpamAssassin

X-Spam-Status: No, score=2.3 required=5.0 tests=BAYES_20,DKIM_SIGNED,
    DKIM_VALID,HTML_MESSAGE,MIMEOLE_DIRECT_TO_MX,RCVD_IN_DNSWL_NONE
X-Spam-Score: 2.3
X-Spam-Bar: ++
X-Spam-Flag: NO

score=2.3 is below the required=5.0 threshold, so the message was not flagged. The tests= list shows every rule that triggered and contributed to the score. A score near or above the threshold warrants attention even if the message was delivered.

Microsoft 365

X-Microsoft-Antispam: BCL:0;
X-Forefront-Antispam-Report: CIP:198.51.100.20;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:sendingserver.com;PTR:sendingserver.com;CAT:NONE;

SCL: is the Spam Confidence Level (0–9). SCL:1 means not spam. SCL:9 means high confidence spam. CAT: shows the threat category — CAT:PHISH means the message was classified as phishing.

Google Workspace

Gmail does not expose detailed spam scoring in headers for external messages, but you can see the classification:

X-Gm-Message-State: AOJu0YzqR3...
X-Google-Smtp-Source: AGHT...

For internal investigation, the Google Admin Console's Email Log Search provides more detail than headers alone.

Identifying Spoofing and Forgery

Mismatch between envelope and From header

Look at these two fields:

Return-Path: <bounce@attacker.com>      ← envelope sender (MAIL FROM)
From: CEO Name <ceo@yourcompany.com>    ← visible From header

The Return-Path reveals the actual envelope sender. If it is different from the From: domain, this is normal for bulk email but suspicious for a message purporting to be from an executive. This mismatch is also why From: header spoofing can pass SPF — SPF checks the envelope, not the visible From.

Display name spoofing

From: "Your Company Support" <support@attacker-domain.com>

The display name looks legitimate but the actual sending address is different. Many mail clients show only the display name by default. Train users to verify the full email address, not just the display name.

Lookalike domains

From: support@yourcompany-help.com
From: support@yourcompany.net   ← different TLD than yourcompany.com
From: support@yourcornpany.com  ← character substitution (rn → m)

Check the sending domain against your real domain carefully. This is where DMARC p=reject on your primary domain pushes attackers to lookalike domains, which require separate registration and therefore separate detection.

Forensics Workflow for Reported Phishing

When a user reports a suspicious message:

1. Collect the full message source — do not just screenshot it; you need the raw headers
2. Extract the originating IP — bottom Received: header's bracketed IP
3. Check the IP against blocklists — dig A 20.100.51.198.zen.spamhaus.org (note the reversed octets)
4. Check domain registration date — newly registered domains (less than 30 days old) are high-risk: whois attacker-domain.com | grep "Creation Date"
5. Analyze authentication results — DMARC fail combined with a display name impersonating your CEO is a clear phishing indicator
6. Check URLs in the body — extract links without clicking: copy the raw HTML and look at href attributes. Check URLs against VirusTotal
7. Search for similar messages — in your mail platform's admin console, search for messages from the same IP, same domain, or same subject pattern delivered to other users in the past 24–48 hours
8. Quarantine and delete — if confirmed phishing, use admin tools to delete the message from all mailboxes and block the sending infrastructure
9. Document and report — file an incident report, notify affected users if any clicked links, and report the phishing to Google SafeBrowsing or Microsoft at phish@office365.microsoft.com

Automated tools like MXToolbox Email Header Analyzer or Google Admin Toolbox help visualize the delivery path quickly, but understanding the underlying mechanics is what lets you recognize novel attack patterns that automated tools miss.