Tracing Spam from Email Headers: What to Look For

Every email carries a hidden paper trail. While the visible portion shows you the sender's display name and subject, the real story lives in the headers — a stack of metadata fields written by every mail server that touched the message. If you know how to read them, you can trace a spam message back to its actual origin, spot forged sender addresses, and decide whether to block an IP, a domain, or an entire netblock.

Where to find the raw email headers

Headers are stripped from most webmail UIs by default. You need the raw source to see them:

• Gmail: Open the message → three-dot menu → Show original.
• Outlook (web): Three-dot menu → View → View message source.
• Outlook (desktop): File → Properties → Internet headers.
• Apple Mail: View → Message → All Headers (or Raw Source).
• Thunderbird: View → Headers → All, or Ctrl+U for source.

Copy the entire block from the top of the message through the first blank line — that's the header section.

The fields that actually matter for spam tracing

Received: lines (read bottom to top)

Each mail server prepends its own Received: line as the message passes through. The bottom-most Received line is closest to the original sender; the top-most is your inbox server.

Received: from mail.suspicious-host.ru (mail.suspicious-host.ru [185.220.101.47])
    by mx.google.com with ESMTPS id abc123
    for <you@example.com>; Tue, 12 Nov 2024 09:14:22 -0800 (PST)

The IP in square brackets is what your server actually saw connecting to it — this is harder to forge than the hostname before it. Trace that IP with WHOIS or an IP geolocation lookup to find the hosting provider, country, and abuse contact.

Return-Path and From

The From: header is what the user sees and is trivially forged. The Return-Path: (also called the envelope sender or MAIL FROM) is what receiving servers use for bounces. A mismatch between these two — especially when the visible From looks like your bank but the Return-Path is bounce@randomdomain.xyz — is a classic phishing tell.

Authentication-Results

This single header summarises what the receiving server verified:

Authentication-Results: mx.google.com;
    spf=fail (google.com: domain does not designate 185.220.101.47 as permitted sender) smtp.mailfrom=paypal-security.tk;
    dkim=none;
    dmarc=fail (p=REJECT) header.from=paypal.com

• spf=pass — the sending IP is authorised by the envelope sender's domain.
• dkim=pass — the message was cryptographically signed and the signature matches.
• dmarc=pass — SPF or DKIM aligned with the visible From domain.

A spam message often shows spf=fail, dkim=none, and dmarc=fail. Legitimate mail from major brands will almost always pass all three.

Message-ID

The Message-ID contains the originating server's domain on the right side of the @. If a message claims to be from support@microsoft.com but the Message-ID is <xyz@mailer.shadyhost.cn>, that's a strong forgery indicator.

X-Originating-IP and X-Mailer

Some providers add an X-Originating-IP header showing the actual client IP that submitted the message. X-Mailer reveals the software used — bulk spam tools like PHPMailer, Mass Mail Sender, or unbranded scripts often appear here, whereas a normal user shows Apple Mail or Outlook.

A practical walkthrough

Suppose you receive a phishing email claiming to be a shipping notification. Here's the workflow:

1. Pull the raw headers using the steps above.
2. Paste them into a parser. The AXOX Hub Email Header Analyzer breaks the Received chain into a readable hop-by-hop list, flags authentication failures, and resolves the originating IP automatically.
3. Check the bottom Received line. Note the IP and hostname. If the hostname doesn't resolve back to the same IP (forward-confirmed reverse DNS), suspect spoofing.
4. WHOIS the originating IP. Tools like whois 185.220.101.47 on the command line, or any web WHOIS, will tell you the netblock owner and abuse email.
5. Compare From, Return-Path, and Message-ID domains. Mismatches between these are red flags.
6. Read the Authentication-Results. Multiple failures + a brand-name From = phishing.
7. Report to the abuse contact. Forward the full message with headers intact to the hosting provider's abuse@ address. Most providers will null-route confirmed spam sources.

Common spammer tricks to recognise

• Injected fake Received lines: Spammers add bogus Received headers below their real one to make the trail look legitimate. The lowest Received line your trusted server added is the real starting point — anything below it could be invented.
• Display-name spoofing: The From shows "PayPal Security" <noreply@randomdomain.xyz>. Mail clients often hide the actual address.
• Lookalike domains: paypa1.com, microsoft-support.net, or punycode tricks like xn--pypal-4ve.com.
• Open relay abuse: Mail routed through compromised legitimate servers to pass SPF on a third-party domain.
• Reply-To redirection: The From looks normal but Reply-To points to a free webmail account where the scammer collects responses.

What to do with the evidence

Once you've identified the originating IP and netblock:

• Add the IP or /24 to your mail server's blocklist (Postfix check_client_access, or your gateway's RBL configuration).
• Submit the IP to community blocklists like Spamhaus SBL, SORBS, or AbuseIPDB so others benefit.
• Email the abuse contact with the full headers — most cloud providers (AWS, DigitalOcean, OVH) terminate spammer accounts when given concrete evidence.
• If the message impersonates your own brand, publish or tighten a DMARC policy with p=reject and an rua= reporting address so you receive aggregate reports of spoofing attempts.

Try it on a real message

The fastest way to learn is to run a suspicious message through a parser and compare it to a known-good one from the same sender. Paste your raw headers into the free AXOX Hub Email Header Analyzer to see the full hop-by-hop trace, SPF/DKIM/DMARC results, and originating IP details in one view.