How to Read Email Headers: A Field Guide for Diagnosing Delivery Problems

When an email doesn't arrive, lands in spam unexpectedly, or shows up looking like it came from somewhere it didn't, the answer is almost always sitting in the headers — you just have to know where to look. Most people never open a raw email header because their client hides it by default, but learning to read one is one of the highest-leverage troubleshooting skills for anyone managing a domain's email.

How to actually view the raw headers

Every major client has a way to expose the full header block, though it's buried a few clicks deep. In Gmail, open the message, click the three-dot menu, and choose "Show original." In Outlook, open the message, go to File, then Properties, and look at the Internet headers box. In Apple Mail, use View, then Message, then All Headers. Once you have the raw text, you're looking at a stack of metadata that was added by every server the message passed through, in reverse chronological order — the top entries are the most recent hops, and the bottom entries are closest to the original sender.

The header fields that actually matter for troubleshooting

Most of a header block is noise for diagnostic purposes. These are the fields worth focusing on:

• Received: Each server the message passed through adds one of these, stamped with a timestamp and the IP addresses involved. Reading from the bottom up traces the message's actual path, which is useful for spotting an unexpected hop or a suspicious relay.
• Authentication-Results: This is where you find out whether SPF, DKIM, and DMARC actually passed for this specific message, as evaluated by the receiving server — not just whether your DNS records are technically correct, but whether this exact email satisfied them.
• Return-Path: The address bounces are actually sent to, which is often different from the visible "From" address and worth checking when bounce handling seems broken.
• Message-ID: A unique identifier assigned by the originating server, useful when you need to reference a specific message with a mailbox provider's support or postmaster team.
• X-headers: Anything prefixed with X- is typically added by a specific mail system (spam scores, routing hints, internal tags) and varies by provider, but can hold clues a standard field won't.

Reading the Authentication-Results line

This is usually the single most useful line for deliverability troubleshooting. It looks something like this:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@yourdomain.com;
  spf=pass smtp.mailfrom=yourdomain.com;
  dmarc=pass header.from=yourdomain.com

If any of these say fail instead of pass, that's your first lead. A DKIM fail often means the message was modified in transit after signing, or the signing key doesn't match what's published in DNS. An SPF fail usually means the sending IP isn't authorized in your SPF record. A DMARC fail means neither SPF nor DKIM aligned properly with the visible From domain, which is worth cross-referencing against your DMARC policy and aggregate reports for the bigger picture.

Tracing a delivery delay through Received headers

If a message took an unusually long time to arrive, the timestamps on each Received line will show you exactly where the delay happened. Subtract the timestamp on one Received line from the one above it, and you can pinpoint whether the holdup was at your outbound relay, a downstream spam filter, or the recipient's own mail system queuing it. This is far more precise than guessing, and it's the kind of detail worth having on hand before escalating a delivery issue with a mailbox provider's postmaster tools.

Common things headers reveal that aren't obvious otherwise

• A message actually routed through an unexpected relay or forwarding service, which can break DKIM alignment
• The sending IP doesn't match what you expected, suggesting a misconfigured send path or an unauthorized sender
• A spam score or classification added by an intermediate filter, visible in an X-header even when the message still landed in the inbox
• Whether a "reply-to" address quietly differs from the visible sender, sometimes a sign of a phishing attempt riding on a spoofed From address

Building this into your regular troubleshooting

Reading headers isn't something to save for emergencies. If you operate SMTP infrastructure at any real volume, spot-checking headers on a sample of outbound mail periodically will surface authentication issues before they turn into a deliverability problem serious enough for someone to notice unprompted. It's a five-minute habit that catches problems a dashboard summary can easily smooth over. If you want more context on what "pass" and "fail" actually mean for your setup, MailDog's DNS and authentication tools lay out how each record ties back to what shows up in the header.