How to Read an Email Header (and Spot a Phishing Email)

The part of an email you usually never see is the part that tells you the truth. Here is how to read the headers, follow the path a message actually took, and check the signals that separate a real sender from an impostor.

What email headers are, and why the body can lie

Every email has two parts. The body is what you read: the greeting, the message, the signature. The headers are a block of technical metadata that travels with the message but stays hidden unless you go looking for it. They record who the message claims to be from, the servers it passed through, timestamps, and the results of automated security checks.

The body and the friendly "From" name are trivial to fake. Anyone can type "PayPal Support" as a display name and write a convincing message. What is harder to fake is the trail left behind as the message moves across the internet, because much of that trail is written by mail servers rather than by the sender. That does not make headers tamperproof, but it does mean they often disagree with a lie told in the body, and that disagreement is what you are looking for.

Most mail apps hide the headers behind a menu like "Show original", "View source", or "Show raw message". Once you have that raw text, the rest of this guide is about reading it.

The Received: chain: the path the message took

The most useful headers are the Received: lines. Each mail server that handles a message adds its own Received: line at the top of the header block as it passes the message along. Because each new server stamps its line on top, the list ends up in reverse order.

So you read the Received: chain from the bottom up. The bottom line is the oldest, written by the first server to touch the message, which is usually closest to where it actually originated. The top line is the newest, written by the server that finally delivered it to you. Walking up from the bottom lets you trace the route and ask where the message truly started.

A typical line names the server that received the message, the server that sent it, and an IP address, often in a form like Received: from mail.example.com (203.0.113.10) by mx.yourprovider.com. The originating IP near the bottom of the chain is worth a closer look: if a message claiming to be from a major bank first appears at a random residential or overseas IP that has nothing to do with that bank, that mismatch is a signal worth investigating. The structure of these trace fields is described in the internet mail standard, RFC 5322.

One honest caveat up front: only the Received: lines added by servers you trust are reliable. A sender can pre-write fake Received: lines into the bottom of the chain, so the lower you go, the more skeptical you should be. The lines added by your own provider near the top are the ones you can actually trust, and they are where the security checks below get recorded.

SPF, DKIM, and DMARC: the authentication results

Modern mail systems run three checks on incoming mail and record the outcome in an Authentication-Results: header. You do not have to run these yourself; you just read the verdict your provider already wrote down.

• SPF (Sender Policy Framework) asks whether the server that sent the message is on the list of servers the domain authorized to send for it. It is checked against the sending domain's published policy and is defined in RFC 7208.
• DKIM (DomainKeys Identified Mail) checks a cryptographic signature attached to the message. A valid signature means the domain that signed it really did, and that key parts of the message were not altered in transit. It is defined in RFC 6376.
• DMARC (Domain-based Message Authentication, Reporting and Conformance) ties the other two to the visible "From" domain and tells receivers what to do when things do not line up. It is defined in RFC 7489.

Each check resolves to a short result, and the words matter:

• pass: the check succeeded. For SPF the sending server was authorized; for DKIM the signature was valid; for DMARC the message lined up with the "From" domain's policy. A pass is reassuring but not a guarantee of good intent, since a scammer can pass these checks on a lookalike domain they actually control.
• fail: the check ran and the message did not pass. This is worth a closer look, though as the caveats below explain, legitimate mail sometimes fails for innocent reasons.
• none: the check could not run because the domain published no policy or no signature. This is common on neglected domains and means the result simply tells you nothing either way.

The combination that should raise an eyebrow is a message that claims to be from a well-known brand yet shows SPF and DKIM failing while DMARC fails too. Big organizations almost always publish strict policies, so a failure on a message wearing their name is a genuine flag.

The classic spoofing tells

You do not need every header to spot the common tricks. A few specific mismatches catch most everyday phishing:

• Display name versus real domain. The friendly name says "Microsoft Account Team" but the actual address in the From: header is something unrelated like [email protected]. The display name is decoration; the domain after the @ is what counts.
• A mismatched Reply-To:. The message looks like it is from a company, but replies are quietly addressed to a different, unrelated mailbox. This is a favorite trick for steering your response to an attacker while the original looks legitimate.
• A mismatched Return-Path:. This is the behind-the-scenes "bounce" address, and on real mail it usually relates to the sending domain. When it points somewhere with no connection to the brand in the From: line, that gap is worth a closer look.
• A suspicious originating IP. As above, an oldest Received: line that places the message's origin somewhere that does not fit the supposed sender is a meaningful signal, especially alongside an authentication failure.

Any one of these on its own can have an innocent explanation. The pattern to trust is several of them pointing the same way at once: a brand name, an unrelated domain, a redirected reply, and a failing check together tell a more convincing story than any single line.

The honest caveats

Headers are evidence, not a verdict, and it is worth knowing where they get noisy.

Forwarding and mailing lists legitimately break authentication. When a message is forwarded, or sent through a mailing list that rewrites parts of it, SPF can fail because the relaying server was never on the original domain's authorized list, and DKIM can break because the content changed in transit. These are real, everyday situations where a fail does not mean anything sinister. A failure on forwarded or list mail is expected, not alarming.

The results were written by servers you do not control. An Authentication-Results: line stamped deep in the chain was added by some server upstream, and you have no way to confirm it is honest. The line you can actually trust is the one added by your own mail provider as it delivered the message to you, because that is the boundary you control. Treat the topmost authentication result from your provider as the trustworthy one and be cautious about results carried in from further away.

In short, headers are great at confirming a mismatch and poor at proving good intent. Use them to find reasons for suspicion, then combine that with the wider context of who is contacting you and what they are asking for.

This guide is educational and reflects publicly available information about email headers and the published email-authentication standards (SPF, DKIM, and DMARC). It is not legal advice or a recommendation about any specific email, sender, person, or decision. Verification and security decisions should follow your organization's policies and applicable law.