How to Read Email Headers: Tracing a Message From Send to Inbox

Every email you receive arrives with a small mountain of metadata attached. Your mail client hides most of it — From, To, Subject, Date, body, done — but underneath sits a stack of headers recording every server the message touched, when it was handed off, whether each leg was encrypted, and what the receiver thought about its authenticity. The metadata is sometimes the most useful part of the message. It's how you tell a real notification from a phishing attempt, debug why a perfectly legitimate email landed in spam, or work out why a customer's reply took four hours to reach you.

This is a practical guide to reading those headers. We'll cover how to find them in any mail client, walk through a real Received chain hop by hop, talk through the authentication results, and finish with the red flags that should make you pause.

When you'd actually look

A few common situations:

• Deliverability debugging. "Why did this email go to spam?" The receiving server's authentication-results header usually tells you in one line.
• Phishing investigation. "Is this really from my bank?" If the visible From: is your bank but the message came through a server in a country your bank doesn't operate from, the Received chain shows it.
• Delay diagnosis. "Why did this take 4 hours to arrive?" Timestamps between consecutive Received hops show exactly where the message got stuck.
• Forensic sender verification. "Did this really come from where it claims?" The SPF and DKIM results, combined with the origin IP, give you the answer.

How to find raw headers

Every major mail client has a "view raw" or "show original" option. They're all hidden behind a menu, but they're all there:

• Gmail — Open the message → click the three-dot menu (⋮) next to the reply button → Show original. A new tab opens with the auth results at the top and the full raw message below.
• Outlook (web) — Open the message → three-dot menu → View message source.
• Outlook (desktop) — File → Properties → "Internet headers" box at the bottom.
• Apple Mail — View → Message → All Headers (or ⌘⌥U).
• Yahoo Mail — Open the message → three-dot menu → View raw message.
• Thunderbird — View → Message Source, or Ctrl+U / ⌘U.

Copy everything from the first header line down to (but not including) the blank line that separates headers from the body. That blank line is the boundary — the body is irrelevant for header analysis.

The anatomy of email headers

Headers are simple key-value pairs, one per line, in the form Name: value. Server names, route information, and authentication results all live here. A few quirks to know about:

• Headers are added top-to-bottom as the message travels. Every server stamps a new Received: header onto the top of the message before forwarding it on. That means when you read the raw text, the top Received: is the most recent hop, and the bottom one is the origin.
• Lines can fold. If a header value is too long, RFC 5322 lets it continue on the next line as long as that line begins with whitespace. So Received: from a (...) followed by an indented line is one logical header, not two.
• Order matters. Within a category like Received, the order is the route. The same isn't true for other headers — From and Subject can appear in any order.

Reading the Received chain

This is the heart of header analysis. Here's a real-looking three-hop chain, read bottom to top (origin first):

Received: from mail-gateway.example.com (mail-gateway.example.com [203.0.113.50])
    by mx.google.com with ESMTPS id abc123
    for <you@gmail.com>;
    Mon, 5 May 2026 10:42:03 -0700 (PDT)

Picking the line apart:

• from mail-gateway.example.com — the hostname the connecting server identified itself as. The address in square brackets is the IP that connection actually came from, which the receiver looks up by reverse DNS. If those two don't match, the receiver makes a note of it (some flag it; others penalise it in spam scoring).
• by mx.google.com — the server that accepted this hop. In this example, Google's MX accepted the message from mail-gateway.example.com.
• with ESMTPS — the protocol. ESMTPS means the connection was negotiated up to TLS — encrypted in transit. ESMTP means extended SMTP without encryption (plain text on the wire). SMTP is the original unencrypted protocol. You want every leg to say ESMTPS, particularly the public legs across the internet.
• for <you@gmail.com> — the recipient this hop was for. Bcc'd recipients sometimes appear here, which is one reason this field exists.
• Mon, 5 May 2026 10:42:03 -0700 (PDT) — when this hop happened. Note the timezone offset; consecutive hops in different timezones look weird until you normalise to UTC.

Now look at three of these stacked together. The bottom one is the origin server — usually your mail gateway, your transactional mail provider, or the sender's actual outbound mail server. The top one is the last hop before the message landed in the recipient's mailbox. Between them is the path the message took: every relay, every TLS upgrade, every queue.

Spotting delays

Compare timestamps between consecutive Received headers. Email is usually fast — most legitimate messages cross the entire internet in under five seconds. When you see longer gaps, the most common explanations are:

• A few seconds. Normal. Different servers, different clocks, slight queue depth.
• 30 seconds to a few minutes. Often greylisting — the receiver intentionally rejects the first delivery attempt from any new sender and waits for the sender to retry. Legitimate mail servers always retry; many spam bots don't. Greylisting frustrates first-time deliveries but generally clears within 15 minutes.
• 30 minutes to several hours. Queue backup somewhere. Either the receiving side was temporarily down and the sender retried, or an intermediate relay accumulated a backlog (Black Friday email blasts, post-incident floods).
• A day or more. Something went badly wrong. Usually a misconfigured mail server, but occasionally a compromised relay that's quietly holding messages for inspection. Worth investigating.

Authentication results

Most large receivers stamp an Authentication-Results: header at the top of the message summarising the SPF, DKIM, and DMARC checks. The format varies slightly, but you're looking for three things:

Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=newsletter@example.com;
       dkim=pass header.d=example.com header.s=selector1;
       dmarc=pass (p=reject) header.from=example.com

• spf=pass — the sending server is authorised for the envelope sender's domain. (For the full picture, see SPF records explained.)
• dkim=pass — the cryptographic signature on the message body and headers verified successfully. The signing domain (header.d=) and selector (header.s=) identify which key was used.
• dmarc=pass — at least one of SPF or DKIM authenticated a domain that aligns with the visible From: header. The (p=reject) note shows the policy the sender has published. (For more, see DMARC explained.)

All three passing on a legitimate transactional message is the expected outcome. One failure isn't proof of fraud — forwarders routinely break SPF, mailing lists sometimes break DKIM — but when all three fail and the message still landed in your inbox, treat it with caution.

Red flags to watch for

The patterns that should make you pause:

• From: ≠ Return-Path: the visible sender and the envelope sender don't match. Legitimate cases exist (mailing lists, bounce handling), but it's the most common signature of envelope spoofing.
• Reply-To different from From: the classic phishing pattern. The message looks like it's from your boss, but if you hit Reply, your response goes to an address the attacker controls.
• SPF/DKIM/DMARC failures on a major sender. If Gmail, Microsoft, Amazon SES, Mailchimp, or any other large provider sends you a message that fails authentication, something is wrong. These services almost never fail their own auth checks.
• Missing TLS on a leg. If any Received line says with ESMTP (no S) or just with SMTP, that hop was unencrypted. Internal-network hops sometimes legitimately skip TLS; public-internet hops shouldn't.
• Unusual origin IP. The first external IP in the Received chain is where the message actually came from. If a "PayPal" message originated from a residential ISP in a country PayPal doesn't operate from, you have your answer. Look up the IP at our IP lookup tool to see the geolocation, ASN, and ISP.
• Bizarre hop chain. A message that bounced through six relays in three countries before reaching you is unusual. Legitimate mail typically takes one to three hops.

Headers you can mostly ignore

Most of what's in the raw text is operational plumbing, not security-relevant signal. You can skim past:

• X-Google-DKIM-Signature and X-Gm-Message-State — Google's internal bookkeeping. They exist to help Google's own systems track and verify messages; they don't change the analysis.
• MIME-Version, Content-Type, Content-Transfer-Encoding — formatting metadata for the body. Useful if you're debugging why an attachment is broken, irrelevant for sender verification.
• Most X-* headers — vendor-specific. Mail platforms add their own tracking IDs, internal flags, and audit notes. You'll occasionally find something interesting (X-Originating-IP in older Outlook messages, X-Spam-Score from server-side filters), but most are noise.
• Message-ID — globally unique identifier the sender assigned. Useful for replying with In-Reply-To, not useful for telling whether the message is legitimate.

The signal is concentrated in Received, Authentication-Results, From, Reply-To, and Return-Path. Everything else is mostly background detail.

The Received chain is the route. The Authentication-Results line is the verdict. Everything else is context.

Reading headers by hand is a useful skill once or twice. Doing it routinely is tedious, and the human mistake rate goes up fast when you're skimming for one thing in a forest of plumbing. The email header analyzer parses everything in your browser — no data is sent to our servers — and renders the route as a timeline, the auth as colour-coded chips, the sender fields with cross-domain mismatches flagged, and any slow hops surfaced explicitly. Paste the raw block, get the verdict, move on.