TL;DR
Email headers tell you the real path a message took to reach you. Checking the originating IP against the claimed sender domain is the fastest way to catch most phishing attempts.
Email headers are the metadata attached to every message you receive. Your email client hides them by default because they look like noise. But to anyone who knows what to look for, they are a complete audit trail: every server the message touched, the timestamps for each hop, and the IP address of the machine that first injected it into the internet.
Phishing emails often have a perfectly convincing display name and sender address. The headers tell a different story.
Where to Find Headers
In Gmail, open the message, click the three-dot menu at the top right, and choose "Show original." In Outlook, open the message, go to File, then Properties, and look in the "Internet headers" box. In Apple Mail, hold Option and click View, then Message, then All Headers.
What you get looks chaotic at first. It is a list of key-value pairs, reading from bottom to top in chronological order (the oldest lines are at the bottom, the newest at the top).
The Four Lines That Matter Most
Received: Every server that handled your email adds a Received line. The bottom-most Received line shows where the message originated. Look at the IP address in brackets. If the email claims to be from PayPal but that IP resolves to a server in a country PayPal does not operate from, that is your first red flag.
From: This is the display address. It is trivially easy to forge. An attacker can set it to anything. Do not trust it on its own.
Reply-To: This is where replies actually go. Phishers often set a legitimate-looking From address but put their real address in Reply-To. If these two do not match, ask yourself why.
Authentication-Results: Modern mail servers run three checks before delivering a message: SPF (does this IP have permission to send for this domain?), DKIM (is this message cryptographically signed by the domain?), and DMARC (what should happen if SPF or DKIM fail?). A legitimate email from a real company will show spf=pass, dkim=pass, and dmarc=pass. A phishing email often shows fail on one or more.
A Practical Example
Say you get an email that looks like it is from your bank. The From line shows [email protected]. You open the headers and find:
- The bottom Received line shows an IP address. You look it up and it belongs to a hosting provider in Eastern Europe.
- Authentication-Results shows
spf=fail. - The Reply-To address is
[email protected]-- a domain registered three days ago.
That is a phishing email. Your spam filter missed it because the display name was convincing. The headers caught it in thirty seconds.
What Legitimate Email Looks Like
A real email from a major service like Google, PayPal, or your bank will show:
- Received hops that trace back to the company's own infrastructure
spf=pass dkim=pass dmarc=passin Authentication-Results- From and Reply-To pointing to the same domain
- That domain matching what the company actually uses (paypal.com, not paypal-security.com)
Checking the Originating IP
Take the IP from the bottom Received line and run it through an IP reputation lookup. You want to know: what organization owns this IP? Is it on any blocklists? Is it in a location that makes sense for the claimed sender?
If the email claims to be from a US company and the originating IP is a residential connection in Romania, that tells you everything you need to know.
One Thing to Remember
Headers can be partially forged. An attacker who controls their own mail server can write Received lines that look legitimate. The one thing they cannot fake is the very first Received line added by your own mail server when it accepted the message. Your server writes that line based on who actually connected to it. That is the ground truth.
Reading email headers takes about two minutes once you know what to look for. Use the Email Header Analyzer on this site to parse them automatically and flag the issues described above.
Khodor Ghalayini
Engineer · AI Builder · Cybersecurity Practitioner
Engineer with 10+ years in systems and project management. I build AI-powered tools to help people work smarter — starting with the security and productivity problems I've personally run into. More about me →