Email Investigation

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:

1. Open the email
2. Click the three dots (top right)
3. Select "Show original"
4. A new tab opens with full headers and message source

Outlook (Desktop):

1. Open the email
2. File → Properties
3. Headers appear in the "Internet headers" box at the bottom

Outlook (Web and new Outlook):

1. Open the email
2. Click the three dots (More actions)
3. Select View, then "View message source" (labeled "View message details" in some versions)

Apple Mail:

1. Open the email
2. View → Message → All Headers

Yahoo Mail:

1. Open the email
2. Click the three dots
3. 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: <invoices@acme-corp.com>
Received: from mail.recipient.com (mail.recipient.com [192.168.1.50])
        by mx.recipient.com with ESMTP id abc123
        for <you@recipient.com>; 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 <you@recipient.com>; 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 <you@recipient.com>; Tue, 15 Oct 2024 09:23:40 -0400
From: Acme Corp Invoicing <invoices@acme-corp.com>
Reply-To: invoices@acme-corp.com
To: you@recipient.com
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:

1. Bottom Received (09:23:40): Email created on Acme's internal server
2. Middle Received (09:23:42): Handed to Acme's outbound mail server
3. 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: <bounce@smtp-relay-247.net>
Received: from mail.recipient.com (mail.recipient.com [192.168.1.50])
        by mx.recipient.com with ESMTP id xyz999
        for <you@recipient.com>; 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 <you@recipient.com>; 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 <you@recipient.com>; Tue, 15 Oct 2024 11:05:15 -0400
From: Acme Corp Invoicing <invoices@acme-corp.com>
Reply-To: invoices@acme-c0rp.com
To: you@recipient.com
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:

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:

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:

1. Save the original before doing anything else
2. View the full headers using your email client's option
3. Find your server's Received header (the anchor point)
4. Check the origin IP in the earliest trusted Received header
5. Compare addresses: Does From match Reply-To and Return-Path?
6. Read Authentication-Results: Did SPF, DKIM, DMARC pass? For what domain?
7. 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.