Email Security
Email Investigation
How to view email headers, what to look for, and how to preserve emails as evidence
For education only. We do not guarantee that this guide is accurate, complete, or up to date. Research the topic yourself and check current, reliable sources before acting.
In this guide
Email investigation is the practice of reading a message's hidden metadata to determine where it actually came from, who handled it in transit, and whether the visible sender can be trusted. Headers record the journey in a form that is much harder to fake than the body, and the entry your own mail server adds is the anchor every investigation builds outward from. This article covers how to view headers across the major email clients, how to read them, what to look for, and how to preserve email evidence so it survives later review.
The $43,000 Reply
The attorney had almost wired the money. Email from his client asking to send closing costs to a new account. Client's exact address. Signature matched. Timing made sense.
But he'd called to confirm. The client hadn't sent anything.
Priya pulled the original email and opened the headers. The From address showed the client's email. But the Received chain told a different story: first hop was a server in Eastern Europe, not the client's corporate mail system.
She checked the Reply-To field. Different domain. One letter swapped. If the attorney had replied instead of calling, his response would have gone straight to the attacker.
The message body was perfect. Same formatting the client always used. Same signature block. Nothing to flag.
The headers caught what the body couldn't reveal.
Fifteen minutes of header analysis. $43,000 that didn't walk out the door.
This story is fictional, but the patterns are real.
Why do headers matter?
You've learned that email can be faked and that authentication helps but doesn't guarantee safety. Now comes the practical skill: examining an email to determine where it actually came from. Phishing and spoofing was the single highest-volume crime type reported to the FBI in 2024, with 193,407 complaints, and most fraud investigations either start with an email or eventually need to read one.[1]
Every email carries hidden metadata recording its journey. This metadata, stored in headers, is your primary evidence when investigating suspicious messages. The visible content can lie. The headers are much harder to fake completely.
How do you view email headers?
Before you can analyze headers, you need to access them. Every email client hides them by default.
Gmail:
- Open the email
- Click the three dots (top right)
- Select "Show original"
- A new tab opens with full headers and message source
Outlook (Desktop):
- Open the email
- File → Properties
- Headers appear in the "Internet headers" box at the bottom
Outlook (Web and new Outlook):
- Open the email
- Click the three dots (More actions)
- Select View, then "View message source" (labeled "View message details" in some versions)
Apple Mail:
- Open the email
- View → Message → All Headers
Yahoo Mail:
- Open the email
- Click the three dots
- View raw message
Reading a Header: Real Example
Here's what headers actually look like. This is a legitimate email from a company called Acme Corp:
Return-Path: <[email protected]>
Received: from mail.recipient.com (mail.recipient.com [192.168.1.50])
by mx.recipient.com with ESMTP id abc123
for <[email protected]>; Tue, 15 Oct 2024 09:23:45 -0400
Received: from mail.acme-corp.com (mail.acme-corp.com [203.0.113.25])
by mail.recipient.com with ESMTP id def456
for <[email protected]>; Tue, 15 Oct 2024 09:23:42 -0400
Received: from internal.acme-corp.com (internal.acme-corp.com [10.0.0.15])
by mail.acme-corp.com with ESMTP id ghi789
for <[email protected]>; Tue, 15 Oct 2024 09:23:40 -0400
From: Acme Corp Invoicing <[email protected]>
Reply-To: [email protected]
To: [email protected]
Subject: Invoice #4521
Date: Tue, 15 Oct 2024 09:23:38 -0400
Authentication-Results: mx.recipient.com;
spf=pass smtp.mailfrom=acme-corp.com;
dkim=pass header.d=acme-corp.com;
dmarc=pass header.from=acme-corp.com
How to read it:
Received headers are added by every server that handles a message and stack in reverse order, with each new server prepending its line to the top.[2] Read them bottom to top to trace the journey:
- Bottom Received (09:23:40): Email created on Acme's internal server
- Middle Received (09:23:42): Handed to Acme's outbound mail server
- Top Received (09:23:45): Arrived at your mail server
The servers match the claimed domain (acme-corp.com). Authentication passed for acme-corp.com. Return-Path, From, and Reply-To all align.
This email is legitimate.
How do you spot a forged email?
Now compare this fraudulent email pretending to be from the same company:
Return-Path: <[email protected]>
Received: from mail.recipient.com (mail.recipient.com [192.168.1.50])
by mx.recipient.com with ESMTP id xyz999
for <[email protected]>; Tue, 15 Oct 2024 14:05:22 -0400
Received: from smtp-relay-247.net (unknown [45.142.XX.XX])
by mail.recipient.com with ESMTP id rst888
for <[email protected]>; Tue, 15 Oct 2024 14:05:19 -0400
Received: from localhost (localhost [127.0.0.1])
by smtp-relay-247.net with ESMTP id qqq111
for <[email protected]>; Tue, 15 Oct 2024 11:05:15 -0400
From: Acme Corp Invoicing <[email protected]>
Reply-To: [email protected]
To: [email protected]
Subject: URGENT: Updated Invoice #4521
Date: Tue, 15 Oct 2024 14:05:10 -0400
Authentication-Results: mx.recipient.com;
spf=fail smtp.mailfrom=smtp-relay-247.net;
dkim=none;
dmarc=fail header.from=acme-corp.com
Red flags:
| What to Check | Legitimate | Fraudulent |
|---|---|---|
| Return-Path | acme-corp.com | smtp-relay-247.net |
| Origin server | internal.acme-corp.com | smtp-relay-247.net |
| Reply-To | [email protected] | invoices@acme-c0rp.com (zero, not O) |
| SPF | pass | fail |
| DKIM | pass | none |
| DMARC | pass | fail |
The From address looks right, but everything else screams fraud:
- The Return-Path shows a bulk relay service, not Acme
- The first Received header shows an unknown IP, not Acme's servers
- The Reply-To swaps the letter O for zero (acme-c0rp.com)
- All authentication failed
The attacker forged the From address but couldn't fake the infrastructure.
The Anchor Point
Attackers can add fake Received headers to make an email look like it originated internally. But they can't control one thing: the header added by your mail server.
When your organization's server accepts an incoming connection, it stamps a Received header with the actual IP address that connected. This is the anchor point. It records what your server actually saw, not what the sender claimed.
In the fraudulent example above, your mail server recorded:
Received: from smtp-relay-247.net (unknown [45.142.XX.XX])
The attacker might add fake headers below this claiming the email came from Acme's internal network. Ignore them. Your server's stamp is the truth. Everything added before your server received the message could be fabricated.
Caveat for cloud-filtered environments: If your organization uses a cloud email gateway (Mimecast, Proofpoint, Microsoft Defender for Office 365), the real anchor is the first Received header added by that trusted infrastructure, not necessarily the final internal mail server. The cloud gateway is the boundary where untrusted internet traffic first hits a system you control. Trace down to that header, then treat anything below it as potentially fabricated.
How do you preserve email evidence?
The most common mistake in email investigations: destroying the evidence before anyone knows to save it. The same discipline applies in any credential or wire-fraud investigation that starts with a suspicious message.
What destroys evidence:
| Action | What's Lost |
|---|---|
| Forwarding | Most headers stripped, new chain starts |
| Screenshots | All metadata, just pixels remain |
| Copy/paste text | Headers, structure, attachments |
| Printing | Everything except visible content |
What preserves evidence:
Save the original file directly from your email client:
Gmail: Show original → Download original
Outlook (Desktop only): File → Save As → Outlook Message Format (.msg). The web and new Outlook clients don't expose a Save As .msg option. Drag the message to your desktop instead, or use the "View message source" option above and save the .eml.
Apple Mail: File → Save As → Raw Message Source
This gives you an .eml or .msg file containing the complete message with all headers, attachments, and metadata intact.
Prefer .eml when you have a choice. It's a plain MIME (RFC 5322) text file that any tool can read and parse.[3] The .msg format is a proprietary Outlook compound binary file. It carries useful extra metadata but is harder to verify, parse, and share across forensic tools.
Document the chain of custody:
- When was the email received?
- When was it saved?
- Who saved it?
- Where is it stored?
- Has anyone modified it?
For legal cases, generate a hash (SHA-256) of the file immediately after saving. This proves the file hasn't been modified since preservation.
Quick Investigation Checklist
When examining a suspicious email:
- Save the original before doing anything else
- View the full headers using your email client's option
- Find your server's Received header (the anchor point)
- Check the origin IP in the earliest trusted Received header
- Compare addresses: Does From match Reply-To and Return-Path?
- Read Authentication-Results: Did SPF, DKIM, DMARC pass? For what domain?
- Look for lookalike domains: Character substitutions (0 for O, rn for m)
Key Takeaways
- Headers record the email's real journey. The visible message can lie. The metadata is much harder to fake completely.
- Your mail server's stamp is the anchor point. Attackers can forge headers, but they can't control what your server records when it receives the connection.
- Compare all the addresses. From, Reply-To, and Return-Path should align. Mismatches indicate manipulation.
- Authentication tells you which domain was verified, not whether it's trustworthy. An email can pass SPF/DKIM/DMARC for a malicious domain.
- Preserve evidence immediately. Forward and screenshot destroy the data you need. Save the original .eml or .msg file.
What's next: You now understand how email works, how authentication tries to verify senders, and how to investigate suspicious messages. For attacks that combine email with phone calls and text messages, see Attack Channels in the Social Engineering module. For a parallel investigation walkthrough that builds the same instincts on transactional data, see the first-investigation walkthrough.
Key Terms
Received header: A line added by each server that processes an email, recording its name, IP address, and timestamp. Read bottom-to-top to trace the path.
Anchor point: The Received header added by your mail server, which records the actual connection source and can't be forged by the sender.
Return-Path: The address where bounced messages go. Often differs from the From address in fraudulent emails.
Chain of custody: Documentation of who accessed evidence and when, required for legal proceedings.
File hash: A digital fingerprint (like SHA-256) proving a file hasn't been modified since a specific point in time.
Lookalike domain: A domain with subtle character substitutions designed to fool readers (acme-c0rp.com vs acme-corp.com).
References
1. FBI IC3 2024 Internet Crime Report (p. 9: Phishing/Spoofing was the single highest-volume crime type reported to IC3 in 2024 at 193,407 complaints).
2. RFC 5321 — Simple Mail Transfer Protocol — J. Klensin, October 2008. Section 4.4 specifies the trace information ("time stamp line") that each MTA prepends to a message it relays.
3. RFC 5322 — Internet Message Format — P. Resnick, October 2008. Specifies the syntax of header fields (From, To, Received, etc.) and message structure for .eml files.
CHECK YOUR UNDERSTANDING
Email Investigation Quiz
1. An employee reports a suspicious email and forwards it to your security team. When you try to analyze the headers, most of the routing information is missing. The investigation stalls. What went wrong, and what should the employee have done instead?
- The attacker deleted the headers remotely after the email was reported
- Forwarding strips out most header information. The employee should have saved the original as an .eml or .msg file to preserve the full headers for analysis.
- The email never had headers because it was sent through a VPN
- The security team needs to use a different email client to see headers
Show answer and explanation
Forwarding strips out most header information. The employee should have saved the original as an .eml or .msg file to preserve the full headers for analysis.
Forwarding an email creates a new message, discarding most of the original headers that contain critical forensic evidence (server IPs, authentication results, routing path). Always instruct employees to save suspicious emails as .eml or .msg files, which preserve the complete original headers.
2. You're analyzing the headers of a suspicious email and see five "Received" entries. Your colleague reads them top to bottom and says the email originated from a server in New York. You disagree. Why?
- Received headers should be read bottom to top because each server adds its entry to the top, so the oldest (origin) entry is at the bottom
- You should only look at the From address, not the Received headers
- The number of Received headers doesn't matter for tracing
- Headers added by your own mail server should be ignored
Show answer and explanation
Received headers should be read bottom to top because each server adds its entry to the top, so the oldest (origin) entry is at the bottom
Each mail server that handles an email adds its Received header at the top of the existing headers. This means the most recent server is at the top and the originating server is at the bottom. Reading top-to-bottom gives you the journey in reverse, which is why your colleague's analysis was wrong.
3. While tracing a phishing email, you notice that the bottom two Received headers show servers in a country known for cybercrime, but the Received header added by your own mail server shows a connection from a completely different IP address. Which header should you trust as the starting point for your investigation?
- The bottom headers, since they represent the original source
- The header added by your own mail server (the anchor point), because attackers can forge headers below it but can't control what your server records about the actual connection
- All headers equally, since none can be forged
- The From address, since it identifies the sender
Show answer and explanation
The header added by your own mail server (the anchor point), because attackers can forge headers below it but can't control what your server records about the actual connection
Your mail server records the actual IP address that connected to deliver the email. Everything below that header could have been fabricated by the sender. This "anchor point" is the most trustworthy piece of evidence in header analysis, and your investigation should build outward from there.