How to Read Email Headers to Check Who Really Sent a Message
Every email carries a hidden section called the headers: a record of where it came from, which servers handled it and whether it passed the sender checks. The From line you normally see is easy to fake. The headers are much harder to fake convincingly, which makes them the best way to settle whether a suspicious message is genuine.
How to see the full headers
- Gmail (web): open the message, click the three dots next to Reply, and choose Show original. Gmail shows an SPF, DKIM and DMARC summary at the top, followed by the raw headers.
- Outlook.com and new Outlook: open the message, click the three dots, then View and View message source (or View message details).
- Apple Mail (Mac): select the message, then View, Message, All Headers.
- Thunderbird: View, Headers, All, or press Ctrl+U (Cmd+U on a Mac) to see the full source.
Mobile apps rarely show headers, so use a computer for this.
The headers that matter
The raw headers can run to dozens of lines. For checking a sender, only a few matter.
Authentication-Results
This line is added by your provider when the message arrives, so the sender cannot write it. It records the result of the SPF, DKIM and DMARC checks explained in our guide to how email works:
What to look for: dmarc=pass with a header.from domain that is really the company's domain. That combination means the message genuinely came from servers the domain owner authorised. A result of fail, or a pass for some unrelated domain, is a strong warning sign.
From, Reply-To and Return-Path
- From is what your app shows. Look at the address inside the angle brackets, not the display name.
- Reply-To, if present, is where your reply will go. A message "from" your bank with a Reply-To at a free webmail address is almost certainly a scam.
- Return-Path is the envelope sender, where bounces go. It often differs legitimately (newsletter platforms use their own), but it should still make sense.
Received
Each server that handles a message adds a Received line at the top. Reading them from the bottom up shows the route from origin to your inbox:
The line added by your own provider (the top one) is the trustworthy one: it records the real address of the server that connected. Lines lower down were written by servers you cannot verify, and a forger can invent them. Check that the connecting server's name belongs to the organisation the email claims to be from.
Message-ID and Date
A Message-ID from a domain unrelated to the sender, or a Date wildly different from when the message arrived, are small clues that something is off. On their own they are not proof.
Two quick examples
Genuine
The visible From domain matches the domain that passed DMARC. This came from the bank's authorised systems.
Forged
The From line claims the bank, but SPF and DMARC both fail, there is no DKIM signature, and replies would go to a free webmail account. If this reached your inbox at all, report it as phishing.
Limits of header checking
- A pass only proves the domain, not the intent. A scammer who registers
example-bank-alerts.comcan set up perfect SPF, DKIM and DMARC for that lookalike domain. Always check that the domain itself is the real one. - Compromised accounts pass everything. If a real colleague's mailbox is hacked, messages from it authenticate perfectly. Unusual requests still deserve a phone call.
- Forwarding can break SPF. A legitimate message forwarded through another service may fail SPF; DKIM usually survives, and DMARC passes if DKIM does.
For the everyday warning signs that do not need headers at all, see How to Spot a Phishing Email.