Email header analysis: what metadata actually proves in a legal dispute

Email is the most common form of digital evidence in civil and criminal litigation. Contract disputes, employment tribunals, fraud cases, regulatory investigations: almost every case that goes to court today involves at least one disputed email. And the question is not always whether the email was sent, but who sent it, when, from where, and whether it has been altered since.

Email headers are the metadata that accompany every email message. They contain routing information, authentication results, timestamps, and sender and recipient details. For a forensic examiner, the headers are the evidence. The body of the email is what the parties are arguing about, but the headers are what establish provenance.

This article describes how email headers are examined in professional forensic practice: what the fields mean, what they prove, what they do not prove, and how they are presented in court.

What email headers contain

Every email message consists of two parts: the body (the content the recipient reads) and the headers (the routing and metadata that got it there). The headers are added by the mail servers that handle the message as it travels from sender to recipient. Each server adds its own block of headers to the top of the message, so reading a header from bottom to top gives you the route the message took.

The key fields a forensic examiner looks at are:

• Received headers: These record each server that handled the message, the timestamp of the handoff, the IP addresses involved, and the protocol used. A single email might have 4 to 10 Received headers, depending on how many hops it made.
• Message-ID: A unique identifier assigned by the sending mail client or server. No two messages should share a Message-ID.
• Date: The timestamp the sender's client claims the message was sent. This is set by the sender's software, not by any server, so it can be falsified.
• From, Reply-To, Sender: The claimed sender address. These fields are set by the sender's mail client and are trivial to forge unless authentication records confirm them.
• Authentication headers (Authentication-Results, Received-SPF, DKIM-Signature): These record the results of SPF, DKIM, and DMARC checks performed by the receiving server. They are the most important fields for establishing whether the sender is who they claim to be.

What headers can prove

Headers can establish three things with reasonable certainty: the route the message took, the time it was handled by each server, and whether the sending domain's authentication records validated the message.

Routing. The Received headers, read from bottom to top, show every server that handled the message. Each Received header includes the IP address of the connecting server, the hostname of the receiving server, and a timestamp. This chain is difficult to forge convincingly because each server in the chain independently records its own header. A forger would need to control every server in the chain, or fabricate headers that are internally consistent across multiple independent systems.

Timing. The timestamps in Received headers are set by the mail servers, not by the sender. If a message passes through three servers, you have three independent timestamps from three independent clocks. Discrepancies between these timestamps can indicate that a message was delayed, relayed through an unusual path, or fabricated after the fact. Timezone information is included in every timestamp, which allows the examiner to normalise all timestamps to a single timezone for comparison.

Authentication. SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting, and Conformance) are the three authentication systems used by email servers. SPF checks whether the sending IP is authorised to send mail for the domain. DKIM checks whether the message was signed with a cryptographic key associated with the domain. DMARC ties SPF and DKIM together and tells the receiving server what to do if authentication fails. The results of these checks are recorded in the headers by the receiving server, and they are the primary evidence of whether the sender's domain actually sent the message.

What headers cannot prove

Headers cannot prove who was sitting at the keyboard. Authentication confirms that a message came from a particular domain or was signed with a particular key, but it does not confirm which person at that domain sent it. If several people share an email account, or if an account has been compromised, the headers will show the correct domain but cannot identify the individual sender.

Headers also cannot prove that a message was received and read. The headers show that the message was delivered to the recipient's mail server, but not that it was opened, displayed, or read by the recipient. Read receipts and delivery receipts exist but are unreliable: they can be suppressed by the recipient's mail client, and they can be generated by mail filters without the recipient ever seeing the message.

Headers cannot prove the content of the message at the time it was sent. The body of an email can be altered after delivery, particularly if it is stored in a mailbox that allows editing (some webmail clients do). The headers, once written by the servers, are more difficult to alter because they are embedded in the raw message source, but a determined forger with access to the mailbox could modify both headers and body. This is why forensic examination of email evidence typically involves analysing the raw message source from the mail server's logs or backup, not from a screenshot or a forwarded copy.

How headers are examined in practice

The examination process follows the same chain-of-custody principles as any other digital evidence. The examiner acquires the raw message source (the complete email including all headers) from the mail server or from a forensic image of the device where the mailbox is stored. The raw source is hashed (SHA-256) at the point of acquisition, and the hash is recorded in the chain-of-custody documentation.

The examiner then analyses the headers using tools that parse and display the fields in a readable format. Common tools include Python libraries that parse RFC 5322 message structures, the Message Header Analyser tool from Microsoft, and command-line tools like swaks and dig for verifying DNS records associated with SPF, DKIM, and DMARC.

The analysis involves:

1. Reading the Received headers from bottom to top to reconstruct the message route.
2. Verifying the timestamps for consistency across all hops.
3. Checking the SPF, DKIM, and DMARC results to confirm whether the sending domain authenticated the message.
4. Cross-referencing the IP addresses against public databases (WHOIS, geolocation) to determine the geographic origin and the ISP or hosting provider.
5. Comparing the headers against any available mail server logs from the sending or receiving servers.
6. Checking for signs of header injection or tampering, such as duplicate headers, inconsistent timestamps, or Received headers that do not match the expected format.

Common challenges to email evidence in court

The most common challenge is that the email was altered after the fact. If the only copy of the email is in a mailbox that the party controls, and the mailbox allows editing or deletion, the opposing party will argue that the message has been tampered with. The defence to this challenge is to produce the message from an independent source: the recipient's mail server logs, a backup of the mailbox taken before the dispute, or a copy forwarded to a third party at the time of sending.

The second most common challenge is that the email was sent by someone other than the party. If the sender's account was compromised, or if the email was sent from a shared account, the party may argue that they did not send the message. SPF, DKIM, and DMARC records help here because they confirm that the message was sent from an authorised server, but they cannot identify the individual user. The examiner may need to look at additional evidence, such as the sending IP address, the mail client identifier in the headers, and any available server-side logs.

The third challenge is that the timestamp is unreliable. If the sender's system clock was wrong, or if the server timestamps are in different timezones and the conversion was handled incorrectly, the opposing party may challenge the timing of the message. The examiner normalises all timestamps to UTC and cross-references them against server logs to establish a reliable timeline.

Presenting email evidence in court

Email evidence is presented in court through a witness statement or expert report. The report should include the raw message source (with hashes) as an exhibit, a parsed view of the headers showing each field and its meaning, a routing diagram showing the path the message took, the authentication results and what they mean, any discrepancies or anomalies found during the examination, and the examiner's opinion on whether the message is authentic based on the evidence in the headers.

The examiner must be prepared to explain, in terms a judge or jury can understand, what each header field means, why the authentication results matter, and what the limitations of the evidence are. The duty is to the court, not to the party instructing the examiner, and the examiner must disclose any findings that are adverse to the instructing party's case.

For a detailed treatment of the chain-of-custody process that governs how email evidence is acquired and preserved, see our article on chain of custody for digital evidence. If you need a forensic examination of email evidence for an ongoing matter, contact us directly.