Email Forensics

What it is and why it matters

Email is old, open and easy to forge. The format has barely changed since the 1980s, and the protocol that carries it was designed to trust whatever the sending server claimed. That is why a message can show any name in the From line and why phishing and business email compromise remain the most common ways into an organisation. It is also why an email that looks damning on screen proves nothing until its headers, its server records and its mailbox context have been examined.

The examiner's material comes in three layers. The message itself carries headers added by every server that handled it, like postmarks on an envelope. The mailbox stores on a computer, a phone or a server hold the message among its neighbours, with the folder it sat in, when it was read and whether it was deleted. The mail servers and cloud services keep logs of what they accepted, from whom and when. Each layer can confirm or contradict the others, and a forged message tends to fail at least one of them.

Reading an email properly also means knowing what the authentication results mean. SPF, DKIM and DMARC are checks a receiving server runs on an incoming message. A pass does not make the content true. A fail does not always mean forgery. The examiner reports what each check says and what, in that mail system, it can and cannot establish.

Types of digital evidence

Message Headers
The fields defined in RFC 5322 such as From, To, Date, Subject, Message-ID, In-Reply-To and References, plus the trace fields Received and Return-Path added by servers along the route.
Authentication Results
The Authentication-Results header written by the receiving server with the SPF, DKIM and DMARC outcomes, and vendor headers such as Microsoft's X-Forefront-Antispam-Report that record how the message was classified.
Body and Attachments
The MIME parts, their declared and actual types, embedded images, links and the attachments, each of which can be hashed and examined on its own.
Mailbox Stores
Outlook PST and OST files, Apple Mail and Thunderbird mbox stores, individual EML and MSG files, Exchange databases and the mail databases inside phone extractions.
Server and Gateway Logs
SMTP transaction logs, message tracking logs on Exchange, Google Workspace Email Log Search records and spam gateway logs that show acceptance, rejection, delivery and the connecting address.
Mailbox Audit Records
Logs of mailbox sign-ins, folder access, rule creation, forwarding changes and deletions, available in Microsoft 365 and Google Workspace audit tools.
Client Artefacts
The Outlook autocomplete cache, search indexes, drafts, calendar entries and the local caches that keep a copy of messages the user deleted from the server.
Deleted and Recovered Items
Messages recoverable from the Deleted Items and Recoverable Items folders, from unused space in a PST file and from mailbox backups.

Devices and data sources

Desktop mail clients such as Outlook, Thunderbird and Apple Mail on a computer image
Mail applications on Android and iOS phones, reached through a mobile extraction
Exchange Server and Microsoft 365 mailboxes, with their audit logs and message trace
Gmail and Google Workspace accounts, with Email Log Search and Vault exports
Webmail accounts at other providers, reached with the account holder's consent or legal process
SMTP relay, spam filter and mail gateway logs at the organisation's perimeter
Backups and archives of mailboxes kept for compliance
Printed or forwarded copies supplied by a complainant, treated as leads and checked against the originals

How an examination runs

The order matters. Each step protects the one after it.

01
Scope and Authority
Decide whose mailbox, which period and which questions. A complainant can consent to their own mailbox being examined. Anyone else's needs a lawful basis, and the organisation's policy if it is a work account.
02
Preserve the Mailbox
Place a legal hold or export the mailbox in its native format with the provider's tool before anyone deletes anything. For a desktop client, image the computer or copy the PST or mbox file and hash it.
03
Get the Original Message
Work from the raw message with full headers, not from a forwarded copy. Forwarding rewrites the headers and strips the trace fields that matter.
04
Read the Trace Headers
Follow the Received lines from the bottom upwards, since each server adds its line at the top. Check that the chain is continuous, that the timestamps make sense and that the first external server fits the claimed sender's domain.
05
Check Authentication and Identity
Compare the From header with the envelope sender, read the SPF, DKIM and DMARC results and verify the DKIM signature against the domain's published key where possible.
06
Correlate With Logs
Match the Message-ID and the timestamps against server, gateway and audit logs. A message that exists in a mailbox but never passed the gateway was planted or imported, not received.
07
Report
Set out the path the message took, what the authentication results show, any sign of alteration and what remains unknown, for example a sender behind a free webmail account whose identity only the provider can confirm.

Tools used in this discipline

Independent profiles: what each tool does, where it stops and what you need to know before using it.

Browse the full tools directory

Terminology

Envelope and Header: The envelope is the SMTP conversation's MAIL FROM and RCPT TO addresses used for delivery. The header From is a display field inside the message. They can differ, and spoofing often relies on that.
Received Header: The trace field each mail server adds at the top of the message, recording from where it received the message, by which server, with what protocol and at what time.
Message-ID: A unique identifier assigned by the sending system, usually a string followed by the @ sign and a domain. It links replies through the In-Reply-To and References fields.
SPF: Sender Policy Framework. A DNS record that lists the servers allowed to send mail for a domain. The receiver checks the connecting server's address against it.
DKIM: DomainKeys Identified Mail. A digital signature over selected headers and the body, added by the sending domain and checked against a public key in DNS. A valid signature shows the signed parts were not changed after signing.
DMARC: Domain-based Message Authentication, Reporting and Conformance. A policy that tells receivers what to do when SPF and DKIM fail to align with the From domain, defined in RFC 7489.
PST and OST: Outlook's personal store file and its offline cache of a server mailbox. Both can hold deleted items in unused space until the file is compacted.
Mbox and EML: Mbox is a single text file holding many messages one after another. EML is a single message saved as a file. Both keep the raw headers.
Mailbox Rule: A server-side instruction such as forward, move or delete that acts on incoming mail. Attackers in a compromised mailbox often add one to hide their activity.

Challenges and limits

What makes it hard

A forwarded or printed email has lost the headers that matter, and many complaints arrive in exactly that form
Header fields other than the trace lines can be typed by the sender, and even Received lines can be forged below the first trusted server
Free webmail providers hide the sender's address behind their own servers, so identifying the person needs provider records under legal process
Authentication checks tell the examiner about the domain, not the person. A compromised account passes SPF, DKIM and DMARC perfectly
End-to-end encryption with S/MIME or PGP leaves the body unreadable without the recipient's private key
Provider logs and audit records have retention limits, and a mailbox examined months after the event may have lost the context around a message
Time zones in Date and Received headers vary with each server, and a careless reading puts the reply before the original

Keeping the evidence intact

Export mailboxes and messages in native formats with full headers and hash each file before examination
Keep the raw message source alongside any rendered or printed version used in a report
Record the exact provider tool, export options and date range used, since exports can silently omit folders or items over a size limit
Never open a suspect attachment on the examination machine outside a controlled environment, and hash it before it is analysed
Document any decryption keys used and where they came from

Standards and legal considerations

NIST SP 800-45 Version 2
Guidelines on Electronic Mail Security. Explains how mail servers, clients and protocols work and where their logs sit, which is the background every email examiner needs.
RFC 5322 and RFC 7489
The Internet Message Format standard that defines the header fields examined on this page and the DMARC specification that defines the alignment checks. Technical standards, not forensic ones.
NIST SP 800-86
The general examination process, with email named among the application data sources.
Read the guide
Bharatiya Sakshya Adhiniyam, 2023
Governs the admissibility of electronic records in Indian courts, including the certificate that accompanies an email produced as evidence.
Read the guide
Information Technology Act, 2000
Defines the offences that email cases most often involve, including identity theft and cheating by personation using a computer resource, and the duties of intermediaries that hold mail.
Read the guide

In practice

The Changed Bank Account
A supplier's email asks a company to pay into a new account. The From line shows the supplier's domain. The Received chain shows the message entered from a server with no connection to that domain, SPF fails, there is no DKIM signature and the Reply-To points to a look-alike domain registered three days earlier. The examiner reports the message as spoofed and the payment instruction as unreliable.
A Mailbox That Was Quietly Forwarding
An accounts manager's mailbox is examined after a fraud. The mailbox audit log shows a sign-in from an unfamiliar address, followed within minutes by a new rule that forwards every message containing the word invoice to an external address and moves the original to a hidden folder. The rule's creation time becomes the point from which every later message is treated as read by the attacker.
An Email Produced in a Dispute
One party produces a printed email as proof of an agreement. The other party's mailbox export contains no such message, the Message-ID on the print does not match the sending system's format and the server tracking log for that day has no entry for it. The examiner reports that the message cannot be traced through any system that should have handled it.

This page is educational material, not legal advice. Laws and standards change, commence on different dates and are interpreted differently across jurisdictions. Always read the official text linked on this page and take advice from a qualified professional for a real matter.

Learn it at DFRTI

Free pages explain. These courses teach it on real devices with a mentor.

LegalFoundation & Legal CoursesBasics of Cyber ForensicsStart here. Evidence handling, imaging, hashing, chain of custody and your first analysis.BeginnerDCFA

AdvancedAdvanced & Specialised ForensicsOSINT / Open Source IntelligenceFind, verify and record public online information in a form a court can checkIntermediate

LegalFoundation & Legal CoursesLegal & Court ProceduresIndian law on electronic evidence: BSA Section 63, BNSS search and seizure and the IT Act.BeginnerDCFA

LegalFoundation & Legal CoursesForensic Report WritingWrite clear forensic reports that answer the questions asked and survive cross-examination.IntermediateDCFA

Standards for this area

Careers that use it

Questions people ask

Can the sender of an email always be identified?

No. Headers show the servers a message passed through and the domain checks it passed or failed. For a message from a free webmail account, the person behind it is known only to the provider, who releases that under legal process and within their retention limits.

Does a DKIM pass prove the email is genuine?

It proves the signed parts were not altered after the sending domain signed them. It says nothing about whether the account that sent it was in the right hands, or whether the content is true.

Is a screenshot of an email enough?

It is a lead, not evidence of origin. The raw message with full headers, exported from the mailbox and hashed, is what the examiner needs. Screenshots are easy to edit and carry no trace information.

What about deleted emails?

Deleted items often survive in the Recoverable Items folder, in the unused space of a PST file, in server backups or in the other party's mailbox. Retention settings decide for how long. The sooner the mailbox is preserved, the better the chance.