Email Metadata: What It Is, Examples, and Outlook Headers

Email metadata is the information describing an email, including who it lists as sender and recipient, when it was sent, and how servers handled it. A timestamp, Message-ID, or routing header can supply context that a screenshot leaves out.

When attorneys talk about email evidence, they usually mean the words on the screen: what was said, by whom, to whom. That visible text is important. But beneath it sits a second layer of information that courts increasingly rely on, and that opposing counsel increasingly exploits.

Email metadata. It's not glamorous. Most attorneys have a vague sense it exists, a firm belief that their IT department handles it, and limited patience for the details. That approach is defensible in transactional work. In litigation, it is a liability.

This guide covers what email metadata actually is, why it matters in discovery and trial, how it can be used against your client (or for them), and what practical steps small firm attorneys need to take to handle it properly.

What Email Metadata Actually Is

Metadata is data about data. In the context of email, it refers to the technical information attached to every message that is not part of the visible body text.

Some of it is familiar. The "From," "To," "CC," and "Subject" fields you see in your email client are technically metadata, in the sense that they describe the message rather than constitute it. But those are just the surface.

The more consequential metadata is in the email's full headers, a block of technical information that most email clients hide by default. A full email header typically includes:

Message-ID. An identifier usually assigned when a message is created or sent. It helps connect copies and replies, but can be missing, duplicated, or forged. It is not an authenticity certificate.

Timestamps. Multiple timestamps, not one. There's the "Date" field (when the sender's mail client recorded the message), the server-received timestamp (when the recipient's mail server received it), and often intermediate timestamps from mail relay servers along the route. These rarely match perfectly, and the discrepancies sometimes matter.

Routing information. The "Received" headers trace the path the email took from sender to recipient, server by server. This shows which mail servers processed the message, in what order, and at what times.

User-Agent string. The email client software used to compose the message (e.g., "Microsoft Outlook 16.0.14701.20226 for Windows"). This can be used to verify whether a claimed email was plausibly composed on the device the sender says they used.

Read receipts and delivery receipts. When supported and enabled, these may generate separate reports about delivery or display. A report does not necessarily prove that a particular person read or understood the message.

DKIM signatures. DomainKeys Identified Mail lets a signing domain cryptographically sign selected headers and body content. Successful verification supports integrity of the signed material, not the identity of its human author. Missing signatures or failed verification need context, not an automatic accusation of forgery.

Email metadata example and Outlook lookup

A message might have a Date field with a time-zone offset, a Message-ID, and several Received fields added by mail servers. The Date field describes the sender-side timestamp; each Received field records a different server handling event. These are related observations, not interchangeable proof of delivery or reading. Preserve the original values before normalizing them into a working chronology.

To inspect metadata in classic Outlook for Windows, open the message separately and choose File, Properties, then Internet headers. In new Outlook or Outlook on the web, look for View message details in the message menu. Interfaces vary by version and account. Our Outlook email evidence guide explains how to keep readable copies alongside source exports.

Why It Matters in Discovery

Authenticating Email Evidence

Under Federal Rule of Evidence 901, email must be authenticated before it is admitted. The proponent must produce "evidence sufficient to support a finding that the item is what the proponent claims it is."

Authentication may rely on a knowledgeable witness, distinctive characteristics, technical evidence, or an applicable self-authentication route. Rules 902(13) and 902(14) concern specified certified electronic evidence and have their own requirements. Metadata is evidence to evaluate, not an automatic exemption from foundation requirements.

Consistent headers and a verifiable DKIM signature can support an authenticity argument. Timestamp differences or signature failures can also have ordinary explanations, such as clock settings, forwarding, or later processing. Review the source and circumstances before drawing conclusions. See our guide to authenticating email evidence in court for the broader foundation questions.

Catching Altered or Fabricated Email

Email forgery is more common in litigation than most practitioners assume. It ranges from the crude (a screenshot that has been edited) to the sophisticated (a message sent from a cloned domain with a spoofed header).

Metadata is the primary forensic tool for detecting alteration. Common indicators:

Timestamp inconsistencies. If the "Date" header shows 9:00 AM Eastern and the receiving server's timestamp shows 2:00 PM UTC (which would be 9:00 AM Eastern), everything is consistent. If the "Date" shows 9:00 AM Eastern and the server received it at 9:47 AM UTC (4:47 AM Eastern), someone has some explaining to do.

Missing routing headers. Every legitimate email passes through at least one mail server and carries "Received" headers to show it. An email with no "Received" headers, or headers that show an impossible routing path, is suspicious.

DKIM signature failures. Forwarding, mailing-list changes, altered content, or unavailable historical verification information can complicate validation. Investigate the cause before alleging fabrication.

Message-ID format mismatches. Message-IDs follow format conventions specific to email client software. An email allegedly sent from Gmail with a Message-ID in the format used by Microsoft Exchange is worth examining carefully.

For small firm attorneys, this does not require becoming a forensic expert. It requires knowing when to engage one.

Establishing or Attacking the Timeline

In contract disputes, employment matters, and fraud cases, timing is often everything. Metadata provides a granular, contemporaneous record that witness testimony cannot replicate.

Consider a scenario: your client's counterparty claims they never received a critical email with an attached deadline notice. The "Date" field of the email says it was sent on Tuesday afternoon. The routing headers show it was received by the counterparty's mail server at 3:47 PM that same day. A delivery receipt shows the message reached the recipient's inbox. Those records may support server delivery, but they do not necessarily establish that the intended person opened or understood the notice.

Or the reverse: the other side produces an email they claim your client sent on March 15th, but the metadata shows the message was composed in a version of Outlook that was not released until April. That is a fabrication problem for them.

Read Receipts in Employment Cases

In employment litigation, a recurring dispute is whether an employee was notified of a policy, warned about performance issues, or informed of a decision. HR departments often send notification emails with read receipts enabled.

Read receipt records, when available, may help assess these disputes but rarely resolve them alone. When it does not exist (because read receipts were not enabled, or because the recipient declined to send one), that absence becomes part of the factual record. Attorneys on both sides need to know what was tracked and what was not.

What Gets Lost When You Handle Email Wrong

Metadata is fragile. Several common practices destroy it entirely, often without anyone realizing it until much later.

Forwarding. When an email is forwarded, the visible content is generally preserved, but the original metadata is not. The "Date" field of a forwarded message reflects the time of the forward, not the original send. The routing headers show only the forward's path. The original Message-ID may be embedded in the body, but it is not in the header where forensic analysis can easily reach it.

Printing to PDF. A typical printout preserves displayed fields but omits much of the original header and mailbox context. Including headers in a printout can help, but a PDF is still not a substitute for the source message.

Screenshots. Same problem, compounded by the possibility of image editing.

Copy-paste into Word. You've already guessed it.

Third-party exports without metadata preservation. Some email management tools and discovery platforms strip metadata during export. Know what your tool preserves before you rely on it.

The implication for litigation is direct: if you or your client have been handling email by forwarding, printing, or screenshotting, the metadata you need may no longer exist in the materials you have. The original source inbox may be the only place it is recoverable.

Collect from authorized source accounts using a method appropriate to the matter, rather than relying only on forwards. IMAP can retrieve messages, but it does not by itself preserve every server-side record, audit event, deleted item, or mailbox property.

The Producing Party's Obligations

Under FRCP 34(b)(2)(E), a producing party must produce ESI either in the form it is ordinarily maintained, or in a reasonably usable form. For email, "the form it is ordinarily maintained" includes metadata. Courts have held that producing email as static PDFs without metadata, when the requesting party has asked for native format or metadata, is non-compliant.

If you receive an ESI request and produce stripped PDFs, you may face a motion to compel, sanctions, or both. The safer practice: understand what format has been requested, understand what your collection method preserves, and confirm that what you produce matches the obligation.

For the requesting party, if you want metadata, ask for it explicitly in your discovery requests. Specify native format or specify that you expect full metadata fields including headers. Courts are more sympathetic to requesting parties who asked for metadata and did not get it than to those who accepted stripped PDFs without objecting.

Practical Steps for Small Firm Attorneys

Get the hold out before anything is forwarded or deleted. The litigation hold notice to your client should specifically address email, should instruct them not to forward emails as a substitute for preservation, and should tell them not to allow IT to run any export process that strips metadata. This sounds obvious. It is frequently ignored.

Collect from the source inbox. Use an authorized collection or export method that retains the fields and attachments you need. Verify what the method captures and what it omits. Document the account, operator, collection date, scope, and output. Follow a source-preservation workflow before preparing presentation copies.

Preserve source files first, convert to PDF later. EML or MSG exports can retain message information that a printout omits, but their contents depend on the source and export method. Convert to PDF for presentation and sharing, but retain the native files. If metadata questions arise later, you have the source.

Know when to get a forensic expert. If you suspect email fabrication, if metadata inconsistencies appear in your opponent's production, or if you are preparing to challenge the authenticity of email evidence, a digital forensics expert is worth the cost. They can perform analysis that you cannot do from an email client, and their testimony on metadata carries weight that lay testimony about "what the email says" does not.

Request metadata explicitly in discovery. If email communications are central to your case, do not accept a production that strips headers. Request native format, or specify in your production protocol that full metadata fields must be preserved and produced.

A Note on Email Chronologies and Metadata

When building an email chronology for court use, the timestamps displayed should come from the metadata, not from what your email client shows on screen. Email clients often reformat timestamps into local time, drop timezone information, or display only the "Date" header rather than the more precise server-received timestamp.

A court-ready chronology that uses wall-clock display times without specifying timezone is an invitation for dispute. A chronology that captures the full timestamp with timezone, drawn directly from the email header, is much harder to challenge.

ThreadLine helps organize messages from a connected mailbox into a readable chronology for review, PDF export, or secure sharing. Keep original messages and any required collection records separately. A timeline is a presentation aid, not a forensic acquisition, an authentication opinion, or a guarantee of compliance with a discovery request.

If you're preparing an email chronology for litigation and want the metadata done right, start with a free timeline at threadline.app. No credit card required.

The Summary

Email metadata is the technical record underneath what you see on screen: timestamps, routing paths, cryptographic signatures, client identifiers, read receipts. In litigation, it authenticates evidence, exposes fabrication, and establishes timelines that witness testimony cannot replicate.

Small firm attorneys do not need to become forensic analysts. They do need to preserve metadata from the start (by collecting from original inboxes, not from forwarded copies), produce it properly when required, request it when opposing counsel owes it to them, and know when the metadata questions in a case warrant expert help.

The attorneys who handle this well tend to be the ones who thought about it before the motion to compel, not during it.

FAQ

What is email metadata?

Email metadata is information describing a message, such as its sender, recipients, subject, timestamps, Message-ID, and routing headers. It helps explain the message context, but no single field proves who wrote or read it.

What is an email metadata example?

An email metadata example is a Date header showing a timestamp and time zone, a Message-ID identifying the message, and Received headers recording server handling. Compare these fields together because sender clocks, relays, and export methods can affect them.

How do I find email metadata in Outlook?

In classic Outlook for Windows, open a message in its own window and look under File, Properties, Internet headers. In new Outlook or Outlook on the web, look for View message details in the message menu. Menu labels vary; save the source message as well as any copied headers.

Related reading

• Outlook email evidence guide
• Email chain of custody
• Admissibility of email evidence
• Document landlord dispute emails

The screenshot above is a product example of the timeline view these articles describe: messages in order, source context preserved, and export or sharing controls available when the record is ready.