tmailrGuides
How to read email headers without guessing
26 July 2026 · 3 min read · TMailr
Headers are where email stops being mysterious. Everything about how a message reached you, who vouched for it and where it lost twenty minutes is written down at the top of the file, and almost nobody reads it because it looks like noise. It is not noise, and there are only four things worth finding.
Received lines read from the bottom
Every server that touches a message adds its own Received line at the top, so the oldest is at the bottom and the newest at the top. Read upward and you are following the message forwards in time from the sender to you.
Received: from mx.example.com (mx.example.com [203.0.113.9])
by mx.google.com with ESMTPS id abc123
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384);
Fri, 31 Jul 2026 12:00:05 -0700 (PDT)Each line says who connected, who they connected to, over what, and when. Subtract consecutive timestamps and you have found the slow hop, which is nearly always the answer to why did this take twenty minutes. It is almost never the sender and almost never you.
The version=TLS1_3 part is worth noticing too. A hop with no TLS mentioned carried your message in the clear.
Authentication-Results is the verdict
The receiving server writes down what it concluded about SPF, DKIM and DMARC. This is the only authoritative statement in the file, and it is the one to read first.
Authentication-Results: mx.google.com; dkim=pass header.i=@example.com; spf=pass smtp.mailfrom=bounces@bounce.example.com; dmarc=pass (p=REJECT) header.from=example.com
One caution that matters: trust only the header added by the server you actually collect mail from, which is the topmost one. Anything below it was added by a machine upstream, and anything a sender puts in the message themselves is just text they typed. A message can arrive carrying a beautifully forged Authentication-Results header claiming everything passed.
There are two From addresses and they are checked differently
The envelope sender, visible as Return-Path, is where bounces go and what SPF is checked against. The From: header is what your mail client shows you. They are routinely different and that is normal: a shop sends with its own bounce address so it hears about failures.
What decides whether the difference matters is alignment. DMARC asks whether the domain that passed belongs to the same organisation as the domain in From:. Relaxed alignment, the default, is happy with a subdomain, so bounce.example.com and example.com align. Two entirely different companies do not.
The display name is not a domain
One of the more effective impersonations needs no infrastructure at all:
From: "billing@paypal.com" <attacker@evil.test>
Everything authenticates, because evil.test really did send it and really does have DKIM set up. The display name is free text and many clients show only that. If the part before the angle brackets looks like an address from a different domain than the part inside them, that is deliberate.
A four-step read
- Authentication-Results at the top: what did spf, dkim and dmarc actually say?
- Does the domain that passed match the domain in From:, allowing for subdomains?
- Does the display name contain an address, and is it a different domain from the real one?
- Walk the Received lines bottom to top and find the gap.
That is enough to answer most of the questions people ask about a message: is it really from them, why was it slow, and why did it end up in spam. Paste a header block into any analyser, including ours, and it is doing these four things and formatting the result.
More on guides
