Email headers in litigation: what they prove and what they do not

Nearly every civil dispute contains at least one email that matters, and at least one party who believes a screenshot of it is evidence. It is not. An email tendered properly is a remarkably strong document, because unlike a letter it carries its own delivery record. An email tendered as a PDF or a screenshot carries almost nothing except its own text, which the person printing it could have written themselves. The gap between those two positions is where forensic examination of email lives.

This article sets out what email headers establish, what they leave open, and how to collect correspondence so that it survives challenge.

What an email actually is

An email in evidence should be produced as the original message file, most commonly an .eml or .msg export from the mail client or, better, from the mail server itself. The file contains two parts: the body and the headers. The headers are a stack of text fields, some written by the sender's own software, some added by every server the message passed through on its way to the recipient.

The distinction that matters in court is between fields the sender controls and fields the sender does not. The From line, the displayed date, the subject: all trivially editable by the sender, and forged constantly in phishing precisely because they are so easy to forge. The Received lines, added by each mail server in the chain, are written by infrastructure the sender does not control. That is the evidential spine of the message.

Reading the received chain

Each server that handles a message prepends a Received line, so the chain reads bottom to top: the oldest hop is nearest the body. Each line records the claiming server identity, the resolved IP address at the time, the encryption used, and a server-side timestamp. A well-formed chain lets the examiner trace the message from the recipient's inbox back to the sending infrastructure, with times at each hop.

Three checks dominate the work. First, plausibility of the times: server clocks are usually maintained by network time protocol, so hops should show a coherent progression within seconds. A chain with a hop that goes backwards by an hour, or that shows a five-day gap between two servers, needs an explanation before the message is safe to rely on. Second, consistency of the sender: does the IP in the first Received line actually belong to the mail system the sender claims to have used? Third, completeness: forwarding a message through a consumer client rewrites the headers into a much thinner set, and forwarding through some webmail services keeps almost nothing. The first instruction in most email disputes is therefore the same as our advice on preserving messaging exports: go back to the account or the server and export the original message files before anyone forwards anything else.

Where DKIM changes the picture

DKIM is the strongest authentication artefact an ordinary email carries. The sending domain's server cryptographically signs selected headers and the body; the signature travels with the message; and the recipient's server verifies it against the public key published in the domain's DNS records. If a produced message carries a valid DKIM signature from the sending domain, that is a technical demonstration, verifiable by a contrary expert, that the message was sent by infrastructure controlling that domain and that the signed headers and body have not been altered since.

Two honest qualifications. The signature proves the domain sent it, not that a particular person pressed send, and not that the visible From display name matches the signer. And the verification has a shelf life: the DNS key can be rotated or removed, so a message should be verified, and the verification documented, at the earliest opportunity rather than years later. When we examine email for proceedings, DKIM verification and archiving of the public key material is a standard early step, alongside the general discipline of chain of custody for digital material: hash the export, record who collected it and when, and keep the working copy untouched.

What headers do not prove

The gaps are as important as the strengths. Headers do not prove authorship. A shared mailbox, a compromised account, an assistant with delegated access: all produce perfectly authentic headers for a message the named individual never wrote. Headers do not survive every journey. A message opened on a phone, screenshotted, and sent on has left nearly all its evidential value in the original mailbox. And headers can be absent entirely: emails exported to PDF, or pasted into a witness statement, have no chain at all and are only as good as the witness's credibility.

Server-side logs fill some of these gaps where they can be obtained. Mail providers retain delivery logs for limited windows, and a subpoena or a properly scoped disclosure request made early can produce records independent of either party, including logins, IP addresses and delivery confirmations. The operative word is early. Retention windows on large consumer providers are measured in weeks to months, not years.

Practical guidance for instructing parties

• Export original message files (.eml or .msg) from the mail client or server, not screenshots, not PDFs, and never rely on a forwarded copy.
• Export the whole relevant mailbox or folder rather than cherry-picking messages; context and surrounding correspondence defeat selective-quotation arguments.
• Preserve access early: keep the account open, note credentials with solicitors, and act on provider log retention windows within weeks, not at trial.
• Ask for DKIM verification to be performed and documented while the sending domain's keys are still published.
• Treat header analysis as a specialist exercise: a badly read Received chain by an amateur does more damage in cross-examination than no analysis at all.

The honest summary: an email preserved as its original file is one of the strongest forms of correspondence evidence available, self-dating, self-routing, and cryptographically checkable in many cases. The same email as a screenshot is a claim. The entire difference is made in the first week, by whether somebody exported the real thing before it quietly disappeared.