Someone Sent a Threatening Email. What the Extended Headers Can (and Can't) Tell You
When a threatening or harassing message arrives, the useful technical step is to preserve the original and read the extended headers — Received hops, authentication, originating servers — before anyone forwards it. This is that step, including its limits.
First, stop, and save the file you actually received
A common exam-style prompt in security training is: a member of the public receives threats by email; you wish to examine the extended header; what is the correct course of action? The answer that training is aiming at is not "reply" and not "forward to a colleague so they can take a look." It is: preserve the original message, then inspect the headers on that original.
Extended headers are the hidden block: every Received line added by a server that handled the mail, Authentication-Results, Message-ID, Return-Path, and related fields. They are the closest thing most people can get to a delivery log without asking the provider for server records.
If the message is a credible threat to someone's safety, contact the police (in the UK, 999 if it is happening now, otherwise 101 or online reporting) and do not wait on a header tool. Technical analysis supports a report. It does not replace one.
A concrete example
What "examine the extended headers" means in practice
Use this on mail still in the account that received it, saved as a file, not as a screenshot of the body.
The situation
An inbox has a message that threatens or intimidates the recipient. You need a technical note of how it arrived — hops, claimed sender, whether authentication passed — to attach to an internal incident record or a police report.
Source and destination you choose
Where it comes from
Original .eml or .msg from the receiving account
Show original / view source / save as in the client that still holds the message
Why this one: Forwarding creates a new message about your server, not theirs.
Also works with
- Copy-paste of the full raw header block if you cannot save a file
- Provider "download original" if the webmail offers it
Where the result goes
Forensics report you can attach to the incident
Routing hops, authentication results, extracted contacts and a readable summary
Why this one: A raw header dump is easy for a non-specialist to mis-order. A structured report is easier to exhibit.
Or choose
- CSV if you are logging several related messages
- On-screen review before you store a copy
A defensible order of work
-
1
Do not reply, and do not bait the sender
Engagement can escalate the behaviour and muddies the record. Save first.
-
2
Save the original from the receiving mailbox
In Outlook, File → Save As → Outlook Message Format. In Gmail, three dots → Show original → Download original. That file is the exhibit.
-
3
Run a header analysis on that file
Email Forensics at https://emailtools.hexamail.com/forensics parses Received lines (oldest hop typically at the bottom), SPF/DKIM/DMARC, and the path between servers.
-
4
Write down what the headers support — and stop there
You can usually say how the message was handed to your provider and whether the sending domain's authentication passed. You can rarely name a person from a consumer IP or a webmail account alone.
Webmail (Gmail, Outlook.com, many workplace systems) often means the "originating IP" you hoped for is a Google or Microsoft server, not the sender's home connection. That is a real limit, not a failure of the tool. Providers may hold more in their own logs; those are obtained through lawful process, not from the message file.
What headers cannot do
They cannot reliably geolocate a person from a phone on mobile data or from a VPN. They cannot prove identity when the From: line is a free webmail address the attacker registered for the occasion. They cannot undo a message already read. And if the sender used a compromised legitimate mailbox, authentication will often pass, because the mail really did come from that account.
Treat the forensics report as: delivery path, domain authentication, inconsistencies worth flagging. Treat identity and intent as matters for the people who investigate crimes, not for a header parser.
Questions after the message is saved
Should I print it for the police?
A printout of the body can help a statement. The original .eml/.msg is the better technical exhibit. Offer both if you are asked for evidence.
The From address looks real. Does that mean it is them?
No. Display names and From: addresses are trivial to spoof unless SPF/DKIM/DMARC (and how your provider treated the result) say otherwise — and even a pass can be a hijacked account.
Can this unmask a sender who used a throwaway Gmail?
Almost never from the message file alone. You will see Google's servers. Further identification, if it happens at all, goes through the provider with a lawful request.
Related guides
Email anatomy, headers and authentication
The wider map of what a forensic pass looks at.
Fraudulent payment instructions in an email
A different reason to read the same headers before you act.
If there is a whole thread, not one message
Order the correspondence first, then analyse the originals that matter.
Preserve the original. Then read the path it took.