Every email you receive carries a piece of metadata that most people never look at. It sits behind a button labeled “Show original” or “View source,” and it tells you, in remarkable detail, the route the message took to reach you and who actually sent it. Learning to read this metadata, called the email headers, is one of the cheapest skills in personal cybersecurity. It takes about five minutes to learn and pays off the next time something feels slightly off about a message.
What Email Headers Actually Are
An email is more than the part you see. Every message has a body, which is the words and pictures, and a long list of headers, which is the routing and authentication information. The headers describe the sender, the receiver, the path the message took between mail servers, and whether each server along the way considered the message legitimate.
The visible “From” line in your email client is just a label. It is set by whoever sent the message and can say anything they want. The real information about origin lives in the headers, and unlike the visible “From” line, it is much harder to fake convincingly.
How to See the Headers in Common Clients
The exact menu varies, but the idea is the same everywhere.
- Gmail: open the message, click the three-dot menu in the top right, choose “Show original.”
- Outlook on the web: open the message, click the three-dot menu, choose “View” then “View message source.”
- Apple Mail: open the message, then in the menu bar choose View, Message, All Headers.
- Thunderbird: open the message, then View, Headers, All.
You will see a wall of text. Do not panic. You only need to know what to look for.
The Three Authentication Lines You Care About
Modern email has three checks that mail servers run on incoming messages: SPF, DKIM, and DMARC. Each one tries to answer a slightly different question about whether a sender is who they claim to be.
SPF
The Sender Policy Framework checks whether the server that sent the message is allowed to send mail for the domain in the From line. The domain owner publishes a list of approved servers, and the receiving mail server compares the actual sending server against that list.
Look for a line like Received-SPF: pass or spf=pass. If it says fail, the message is claiming to be from a domain that did not authorize the sending server. That is a strong signal of spoofing.
DKIM
DomainKeys Identified Mail attaches a cryptographic signature to outgoing messages. The signature is created with the sender’s private key and verified by the receiving server using a public key published in the sender’s DNS records. If the signature is valid, you know the message has not been altered in transit and that it really was sent by the claimed domain.
Look for dkim=pass in the Authentication-Results header. A fail or missing DKIM on a message that claims to be from a major company is suspicious. Companies like banks, large retailers, and most cloud services sign all of their outgoing email.
DMARC
DMARC ties SPF and DKIM together and tells the receiving server what to do if both fail. It is the policy layer on top of the other two checks. A line like dmarc=pass is what you want to see for messages from any organisation that takes email seriously.
If a message claims to be from a major brand and the Authentication-Results header shows spf=fail dkim=fail dmarc=fail, the message is almost certainly forged. No legitimate large sender ships email that fails all three.
The Received Chain
Headers also contain a stack of Received: lines, each one describing one hop the message took. The lines read from bottom to top in chronological order. The bottom line is the first server that handled the message, usually the one belonging to the sender. The top line is the server that handed the message to you.
You do not need to memorise the format. You only need to glance at the bottom-most Received line and ask whether the originating server makes sense. A message claiming to come from a household-name bank but originating from a residential IP address in an unrelated country is a quick red flag.
The Reply-To Trick
Phishing emails often set the visible From line to a real-looking name while quietly using a different Reply-To address. If you hit reply, your response goes to the attacker rather than the supposed sender. The headers will show this immediately.
Compare the From: header and the Reply-To: header. If they are wildly different domains, treat the message as hostile by default. A message from support@yourbank.com with a reply-to of some-random-account@gmail.com is not from your bank.
A Quick Worked Example
Imagine you get an email that looks like it is from a major payment provider asking you to confirm a charge. The visible From line says the right brand. The link goes to a domain that is not quite right. You open the headers and see something like this:
From: "PayPal Support" <support@paypa1-secure.com> Reply-To: refund-team@mailbox-help.net Authentication-Results: mx.example.com; spf=fail (sender IP is not authorized); dkim=none; dmarc=fail Received: from unknown.host (192.0.2.45) by mx.example.com
Even without security training, the picture is clear. The sender domain replaces the lowercase “l” with a digit. The reply-to is on an unrelated domain. SPF failed, DKIM is not even attempted, and DMARC failed. The originating IP address is a residential block. Delete and move on.
What Real Companies Look Like
For comparison, a real notification from a major service usually has Authentication-Results with three clean passes, a From and Reply-To that match the company’s domain, and a sending server that belongs to either the company itself or a well-known transactional email provider. None of this is hidden. Open the headers on any email you trust and get used to what “normal” looks like for the senders you deal with regularly.
Why This Skill Pays Off
Spam filters catch most spoofed mail before you ever see it, but the most dangerous phishing attempts are precisely the ones designed to slip past filters. Those are the messages you have to evaluate by hand, and a 30-second glance at the headers is often enough to settle the question.
You do not need to read every header on every message. The point is to know how, so that on the rare day when something feels off, you can look. The few times in your life when this skill saves you from clicking a perfect-looking link will more than pay for the few minutes you spent learning it.
One Last Habit
Combine header literacy with the simpler habits that prevent phishing from reaching you in the first place. Use a temporary email for low-trust sign-ups so that fewer marketing lists contain your real address. Use a password manager so that even a successful phish does not autofill on a fake domain. Turn on two-factor authentication on the accounts that matter. The headers are the last line of defense for the few suspicious messages that get through. The fewer of those there are, the easier the job.