Email Header Analysis Guide: How to Read Email Headers & Trace the Source

What Email Headers Actually Are

Every email is really two parts stapled together: a block of headers (metadata about the message) followed by the body (what you actually read). Headers are added incrementally as the message travels — the sender's outgoing server writes the first ones, then every relay, spam filter, and gateway the message passes through prepends its own, so by the time it lands in your inbox, a message that started with perhaps six or seven headers can easily carry twenty or more. None of this is visible in a normal inbox view, which deliberately hides it to keep the reading experience clean.

The headers that matter most for tracing a message fall into a handful of categories: identity headers (From, To, Subject, Date), routing headers (the repeated Received lines showing every hop), and authentication headers (Authentication-Results, Return-Path) that record whether the sending domain was actually verified. Understanding just these three groups covers the vast majority of what anyone actually needs headers for.

Getting Raw Headers Out of Gmail, Outlook, and Apple Mail

In Gmail (web), open the message, click the three-dot menu in the top-right corner of the message pane, and select "Show original." This opens a new tab containing the complete raw source with every header intact, along with a copy-friendly text box. In Outlook desktop, open the message, go to File → Properties, and look for the "Internet headers" box near the bottom of that dialog — it's easy to miss since it's a small scrollable text area rather than a prominent panel. Outlook on the web hides the same information behind the three-dot menu on an open message, under "View" → "View message source."

On Apple Mail for macOS, open the message and choose View → Message → All Headers to see just the header block, or "Raw Source" for the complete message including the body. Mobile mail apps generally don't expose raw headers at all — if you need to inspect a message received on a phone, the most reliable path is opening the same account's webmail interface instead, or forwarding the message as an attachment to an account where you do have desktop access.

The Received Chain: How to Read It in the Right Direction

Each Received header is written by one mail server as it accepts the message, and every hop adds a new one to the very top of the header block — meaning the chain reads newest-to-oldest from top to bottom in the raw text. Flip that around by reading from the bottom up, and you get the message's actual chronological journey: the bottommost Received line is closest to the original sending server, and each one moving upward represents the next relay, gateway, or filter the message passed through before reaching your inbox.

A typical Received header follows a recognizable pattern: from [sending host] by [receiving host] with [protocol]; [timestamp]. The "from" portion usually includes the sending server's hostname and, in parentheses or brackets, its actual IP address — the piece of information you need if you're trying to trace the message's true network origin rather than just its claimed domain name.

Tracing the Originating IP Address

Once you've identified the bottommost (earliest) Received header, look for an IP address in square brackets, typically following the sending hostname. This is the actual network address the message was accepted from — not necessarily the sender's personal computer, but the mail server (often a webmail provider, an office SMTP server, or a bulk-sending platform) that first introduced the message to the wider mail system. Running that IP through a lookup tool tells you its owner, approximate location, and hosting provider, which is often the single most useful fact for judging whether a message's claimed origin makes sense.

Be careful about which IP you're actually looking at, though. Internal, private-range addresses (starting with 10., 172.16–31., or 192.168.) that show up in early hops within a large organization's own mail infrastructure aren't the true origin — they're just internal routing before the message left that organization's network. Skip past those and keep looking further down the chain (or further up in raw reading order) for the first public IP address, which is where the message actually entered the broader internet.

Reading the Delay Between Hops

Every Received header ends with a timestamp, and comparing consecutive timestamps tells you how long the message sat at each stage of its journey. Most hops in a healthy delivery chain take well under a second; a gap of several minutes or hours at one specific hop points to a genuine bottleneck worth investigating — a congested relay, a greylisting delay, or a queue backup at one particular server, rather than a network-wide problem.

Occasionally you'll see a hop with a timestamp technically earlier than the one before it, producing a negative delay when subtracted. This is clock skew — two servers whose system clocks aren't perfectly synchronized — and on its own it's rarely meaningful. It becomes worth noting only when it appears alongside other inconsistencies, since a completely fabricated header chain sometimes shows more dramatic and less explainable timestamp irregularities than ordinary clock drift.

Other Header Fields Worth Recognizing

Return-Path shows where bounce notifications are sent, and frequently reveals the actual sending infrastructure behind a message even when the visible From address shows a completely different domain — extremely common and often entirely legitimate with bulk email platforms sending on a client's behalf. Message-ID is a unique identifier the originating server assigns, useful for correlating a specific message across logs, though trivially fakeable and not a trust signal by itself. X-Mailer or User-Agent identifies the software that composed the message, which can occasionally reveal a mismatch worth a second look — a message claiming to come from a major provider's web interface but showing an unfamiliar, unbranded mailer value.

A Worked Walkthrough, One Header at a Time

Take a simplified real-world header block and walk through it the way you actually would in practice. Near the top: Delivered-To: you@example.com and Return-Path: <bounce@sender-platform.com> — already one useful fact, since the bounce address differs from whatever the visible From header will show, which is worth remembering as you keep reading. Next come the Received headers, several of them stacked, each with its own "from," "by," and timestamp.

Starting from the bottommost Received header (the earliest hop) and working upward: the first one shows from mail-relay.sender-platform.com [198.51.100.20] — this is very likely the true origin, a specific IP belonging to whatever platform actually sent the message. The next hop up shows an internal handoff within that same platform's own infrastructure, with a private or platform-internal address, not a new external server. The final (topmost) Received header shows your own provider's mail server accepting the message for final delivery to your inbox — the hop that matters least for tracing origin, but the one most people mistakenly look at first.

Further down in the headers, From: Notifications <alerts@sender-platform.com> and Subject: Your weekly summary round out the identity fields, and an Authentication-Results header (the focus of our companion guide on reading SPF, DKIM, and DMARC results) confirms whether all of this actually checks out cryptographically, not just structurally.

Manually Reading Headers vs Using an Analyzer

Learning to read a chain manually at least once is genuinely worthwhile — it builds the intuition to sanity-check an automated tool's output and to recognize when something in a header looks unusual even before running it through anything. But for routine checks, an automated analyzer removes the tedious and error-prone parts (chain reversal, timestamp math) while leaving the actual judgment calls to you.

Real Scenarios for Tracing a Message's Source

An unexpected password-reset email arrives for an account you don't remember requesting a reset on. Tracing the originating IP and comparing it against the service's known infrastructure (or simply checking whether the IP geolocates somewhere plausible) helps distinguish a genuine security event from a message that was never really sent by that service at all.

A recruiter's message promises an unusually generous remote role after minimal vetting. The originating server in the earliest Received header, and whether it matches any infrastructure remotely associated with the claimed company, often tells you more in ten seconds than the message's actual wording does.

An internal team debugging delivery delays for their own transactional email needs to know exactly which hop in their own pipeline is slow — their ESP, an internal relay, or the recipient's own server — and the hop-by-hop timestamp trail is the only place that answer actually lives.

A support agent investigating a phishing report from a customer needs to determine the actual sending infrastructure behind a reported message, separate from whatever domain the message claimed to be from, in order to decide whether to escalate it and to whom.

What an Inconsistent Header Chain Often Looks Like

Beyond a single origin IP, certain patterns in the overall chain are worth a second look. A message with an unusually short chain — just one or two Received headers — for a claimed sender that would normally route through several well-known relays can indicate the headers were partially fabricated rather than genuinely generated by a real mail transaction. Similarly, a hostname in an early Received header that doesn't resolve to anything, or that bears no resemblance to the claimed sending organization's actual domain, is a concrete, checkable detail rather than a vague impression.

None of these patterns are proof on their own — legitimate mail infrastructure varies enormously in how many hops a message picks up, and hostname mismatches sometimes reflect nothing more than a third-party sending platform. Treat header-chain oddities as a prompt to check the actual authentication results next, covered in full in our companion guide on reading SPF, DKIM, and DMARC results, rather than as a conclusion in themselves.

A Quick Checklist Before You Trust or Escalate a Message

• Locate the bottommost Received header and check whether the IP or hostname there plausibly matches the claimed sender.
• Check the Return-Path domain against the visible From domain — a mismatch alone isn't damning, but combined with other signals it matters.
• Look at hop delays for anything wildly abnormal, keeping in mind that most irregularities have mundane explanations.
• Cross-reference with the Authentication-Results header rather than relying on header tracing alone — the two are genuinely complementary, not redundant.
• Escalate based on the combination of signals, not any single one in isolation — that's the pattern real spoofing detection actually relies on.

What Header Tracing Can't Tell You on Its Own

Tracing a message back to its originating IP and server tells you where it technically came from, but not whether that origin is trustworthy. A message can trace back to a completely legitimate, well-known email service provider while still being a phishing attempt sent through a compromised or abused account on that same platform — large, reputable providers are common launch points for spam precisely because their infrastructure is trusted by default. Origin tracing is one input, not a verdict, and pairs best with checking the actual authentication results (covered in depth in our companion guide on reading SPF, DKIM, and DMARC results in headers) rather than being treated as conclusive on its own.

FAQ