What Email Forensics Actually Looks At: Anatomy, Headers and Authentication

Q: Do I need specialist software, or is View Source enough?

View Source is enough to *see* headers. A dedicated analysis is faster once you have several messages, need a report, or are not practised at reading Authentication-Results. The method is the same either way.

The body is the story. The headers are the evidence

People search for "email forensics" when a message does not add up: a threat, a lookalike invoice, a phishing lure, a mail that claims to be from a colleague and is not. Reading the visible text is necessary and not sufficient. The parts that decide origin and authenticity sit above the body, in headers most clients hide behind a "show original" or "view source" control.

The anatomy is stable across providers. An email has an envelope (the SMTP path used to deliver it), a header block (From, To, Date, Message-ID, Received lines, authentication results), a body (plain text and/or HTML), and optional MIME parts (attachments, inline images). Forensics starts with that structure, not with a hunch about the wording.

Email Forensics on this site is a header-and-routing analysis of files you already have (.eml, .msg, or a PST). It does not seize mailboxes, decrypt other people's accounts, or replace a police investigation. It makes the technical record readable so a person can decide what to do next.

A concrete example

Reading one message the way an investigator would

Use this on a saved original, not a forward. Forwarding often rewrites headers and destroys the path you need.

The situation

A member of the public has received a threatening or otherwise serious email. You want to examine the extended headers — Received lines, originating IP, Message-ID, authentication results — before you escalate, not after you have forwarded the mail around and lost the original.

Source and destination you choose

Where it comes from

The original .eml or .msg

Saved from the client that received it, with headers intact

Why this one: Extended headers live in that file. A screenshot of the body has none of them.

Also works with

Pasted raw headers if you can still open View Source
A PST if several related messages need the same pass

Where the result goes

Forensics report (on-screen, PDF or CSV)

Headers, contacts, routing hops, authentication, and a plain-language summary

Why this one: Raw header blocks are easy to misread. A structured report is something you can attach to a ticket or a police statement.

Or choose

Header-only view if you already know what you are looking for
Routing view when the question is "which servers touched this"

A working order of examination

1

Preserve the original file

Save .eml/.msg before anyone forwards, prints, or "cleans up" the thread. Note when and from which account you saved it.
2

Read the header block as a timeline

Received lines are written as the message travels; the bottom Received is typically the first hop, the top one the last. That path is the route, not the From: display name.
3

Check authentication, not just the From line

SPF says whether the sending server was allowed for that domain. DKIM says whether the body and some headers still match a signature. DMARC says what the domain owner asked receivers to do on failure. A pretty From: address can still fail all three.
4

Separate "looks wrong" from "provably from this person"

A pass on SPF/DKIM can still be a compromised legitimate mailbox. A fail can still be a misconfigured but genuine server. Headers narrow the story; they do not finish it.

If this is a crime report, the original file and a note of chain of custody matter more than a tidy summary. Keep both. Do not "improve" the evidence by converting it to PDF only.

Anatomy you actually use

Envelope vs header From. SMTP delivers to envelope recipients. The From: you see can be arbitrary text. Forensics cares about both, and about Return-Path, which often reflects the envelope sender.

Message-ID. A unique identifier assigned near the origin. Useful for correlating the same message across mailboxes. Easy to forge if someone is building a fake .eml from scratch, which is why it is a clue, not a proof.

Date. The Date: header is set by the sending client and can be wrong or spoofed. Server Received timestamps are harder to fake in a real transit path, though not impossible if the attacker controls a hop.

MIME parts. HTML bodies can hide links behind display text. Attachments can be a different threat from the body. A forensic pass that only reads the preview pane will miss both.

None of this requires a lab. It requires the original file and a way to parse it without destroying it.

Where a tool helps, and where it must not over-claim

Parsing Received chains, Authentication-Results, ARC, and MIME by hand is slow and easy to get backwards. Email Forensics does that parse and shows contacts, websites, routing and authentication in separate views so you are not staring at a 200-line header blob.

What it will not do, honestly: name a human being from an IP with certainty, recover mail the provider has already deleted, or declare a message "safe." IP geolocation is approximate. Compromised accounts authenticate. Shared hosting and privacy relays hide consumer origins. A good report lists what the headers support and what they do not.

Questions that show up around "what is email forensics"

Is this the same as reading someone else's inbox?

No. You analyse files you already have a right to — mail sent to you, mail your organisation retains, or mail provided for an investigation. Unauthorised access to an account is a different, usually illegal, activity.

Do I need specialist software, or is View Source enough?

View Source is enough to see headers. A dedicated analysis is faster once you have several messages, need a report, or are not practised at reading Authentication-Results. The method is the same either way.

What if SPF, DKIM and DMARC all pass?

Then the message likely came from an authorised sender for that domain, or from a mailbox that domain actually controls. It can still be malicious if that mailbox was taken over. Passing auth is not the same as a trustworthy human.