How to Read Email Headers and Diagnose Delivery Issues

What Are Email Headers?

Every email message consists of two parts: the body — the content you read — and the headers, a block of structured metadata that describes the message's journey from sender to recipient. Headers record every server the message passed through, the authentication checks performed along the way, timestamps, spam filter verdicts, and much more.

Most email clients hide headers by default because they are not intended for casual reading. But when a message ends up in spam, gets rejected, or takes an unexpectedly long time to arrive, headers are the primary diagnostic source. Learning to read them turns a confusing delivery problem into a solvable one.

How to View Email Headers

The method for accessing full headers varies by email client:

• Gmail: Open the message, click the three-dot menu in the top-right corner of the message, and select Show original. This opens a new tab with the complete raw message including all headers.
• Outlook (desktop): Open the message, go to File → Properties. The Internet headers box at the bottom of the dialog contains the full header block.
• Apple Mail: Open the message and go to View → Message → All Headers. You can also press Shift + Cmd + H.
• Thunderbird: Open the message and go to View → Message Source (or press Ctrl + U). The headers appear at the top of the raw source.

Once you have the raw headers, copy them and paste them into a tool like the DMARCFlow Email Header Analyzer for a structured, human-readable breakdown.

Understanding the Received Headers

The most important headers for tracing a message's delivery path are the Received: headers. Each mail server that handles the message prepends a new Received: header describing itself, the server it received the message from, and the timestamp.

A critical point that confuses many people: Received headers are in reverse chronological order. The header at the very bottom is the first hop — the originating server. The header at the very top is the last hop — the server that delivered the message to your inbox. Reading from bottom to top traces the full path.

Each Received: header typically includes:

• from — the server that sent this hop (hostname and IP)
• by — the server that received this hop
• with — the protocol used (SMTP, ESMTP, ESMTPS)
• for — the recipient address
• A timestamp indicating when this hop occurred

By comparing timestamps between consecutive hops, you can identify delays. A gap of several minutes between two hops often indicates greylisting — a technique where receiving servers temporarily defer unknown senders to filter out spam bots that do not retry.

The Authentication-Results Header

The Authentication-Results: header is added by the receiving mail server and records the outcome of SPF, DKIM, and DMARC checks for the incoming message. It is one of the most useful headers for diagnosing authentication failures. A passing message looks like this:

Authentication-Results: mx.example.com;
  spf=pass (google.com: domain of sender@yourdomain.com designates 203.0.113.1 as permitted sender)
  dkim=pass header.i=@yourdomain.com header.s=selector1
  dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=yourdomain.com

When any of these show fail or softfail instead of pass, that is a direct signal to investigate your SPF, DKIM, or DMARC configuration. The value in parentheses often explains why — for example, which IP address was evaluated against SPF, or which DKIM selector was checked.

X-Spam and Spam Score Headers

Many receiving servers run spam-scoring software — most commonly SpamAssassin — and embed their verdict in X-Spam-* headers before delivering the message. Common headers include:

• X-Spam-Status: — Usually Yes or No followed by the numerical score and a list of rules that fired, for example: X-Spam-Status: Yes, score=7.8 required=5.0 tests=BAYES_99,HTML_MESSAGE,MISSING_DATE
• X-Spam-Score: — The raw numerical score. Anything above the threshold (typically 5.0 for SpamAssassin) is treated as spam.
• X-Spam-Flag: — A simple YES or NO indicator.

The list of rule names that fired is particularly useful. Rules like BAYES_99 mean the Bayesian filter is highly confident the message is spam based on content. Rules like MISSING_DATE, NO_RECEIVED, or FORGED_RCVD_TRAIL indicate structural or technical problems with the message construction itself.

Diagnosing Common Problems

Armed with the headers, most delivery problems map to a small set of root causes:

• SPF fail: The Authentication-Results header shows spf=fail and names the sending IP. That IP is not listed in your domain's SPF record. Either update your SPF record to include that sending service, or the message was sent from an unauthorized source that needs to be investigated.
• DKIM fail: dkim=fail typically means the DKIM signature did not verify. Common causes: the message body was modified in transit (by a mailing list, forwarding service, or Content Security scanner), the DKIM key was rotated without updating DNS, or the selector referenced in the header does not exist in DNS.
• DMARC fail: dmarc=fail means neither SPF nor DKIM passed and aligned with the From domain. Even if SPF passes for a third-party relay, if the relay's domain does not align with your From header domain, DMARC still fails. This is the most common cause when switching to a new email service provider.
• Long delays between Received hops: A gap of 5–15 minutes usually means greylisting. A gap of hours suggests a queue backup on one of the intermediary servers, possibly due to the destination server rate-limiting your sending IP.
• High spam score with content rules: The message content itself is triggering filters. Review the fired rules. Common triggers include excessive use of HTML formatting, all-image emails with no text, spam trigger words, or a broken text-to-HTML ratio.

Using the DMARCFlow Email Header Analyzer

Reading raw headers manually takes experience and time. The DMARCFlow Email Header Analyzer automates the process: paste your full raw headers into the tool and it returns a structured analysis of the delivery path, authentication results, spam scores, and a plain-language summary of any issues found. It is the fastest way to move from "why did this message land in spam?" to a concrete answer and a path to fixing it.