Email metadata and admissibility
An email exhibit usually goes in without argument. Both sides know the correspondence is real, nobody contests it, and the printed message is accepted for what it plainly is.
This page is about the other situation — where a party disputes that they sent a message, or that it says what it appears to say. That argument is not conducted in the body text. It is conducted in the metadata, and it is where the difference between a screenshot and a retained native stops being academic.
What is actually in a message
Every email carries two layers, and only one of them is normally visible.
The face of the message is what a mail client displays: From, To, CC,
Date, Subject, and the body. This is what appears on a printed exhibit, and
for the great majority of cases it is entirely sufficient.
Beneath it sits the transport layer. A Received header is prepended by
each mail server that handles the message, so the headers accumulate in reverse
chronological order, recording the route the message actually travelled and
when each hop happened. A Message-ID uniquely identifies the message.
Authentication-Results records the receiving server’s verdict on SPF, DKIM
and DMARC checks — whether the sending server was authorised to send for that
domain, and whether the message’s cryptographic signature validated.
None of that is printed on a PDF, shown in a mail client, or present in a
screenshot. It exists in the .eml file and nowhere else
you are likely to have kept.
Which parts prove anything
Not all headers are equal, and the difference matters because they fail in different directions.
The From header proves very little. It is set by whatever sent the
message. Anyone can put anything in it — this is the mechanism behind essentially
every phishing email. A dispute that comes down to “I never sent that” cannot be
resolved by pointing at the From line.
The Received chain is substantially harder to fabricate. Each hop is added
by a different system, and a forged chain has to be internally consistent in
timing, in routing, in server naming, and against what those servers’ own logs
would say. It is not impossible; it is a different order of effort, and
inconsistencies are findable.
Authentication results are harder still. DKIM in particular involves a cryptographic signature over parts of the message, verifiable against a public key published in the sending domain’s DNS. A valid DKIM signature is meaningful evidence that the message came from that domain and was not altered in specified respects along the way — subject to the significant caveat that keys get rotated and old ones become unverifiable, so this is more reliable close in time to the message.
The practical upshot: the metadata does not usually decide the question by itself, but it determines how much work the other side has to do to raise a serious dispute, and whether you have anything to answer with.
Authentication under the Federal Rules
Authentication is the requirement that the proponent produce evidence sufficient to support a finding that the item is what it is claimed to be. It is a low bar, and it is not the same as admissibility — a properly authenticated email can still be excluded as hearsay, as irrelevant, or on any other ground.
The routes most commonly used for email are:
- Testimony of a witness with knowledge — someone who sent, received, or otherwise knows the message, saying so. This carries most email into evidence in practice.
- Distinctive characteristics — the content, internal patterns, or context of the message taken together with the circumstances. Reply chains, details only the purported sender would know, and consistent addresses all do work here.
- Evidence describing a process or system producing an accurate result, which is the route that engages how the message was collected and converted.
Since December 2017 the rules have also provided self-authentication routes for certain electronic evidence — a certification by a qualified person regarding a record generated by an electronic process or system, and a certification that a copy of data was authenticated by a hash value or other reliable digital identification. Both are aimed at removing the need for live foundational testimony where authenticity is not genuinely in dispute, and both come with notice requirements and their own conditions.
What all of this actually requires in your matter depends on your jurisdiction, the governing rules and the applicable case law, and it changes. Nothing here is legal advice. Confirm the requirements before relying on any of it.
What this means for the workflow
The rules point in a consistent practical direction, and it is not a demanding one.
Keep the native. The .eml or .msg original is the artifact that carries
everything the printout does not. It costs nothing to retain and cannot be
recovered later. Everything else on this list is downstream of it.
Do not let the first step destroy evidence. The two common ways to lose metadata are forwarding — which creates a new message with new headers, nesting the original in the body — and printing, which keeps the face and discards the rest. If either is how a message reached you, note that fact and go looking for the original.
Render the exhibit so it carries the header block. An exhibit showing
From, To, CC, Date and Subject on its face is self-describing. One
that shows only body text needs a witness to say what it is, which is fine
until the witness is unavailable or their recollection is contested.
Record the handling. Who collected it, from where, when, and what was done to it. This is chain of custody and for a small matter it is a paragraph in a memo, not a protocol.
Preserve hashes where it matters. Especially for attachments — which is why extracting them byte-for-byte rather than re-rendering them into a PDF is worth insisting on. A re-encoded attachment has a different hash for an innocent reason, and you cannot demonstrate that innocence with the hash itself.
The proportionate version
Most email exhibits are uncontested and none of this comes up. The reason to follow the workflow anyway is that you do not find out which messages will be contested until later, and by then the choices that mattered — retain the native, do not forward, record the collection — were made months ago in about ten minutes of work.
Doing it in EML Exhibit
-
Collect the native, not a printout
Keep the .eml or .msg original alongside anything you produce. It is the only artifact carrying the full transport header chain, and it cannot be reconstructed from a PDF afterwards.
-
Preserve the headers before anything else touches the message
Forwarding a message to yourself creates a new message with new headers. Print-to-PDF discards the transport chain entirely. Whatever else you do, get an unmodified copy out first.
-
Render the exhibit from the native
Convert the .eml to a paginated PDF with the header block printed above the body, so the exhibit shows sender, recipients, date and subject on its face rather than in someone's testimony about it.
-
Record how it was handled
Who collected it, when, from which mailbox, and what was done to it. This is the chain of custody, and ten minutes at the time replaces an uncomfortable reconstruction later.
-
Keep hashes where the matter warrants it
For attachments especially, a hash recorded at collection and re-computed later demonstrates the bytes are unchanged — which only works if nothing re-encoded the file in between.
Is a printed email admissible?
Routinely, yes — most email exhibits are printouts and most go in without objection. The point is not that a printout is inadmissible; it is that a printout carries almost no information for answering a genuine authenticity challenge, and by the time you discover the challenge is coming, the native may be gone.
Can email headers be faked?
The From header can be trivially set to anything — it is a display
field chosen by the sender. The Received chain is much harder to
fabricate consistently, because each line is added by a different server
and the chain has to remain internally coherent in timing and routing.
SPF, DKIM and DMARC results recorded by the receiving server are harder
still. None of this is conclusive on its own; it shifts how much work an
opposing party has to do.
What does a self-authenticating certification under FRE 902(13) or 902(14) actually do?
Broadly, it lets a qualified person’s written certification stand in for live foundational testimony, so a record generated by an electronic process or a hash-verified copy of data can be authenticated without calling a witness at trial. It addresses authenticity only — not hearsay, relevance, or any other objection. It also carries notice requirements. Whether it fits your situation is a question for the rules and case law governing your matter.
Does converting an email to PDF affect admissibility?
Converting produces a rendering, and how a rendering is treated depends on what it is offered for and whether anyone contests it. The practical protection is not avoiding conversion — it is retaining the native so the rendering can be checked against it, and being able to describe how the conversion was done.
What if the only copy is a screenshot the client took?
Work with it, and go looking for the native in parallel — in the client’s mailbox, in the sender’s, in a backup, or in the recipient’s if that party is cooperative. A screenshot proves that something appeared on a screen. Almost every question an opposing party will raise about the message is answered somewhere the screenshot does not reach.