How to read email headers to trace delivery problems

When an email arrives late, lands in spam, or you're trying to prove where a message actually came from, the answer is in the full headers, not the message body. Every mail server that touches a message adds a line to it. Read the headers top to bottom and you get an exact timeline of the delivery, plus the authentication checks that decided its fate.

The fastest read: find the Received lines and read them bottom to top (oldest at the bottom, newest at the top), then check the Authentication-Results line for SPF, DKIM, and DMARC verdicts. Big time gaps between consecutive Received lines point to the server or hop causing the delay.

Getting the full headers per client

"Full headers" or "original message" is a hidden view in most clients since normal reading doesn't need it.

• Roundcube (our default webmail): open the message, click the three-dot menu, choose Show source. This dumps the raw message including headers.
• Apple Mail: open the message, go to View → Message → All Headers (or All Headers in the message viewer menu).
• Outlook (desktop): open the message, File → Properties, headers are in the "Internet headers" box.
• Outlook (web): open the message, click the three-dot menu, View → View message details.
• Gmail: open the message, three-dot menu, Show original.
• Thunderbird: open the message, View → Headers → All, or Ctrl+U for the raw source.

If you're setting up a client for the first time, get the account working with the right IMAP and SMTP settings before you start debugging individual messages, half of what looks like a delivery problem is actually a misconfigured client.

Reading the Received chain

Each server that handles a message stamps a Received header on top of whatever's already there. That means the header block reads newest-first, but the delivery happened oldest-first. To trace the actual path, read from the bottom Received line up.

A typical line looks like:

Each line tells you three things: which server sent it (from), which server received it (by), and when. Walk the chain and you can answer:

• Where did this really originate? The bottom-most Received line, closest to the sender, is the most trustworthy origin point. Anything a sender puts in the visible "From" field can be spoofed; the Received chain is added by servers, not the sender, so it's much harder to fake.
• Where did it slow down? Subtract timestamps between consecutive hops. A message that jumps from 2:00pm to 2:01pm at every hop except one that takes 40 minutes tells you exactly which server queued it.
• Did it even leave the origin network promptly? If the gap between "message composed" (check the Date header) and the first Received line is large, the delay was on the sender's end, not ours.

Checking authentication results

Look for an Authentication-Results header, added by the receiving server after checking the sender's authenticity. It reports three checks:

• SPF (Sender Policy Framework): confirms the sending server is authorized to send mail for that domain. Result is pass, fail, softfail, or neutral.
• DKIM (DomainKeys Identified Mail): a cryptographic signature proving the message wasn't altered in transit and really came from the claimed domain. Result is pass or fail.
• DMARC: a policy layer that says what to do if SPF or DKIM fail (quarantine, reject, or do nothing). Result is pass or fail, and it only evaluates cleanly if the underlying SPF/DKIM checks align with the visible From domain.

For hosted domains, we auto-configure SPF and DKIM, so outbound mail from your domain should show pass on both at the receiving end. DMARC is not automatic and needs its own DNS record if you want it. A fail on an inbound message you received is often the strongest signal of a spoofed sender, don't trust the display name if SPF and DKIM both fail.

Diagnosing common delay patterns

Once you can read the chain, most delivery complaints fall into a few shapes:

1. Long gap right after origin, then normal hops. The sending server or its outbound queue was the bottleneck. Nothing on the receiving end to fix.
2. Fast until the last hop, then a big jump before final delivery. Check greylisting or spam filtering on the receiving side, greylisting deliberately delays first-time senders and asks the origin server to retry.
3. Message shows as delivered in the chain but isn't in the inbox. Check spam/junk folders and any client-side filters. The headers prove the server accepted it; where it landed after that is a filtering question, not a delivery one.
4. Multiple identical Received lines from the same server. Usually retry attempts, meaning the next hop was temporarily rejecting or timing out the connection.

If you're chasing recurring delays or suspect spoofed mail using your domain, checking your client's protocol choice matters too, see POP3 vs IMAP if sync issues are muddying whether a message actually arrived late or just synced late to a particular device.

When to contact support

If the headers show a message stuck for hours between two of our servers, or SPF/DKIM are failing on mail you legitimately sent from your own domain, that's worth a ticket. Open one from the portal under Support → New ticket and paste the full raw headers, real humans will trace it from our server logs against the timestamps you're seeing. Live chat works too for a quick sanity check before you file anything formal.