How to Read Email Headers and Trace a Delivery Problem

A customer swears they never got your invoice. Your sending dashboard says "delivered". Somewhere between those two claims sits a block of text most people never open: the raw headers. Learning to read email headers takes about twenty minutes, and after that you can settle arguments like this one with evidence instead of guesses.

I have spent more hours than I would like staring at headers for small companies whose mail was vanishing. The pattern is almost always the same. Nobody looked at the message itself; everyone looked at dashboards. This guide shows you what to read, in what order, and which lines you can safely ignore.

Where to Find the Raw Headers in Common Mail Clients

You need the full original message, not the friendly summary your client shows. Each client hides it in a different place:

• Gmail on the web: open the message, click the three dots, choose "Show original". You get the headers plus a small summary of SPF, DKIM and DMARC results at the top.
• Outlook on the web: three dots, then "View", then "View message source".
• Apple Mail: View menu, Message, All Headers. Or press Shift, Command and H together.
• Thunderbird: View menu, Message Source, or Control and U.

Ask the recipient for this, not a screenshot. A screenshot cuts off the lines you need and turns timestamps into an image you cannot search. If the message went to spam, the copy in the spam folder still has full headers, and those are the most useful ones of all.

Read Email Headers From the Bottom Up

This is the single habit that makes headers readable. Every server that handles a message adds its own "Received" line at the top. So the oldest hop sits at the bottom and the final delivery sits near the top. Reading top to bottom means reading the story backwards.

Scroll to the lowest "Received" line. That is usually your own sending server or the application that handed the message to it. Work upward one hop at a time. A typical transactional email from a small business passes through three to six hops. If you count twelve, something is relaying it through places it should not go, such as an old forwarding rule or a security gateway nobody remembers buying.

What each Received line tells you

Each line follows roughly the same shape: "from" the server that sent it, "by" the server that accepted it, "with" the protocol, and a timestamp after the semicolon. The "from" part often includes an IP address in square brackets. That address is the one receiving systems judge, so it is worth copying into a note.

Timestamps Show Exactly Where Mail Got Stuck

Delays are the most common complaint and the easiest to diagnose. Compare the timestamps on consecutive Received lines. Watch the time zones: one server may stamp +0000 and the next -0500, so convert before you panic about a five hour gap.

The last row matters most. When the big gap sits on a hop you control, no amount of complaining to the recipient's provider will help. I once traced a "Microsoft is slow" problem to a cron job on the company's own relay that only flushed the queue every 40 minutes.

The Authentication-Results Line Is Your Verdict

Near the top, the receiving provider writes a line called "Authentication-Results". It is the receiver's own judgement of your message, and it outranks anything your sending tool claims. Look for three words: spf=, dkim= and dmarc=, each followed by pass, fail, softfail, neutral or none.

A pass on all three is the baseline you want. The interesting cases are mixed results. SPF can pass while DMARC fails, because DMARC also checks alignment: the domain in your visible From address has to match the domain that passed SPF or DKIM. Newsletter platforms that sign with their own domain cause this constantly. If those records still feel abstract, the explainer on why email authentication records confuse website owners covers the setup side.

Also check the "header.d=" value next to the DKIM result. That is the domain that actually signed. If it reads like your platform's domain instead of yours, you have found your alignment problem in one glance.

Headers Most People Overvalue

Plenty of guides tell you to study every line. I disagree. Most of a header block is noise for diagnosis, and treating it all as meaningful sends people chasing ghosts.

• X-Mailer and User-Agent: they tell you the software, rarely the problem.
• Spam score lines from your own tool: a score of 1.2 from your sending platform says nothing about how Gmail or Outlook rated the message.
• Message-ID: useful for searching logs, useless for judging reputation.
• Long X- headers from security gateways: unless you run that gateway, you cannot act on them.

The lines that matter fit on one screen: the Received chain, Authentication-Results, Return-Path, From, and any provider spam verdict such as Microsoft's "X-Forefront-Antispam-Report" with its SCL value. An SCL of 5 or higher means Outlook filed you as spam.

A Five Step Routine for Any Missing Email

1. Get the full original from the recipient, ideally from their spam or junk folder.
2. Read the Received lines bottom up and note the sending IP and every hop.
3. Compare timestamps and mark any gap longer than a few minutes.
4. Read Authentication-Results and check that the DKIM signing domain matches your From domain.
5. Check the Return-Path. Bounces go there, so a typo in it means you never hear about failures.

If the message never arrived at all, there are no headers to read on their side. Then switch to your own server logs and search for the recipient address. Wider placement problems, like a whole domain sliding into spam over weeks, belong to reputation, which the piece on how email deliverability works explains in more depth.

Reading Headers on Mail You Receive

The same skill protects you from phishing. A message from "your bank" whose lowest Received line shows a residential IP in another country, with dmarc=fail, tells you everything. Display names lie easily. Received chains and authentication verdicts are much harder to fake, because each receiving server writes its own lines and the sender cannot edit them after the fact.

One caution: lines below the first hop your provider added can be forged by the sender. Trust starts at the first Received line written by a server you know, and everything beneath it is a claim, not evidence.

FAQ

Can I read email headers on a phone?

Mostly no. The Gmail and Outlook mobile apps do not show raw headers. Open the same message in a desktop browser, or forward it as an attachment, which keeps the original headers intact.

Does forwarding a message break the headers?

A normal forward replaces them with new ones, so the evidence is lost. Forwarding as an attachment, usually an .eml file, preserves the original headers for whoever investigates.

Why does a message show dkim=pass but still land in spam?

Authentication proves who sent the message, not that receivers want it. Content, sending volume, complaint rates and the reputation of your IP and domain still decide placement after authentication passes.

Keep One Saved Example of a Healthy Message

Send a message from your own domain to a Gmail account today, open the original, and save it as a text file. That is your known good baseline: the right hops, the right signing domain, three passes. The next time someone says your email disappeared, put their headers next to the healthy copy and the difference usually jumps out within two minutes. More guides on this side of the stack live under email infrastructure.