Reading Email Headers

In short. The name you see on a message is typed by whoever sent it and proves nothing. The headers underneath record how the message actually travelled, and five fields out of dozens tell you almost everything.

Why the sender name proves nothing

The visible sender is two separate things: a display name and an address. Both are supplied by the sender, and neither is verified by the act of sending.

Nothing prevents a message from claiming to be from any name and any address. The protocol was designed in an era when the network was small and trusted, and the checks that exist now were bolted on afterwards. They work, but they live in the headers, not in what your mail app displays in bold.

This is why "it came from their real address" is not evidence, and why people who know better still get caught: the forgery is convincing precisely where everyone looks.

How to see them

In this service, open the message and choose to view its source. On the page you see the message rendered safely, with scripts stripped and the body isolated; the source view shows the raw text underneath, headers first.

In ordinary mail clients the wording differs but the feature is always there: show original, view source, show all headers. What you get is a long block of Name: value lines, oldest at the bottom.

The length is intimidating and unimportant. Most of it is machine bookkeeping.

The five fields that matter

Return-Path. Where bounces go, and the address the receiving server checked against SPF. Frequently different from the visible sender, and that difference is often the first sign of something worth looking at.

Received. One line added by each server that handled the message, newest at the top. Together they are the route.

From. What you were shown. Compare it with the others rather than trusting it.

Authentication-Results. The receiving server's verdict on SPF, DKIM and DMARC, written in plain words: pass, fail, none.

Message-ID. A unique identifier, usually ending in the sending domain. Cheap to fake, but forgers often forget, and a Message-ID from an unrelated domain is a strong hint.

SPF, DKIM and DMARC without the jargon

SPF is a list, published by a domain, of the servers allowed to send its mail. The receiver checks whether the message arrived from one of them. It answers: was this sent from an authorised machine?

DKIM is a signature. The sending server signs the message with a private key, and the public key lives in the domain's DNS. It answers: was this message written by someone holding the domain's key, and is it unmodified?

DMARC is the policy that ties the two together and tells receivers what to do when they fail, plus a requirement that the checked domain matches the visible one.

In the headers this appears as something like spf=pass, dkim=pass, dmarc=pass, with the domain each result applies to. Three passes with the domain matching the visible sender is a good sign. Any fail on a message that claims to be from a large organisation is a bad one, because large organisations have these configured correctly.

Reading the chain from the bottom up

The lowest Received line is where the message entered the network, and each line above is one hop closer to you.

Read upward and ask whether the story is coherent. A message claiming to be from a bank should originate on infrastructure plausibly connected to that bank or its mail provider. If the bottom of the chain is a consumer connection in an unrelated country, or a bulk sending platform with no relationship to the brand, that mismatch is the finding.

Do not over-interpret. Legitimate mail passes through marketing platforms, gateways and filters, so unfamiliar names are not automatically suspicious. What matters is the earliest hop and whether authentication passed for the domain being claimed.

Three signs of forgery in ten seconds

Authentication failed for the claimed domain. dkim=fail or spf=fail on mail supposedly from a major company. Real mail from real companies passes.

Return-Path unrelated to From. The visible sender says one company, bounces go to an unconnected domain.

Reply-To pointing somewhere else. The message looks official and the reply goes to a free mailbox or a lookalike domain. This is the field to check on anything asking for money or a login.

All three turn up together in one place in particular: the mail that follows a classified listing, where fake couriers and fake payment notices are the standard script.

Why passing checks does not mean honest

This trips people up, so it deserves stating clearly: SPF and DKIM prove that a message really came from the domain it claims. They say nothing about whether that domain is trustworthy.

A fraudster who registers a lookalike domain and configures it correctly gets three passes on every message. The checks confirm authorship, not intent, and they cannot see that the domain has one character different from the real one. The details that make such a message convincing, your order number, your address, the name of a service you really use, usually come out of an old leak somebody bought, and no header tells you that either.

So authentication failing is strong evidence against a message, while authentication passing is only weak evidence for it. The remaining work is reading the domain carefully, character by character, on anything consequential.

If a message fails

Do not click the links, do not reply, and do not open attachments. If it asks for a password or a payment, treat that as settled regardless of how convincing the rest looks.

If you want to check whether a real service actually contacted you, go to that service the way you normally do, by typing the address yourself, and look for the same message there.

And if a forged message arrived at an address on one of our domains, tell us. Phishing aimed at our domains is our problem too: it generates the complaints that get domains listed, which shortens the life of every address on them.