How to Read an Email’s Headers to Find Where a Phishing Message Really Came From
You have a message in front of you that claims to be from your bank, a grant officer, or a supplier asking you to re-confirm payment details before a deadline. The display name looks right. The logo looks right. What you need is not a feeling about the message but a check you can run and show to someone else.
The header section is that check — with a hard limit you should understand before you rely on it. Headers can tell you which mail servers handled a message, in what order, and what authentication checks the receiving system ran. They cannot tell you who the human being on the other end is, and they cannot prove a message is safe. What they can do is contradict the story the message is telling. A contradiction is enough to act on.
Start with what the visible message actually is
An email is not a single object with a sender attached. Under the Internet Message Format, a message consists of header fields — collectively the header section — followed optionally by a body, separated by an empty line (RFC 5322, Section 2.1). Each header field is a line beginning with a field name, a colon, a field body, and a line ending (RFC 5322, Section 2.2).
The From: line you see in your mail client is one header field among many. It is text in the message. Nothing in the format prevents a sender from putting any display name and any address there. That is why “the From address looked legitimate” is not evidence of anything — it is the claim under examination, not the proof.
What you want instead are the fields written by systems that handled the message after it left the sender’s control: the Received chain and the Authentication-Results field. Those are where the traceable material lives.
Reveal the full header section
Every mainstream mail client can show you the raw message, but the menu path differs by client and changes between versions. Rather than give you a path that may not match your screen, look for one of these labels in the message’s overflow menu (often three dots or a downward chevron): Show original, View source, Show source, Message source, or View headers. In desktop clients it is frequently under a menu named File, View, or More.
Two practical notes. First, do this on a message you have already decided not to interact with — do not click links or open attachments to “investigate.” Second, copy the header block into a plain text file before you start reading. You will want to compare lines side by side, and mail clients wrap long lines in ways that make comparison hard.
The Received chain: read it bottom-up
Each mail transfer agent that accepts a message adds a Received line, and it adds that line at the top of the header block. The result is a stack in reverse chronological order: the newest hop is at the top, the oldest at the bottom. To follow the message’s actual journey, read from the bottom upward.
A Received line conventionally carries these elements, separated from a timestamp by a semicolon:
- from — the source the receiving server saw, typically a hostname, sometimes a reverse-DNS name in parentheses, and the connecting IP address in square brackets.
- by — the hostname of the server that accepted the message and wrote this line.
- with — the protocol used for that hop. Values ending in
S (such as ESMTPS) indicate TLS was negotiated; values without it (such as ESMTP) indicate it was not.
- id — a queue identifier local to that server. It changes at every hop and is useful only for correlating that server’s logs.
- for — the envelope recipient for that hop, which may differ from the
To: line.
- timestamp — when that server accepted the message.
The key structural property is continuity: each hop’s from should correspond to the previous hop’s by. When you climb the chain and the handoffs line up, the routing is internally consistent. When they do not line up, something was inserted, stripped, or forwarded — and that is worth a second look.
What the chain can and cannot establish
Here is the part most guides skip. A Received line is written by the receiving server, not the sender, so the IP address it records is the address that server actually observed. That is the useful property. But a sender can add fabricated Received lines at the bottom of the chain to make a message appear to have originated somewhere it did not. What a sender cannot do is forge lines added by infrastructure you already trust — your own mail provider’s inbound servers, for example.
So the practical rule is: trust the top of the chain, treat the bottom with suspicion. The lines closest to you were written by systems you have some reason to rely on. The lines closest to the claimed sender are the ones an attacker had the most opportunity to shape.
This is why the honest answer to “where did this really come from” is usually narrower than the question implies. You can often establish which servers handled the message and whether the routing is consistent. You can rarely establish the identity of the person who sent it. For a decision about whether to click, pay, or reply, the narrower answer is the one that matters.
Authentication-Results: a receiver’s opinion, not a verdict
The Authentication-Results header field reports the outcome of message authentication checks in a machine-readable format (RFC 8601). It is written by a receiving system, and it summarizes what that system’s checks found.
Read it carefully, because the standard is explicit about its status: the mere presence of the field does not mean its contents are valid. It reports assertions made by authentication schemes applied somewhere upstream (RFC 8601, Section 1.1). In other words, it is a claim by a mail system, not a property of the message. If the field was added by a system you trust, it is useful evidence. If it appears in a message that arrived through an unfamiliar path, treat it as text like any other.
To interpret the results, you need to know what each check actually tests:
- SPF lets a domain owner publish which hosts are authorized to send mail using that domain, and lets a receiving host check that authorization (RFC 7208). It is evaluated against the envelope sender and HELO identity — not the visible
From: line.
- DKIM attaches a cryptographic signature associating a signing domain with the message, validated by querying that domain for a public key (RFC 6376). It asserts that signed content has not changed since signing — and, per the same document, asserts nothing else about protecting the message end to end.
- DMARC uses the domain in the
From: field as its primary identifier and combines it with SPF and DKIM results to evaluate alignment (RFC 7489).
Now the limits, stated plainly. DMARC does not address visually similar “cousin domains” or abuse of the human-readable display name (RFC 7489, Section 2.4). A DMARC pass means the From domain was authenticated for that message. It does not mean the message is safe, that the organization endorses its contents, or that the person who sent it is who they claim to be. A compromised legitimate account can produce a message that passes every check.
A worked example, clearly labeled as illustrative
The following is a fabricated header block, constructed to show a specific pattern. It is not a real message and does not describe any real organization.
Received: from mail.example-relay.net (mail.example-relay.net [198.51.100.24])
by mx.recipient.example with ESMTPS id 4Xy2ab
for <you@recipient.example>; Mon, 03 Mar 2025 09:14:02 +0000
Received: from portal.partner-billing.example (unknown [203.0.113.77])
by mail.example-relay.net with ESMTP id 7Qp9zz
for <you@recipient.example>; Mon, 03 Mar 2025 09:13:58 +0000
Received: from localhost (localhost [127.0.0.1])
by portal.partner-billing.example with ESMTP id 1Aa0bb
for <you@recipient.example>; Mon, 03 Mar 2025 09:13:55 +0000
Authentication-Results: mx.recipient.example;
spf=pass smtp.mailfrom=partner-billing.example;
dkim=pass header.d=partner-billing.example;
dmarc=pass header.from=partner-billing.example
Read bottom-up. The oldest line shows a submission from localhost to portal.partner-billing.example. The next line shows that server handing off to mail.example-relay.net, and here the from field reads unknown with an IP in square brackets — the reverse-DNS lookup did not produce a name. The top line shows the relay delivering to the recipient’s mail server over TLS.
What does this tell you? The routing is continuous: each by becomes the next from. The authentication results show passes for SPF, DKIM, and DMARC aligned to partner-billing.example. On its face, the message is consistent with a legitimate send from that domain.
What it does not tell you is whether partner-billing.example is a domain you should be doing business with, whether the account that sent it was compromised, or whether the content of the message is honest. The unknown reverse-DNS entry is a mild flag worth noting but not proof of anything — plenty of legitimate servers lack proper PTR records. This is the discipline the exercise teaches: separate what the evidence shows from what you are tempted to conclude.
A checklist you can run today
For a suspicious message, in this order:
- Do not interact. No links, no attachments, no reply, no phone number from the message.
- Reveal the full header section and copy it to a plain text file.
- Read the
Received chain bottom-up. Check that each hop’s from matches the previous hop’s by. Note any break in continuity.
- Compare timestamps. Large gaps between adjacent hops suggest queuing or deferral, not necessarily malice. Out-of-order timestamps suggest clock problems on a server.
- Check the
with values. A hop without TLS in an otherwise encrypted chain is a downgrade worth noting.
- Read
Authentication-Results and identify which system wrote it. A pass from your own provider’s inbound server is meaningful; a pass field in a message that arrived through an unusual path is not.
- Verify out of band. Use a contact method you already have — a stored phone number, a known address — not anything supplied in the message. CISA’s guidance is explicit on this point: verify through a known channel rather than replying or using a link or number from the message, and report and delete suspected phishing (CISA, Teach Employees to Avoid Phishing).
Steps 1 through 6 take a few minutes and produce a record you can hand to an IT provider, a colleague, or a reporting channel. Step 7 is the one that actually protects you, and it is the one people skip.
Why this matters more than it used to
Phishing is not a niche problem. CISA cites the FBI’s 2024 Internet Crime Report placing phishing at the top of the five most reported cybercrimes, with 193,407 complaints (CISA). For a small organization without a security team, the header section is one of the few investigative tools available that requires no software installation and no vendor relationship.
It is also a tool that produces evidence rather than impressions. If you are a journalist assessing a source, a small-business owner facing a payment-redirect request, or a staff member who has been asked to “just approve” something before a deadline, the difference between “this felt wrong” and “the routing contradicts the claimed sender” is the difference between a suspicion and a finding.
What this procedure does not cover
Being clear about the boundaries is part of using the method honestly.
It does not identify the human sender. Headers describe servers and authentication results, not people.
It does not prove a message is safe. A message can pass SPF, DKIM, and DMARC and still be a phishing attempt from a compromised account, or carry a malicious attachment from a legitimate domain.
It does not detect cousin domains or display-name tricks. DMARC explicitly does not address these (RFC 7489), so a message from examp1e-bank.example with a display name reading “Example Bank” can pass every check while being fraudulent.
It does not replace reporting. Header analysis tells you what you are looking at; reporting tells the people who can act on it. CISA’s guidance is to report and delete suspected phishing, and to change account passwords immediately if you suspect compromise.
And it does not replace training. A single person reading headers is a useful backstop; a team that knows to verify out of band before acting on an unexpected request is a control.
Questions readers actually ask
Can I trust the top Received line?
More than the bottom, yes — provided the system that wrote it is one you have reason to rely on. The top line was added by the server that delivered the message to your mailbox, which is typically infrastructure your provider controls. The bottom lines are the ones a sender had the most opportunity to fabricate.
Does a DMARC pass mean the email is legitimate?
No. It means the domain in the From field was authenticated for that message. It says nothing about whether the content is honest, whether the organization endorses it, or whether the account that sent it was compromised.
Why does the from field say unknown?
That usually means the receiving server could not resolve a reverse-DNS name for the connecting IP address. It is common on legitimate mail from small or misconfigured servers and is not by itself evidence of fraud. It is a detail to note alongside other signals, not a verdict.
What if the Received chain has a break in continuity?
A break means a hop is missing, a forwarder inserted itself, or a line was added or removed. Any of those is a reason to slow down and verify the request through a channel you already trust. It is not proof of malicious intent — forwarding and mailing lists routinely alter chains.
Should I forward the message to my IT provider?
If your organization has a reporting process, follow it. Forwarding as an attachment preserves the header section; forwarding inline often does not. If you are unsure, copy the header block into a separate text file and send that alongside a description of what you received.
The step to take today
Pick one message in your inbox that you have already decided not to act on — a newsletter, a notification, anything harmless — and practice the procedure on it. Reveal the header section, find the Received lines, and read them bottom-up. Find the Authentication-Results field and identify which system wrote it. You will learn more from five minutes on a message you do not care about than from an hour of reading on a day when a real one arrives.
The point of the exercise is not to become a mail administrator. It is to build the habit of asking what the evidence shows before the deadline pressure makes the question feel optional.