Email forensics

01Scope

Header analysis: Received chain order, time stamps and zones, Message-ID, Return-Path, X-Originating-IP
Authentication results: SPF, DKIM signature verification, DMARC alignment, ARC
Mailbox stores and exports: PST/OST, MBOX, EML, provider exports and their item metadata
Attachments: hashing, file signatures, embedded metadata, links and their redirect chains
Business email compromise patterns: look-alike domains, reply-to changes, inbox rules, thread hijacking

Source	What it yields	Note
Original message as stored at the recipient (EML/MSG with full headers)	Complete Received chain, authentication results, Message-ID, MIME structure	A forwarded or printed copy loses the original headers; obtain the item from the mailbox store.
Receiving mail server logs (MTA, gateway, filter)	Connecting IP, HELO, TLS, queue IDs, delivery time, filter verdicts	Server logs corroborate the Received headers the server wrote; the two must agree.
Mailbox audit and sign-in logs	Who read, moved, deleted or created rules, from which IP and client	See the cloud area for preservation; the logs expire.
Sender-side records where available (sent items, SMTP logs, DKIM keys in DNS)	Whether the message exists in the purported sender's store; key validity at the time	DNS records change; capture them with a time stamp when the examination is done.

Get the original item, not a copy of a copy
Export the message from the mailbox store with full headers; hash it; note the store, folder, item ID and export method.
Read the Received chain bottom-up
The lowest Received header is the first hop. Each hop's time is in that server's zone; convert all to UTC and check that times increase. Out-of-order or missing hops are findings.
Verify authentication, do not just read it
Re-verify the DKIM signature against the public key in DNS at the time of examination; evaluate SPF against the connecting IP in the receiving server's own Received header; check DMARC alignment of the visible From domain.
Compare with the sender's store
If the purported sender is available, look for the item in Sent Items and the SMTP logs; a message that exists only at the recipient needs a different explanation.
Trace attachments and links
Hash attachments, identify them by signature, read their embedded metadata. Resolve shortened links in a controlled environment and record the chain and final destination with times.

The library records behind this area:

The From header is writable by the sender; the Return-Path, the connecting IP and the DKIM domain are the fields that carry weight.
Received headers added before the recipient's own server are trusted only as far as that server is; a sender can forge earlier hops.
The Date header is set by the sending client and can be wrong or deliberately set; use server times.
A valid DKIM signature proves the signing domain handled the message, not that the human named in From wrote it.
Screenshots of emails are not email evidence.

Source of the message item (store, folder, item ID), export method and hash.
Hop-by-hop table of the Received chain in UTC with the server that wrote each line.
SPF, DKIM and DMARC results as re-verified, with the DNS records captured and dated.
A plain statement of what the headers prove about origin and what they do not.

Was the original item with full headers examined, or a forwarded copy?
Were DKIM and SPF re-verified, or only read from the Authentication-Results header?
Do the receiving server's logs match the Received headers?
What does the report say about the From display name versus the actual sending domain?