Why did my email go to spam?

Check the authentication results in the headers first. A DMARC failure is the single strongest signal, because it means the domain in the From line did not authorise the message in a way the receiver could verify. SPF or DKIM failing alone is weaker — SPF breaks legitimately on forwarding and DKIM breaks when a mailing list modifies the message.

Why are Received headers in reverse order?

Each server adds its line at the top of the block rather than the bottom, so the raw list runs newest to oldest — the opposite of how the message travelled. Read from the bottom up, or use a tool that reverses them for you. This trips up nearly everyone reading headers for the first time.

What causes a several-minute delay at one hop?

Usually greylisting. The receiving server deliberately rejects the first delivery attempt and accepts a retry minutes later, on the theory that spam software rarely retries. It is not a network fault and there is nothing to fix — it is working as designed, and it is invisible unless you read the timestamps.

Can I find out who really sent an email from the headers?

Sometimes, but less often than people expect. The earliest Received hop may name the originating host, but Gmail, Outlook and other large providers deliberately strip or replace that for their users' privacy, so you usually see only the provider's own infrastructure rather than the sender's computer.

Is it safe to paste email headers into an online analyser?

It depends entirely on the tool. Headers contain your address, the sender's, the subject line and frequently internal hostnames and IP addresses from a company network. Most established analysers post all of that to a server. Prefer one that parses in your browser, and check the network tab if the claim matters to you.

September 7, 2026 · 8 min read

How to Read Email Headers: Delivery Path, Delays and Spam Signals

Email headers record every server that touched a message, how long each held it, and whether the sender was who they claimed. Here is how to read them without guessing.

An email arrived late, or landed in spam, or looks like it might be a phishing attempt. The answer is usually recorded in the headers — a block of text your mail client hides because it is nearly unreadable raw. Our email header analyzer parses them in your browser, but the structure is worth understanding whichever tool you use.

Quick answer

What you want to know	Where to look
Which servers handled it	The `Received` chain, read bottom-up
Where the delay happened	Timestamps between consecutive `Received` lines
Whether the sender is genuine	`Authentication-Results` — SPF, DKIM, DMARC
Why it went to spam	A DMARC failure, most often
Who really sent it	Earliest `Received` hop — frequently stripped by big providers

The Received chain runs backwards

This is the single thing that confuses people first.

Every server that handles a message adds a Received header — at the top of the block, not the bottom. The result is that the raw list runs newest to oldest, the reverse of how the message actually travelled.

Received: from relay.provider.net by mx.recipient.com; 10:05:00   ← arrived last
Received: from smtp.sender.example by relay.provider.net; 10:00:30
Received: from laptop.local by smtp.sender.example; 10:00:00      ← started here

Read from the bottom up and it becomes a story: a laptop handed the message to its outgoing server at 10:00:00, which passed it to a relay thirty seconds later, which delivered it four and a half minutes after that.

Delays tell you more than totals

Do not look at the total transit time. Look for a single hop that took far longer than the others.

Most hops take a second or two. One hop taking several minutes while the rest are instant is almost always greylisting: the receiving server deliberately rejects the first delivery attempt, expecting a legitimate sender to retry a few minutes later. Spam software often does not retry, so it is an effective and very common filter.

That is not a fault, and there is nothing to fix. It is also completely invisible unless you read the timestamps — from the outside it looks like "email is slow today".

One caveat: those timestamps come from the servers themselves, and server clocks disagree. A hop that appears to take negative time is clock skew, not a delivery that arrived before it was sent.

SPF, DKIM and DMARC

These three decide whether a message is trusted, and they fail for different reasons.

Authentication-Results: mx.recipient.com;
  spf=pass smtp.mailfrom=sender.example;
  dkim=pass header.d=sender.example;
  dmarc=fail

SPF asks whether the server that sent this message is on the list of servers allowed to send for that domain. It breaks legitimately when mail is forwarded, because the forwarding server was never on the original list. An SPF failure alone often means nothing.

DKIM is a cryptographic signature over the message. It survives forwarding, but fails if the content changed in transit — which some mailing lists cause by appending a footer.

DMARC is the one that matters most. It ties SPF and DKIM to the domain a reader actually sees in the From line, and tells the receiver what to do when they disagree. The example above is the interesting case: SPF and DKIM both pass, and DMARC still fails, because they passed for a different domain than the one displayed. That is precisely the gap DMARC exists to close, and it is the strongest single explanation for a message landing in spam.

One thing to remember: these verdicts are the receiving server's findings, recorded at delivery. They are a report, not a live check — a header can say spf=pass for a domain whose policy has changed since.

Return-Path mismatches are not automatically suspicious

If Return-Path shows a different domain from From, that is worth noticing but is not evidence by itself.

It is entirely normal for mailing lists, newsletters and anything sent through a bulk provider — the bounce address belongs to the sending platform rather than the brand. It is also what unsophisticated spoofing looks like.

The authentication block separates them. A legitimate bulk sender passes DMARC despite the mismatch, because the domain owner authorised that platform. A spoof usually does not.

Where to find the headers

Gmail — open the message, three-dot menu, Show original. Outlook — File, Properties, copy the Internet headers box. Apple Mail — View, Message, All Headers. Thunderbird — Ctrl+U for Message Source.

One formatting detail matters if you are reading by hand: headers can fold across multiple lines. Any line beginning with a space or tab is a continuation of the one above, not a new header. A subject read naively therefore comes out truncated.

A note on pasting headers into websites

Headers are more sensitive than they look. They contain your address, the sender's, the subject line, and often internal hostnames and IP addresses from inside a company network — the sort of thing that maps a private network for anyone who collects enough of it.

Most established analysers post all of that to a server. That may be fine for a newsletter; it is a poor idea for a work message. Prefer a tool that parses locally, and verify it: open your browser's network tab and confirm that pasting produces no outbound request.

Analyse a message with the email header analyzer — it reverses the hop order, computes per-hop delays, and reads the authentication results, entirely in your browser. To check a domain's published SPF and DMARC records directly, use the DNS lookup; to identify a sending host, IP address and ISP lookup.