Authenticating Email Evidence Gets Harder to Contest

Authenticating email evidence often presents a problem that most counsel underestimate if the opposing party refuses to agree to authenticity. The From address visible in a message carries no inherent authentication. Under Fed. R. Evid. 901, courts require the proponent to establish that the communication was sent by the person it appears to be from. But the message, on its own, is insufficient to do that. Two protocols are commonly understood to resolve this. Neither one does what counsel hearing the word “authentication” typically assumes.

SPF (the Sender Policy Framework) evaluates the RFC 5321 MAIL FROM address, which is the envelope sender used during SMTP negotiation.¹ That address is not displayed to the recipient. It does not correspond to the RFC 5322 From header that appears in the message and that a factfinder would examine. SPF tells you whether the submitting server was authorized to send on behalf of the evaluated domain. It says nothing about the From header that someone sees on a printout of the email.

DKIM (DomainKeys Identified Mail) signs specific headers and the message body at the point of origination.² A valid DKIM signature indicates that the signed portions of the message arrived intact at the receiving server. It is a meaningful artifact. It is also fragile. Mailing list software routinely appends footers to the message body and rewrites or adds headers. Either modification breaks the original DKIM signature. The list server then applies its own DKIM signature, authenticating the list operator’s domain rather than the original sender’s. By the time the message reaches the recipient, the only surviving cryptographic assertion belongs to a third party who is not the defendant.

When opposing counsel produces no copy of a message in discovery and their client denies authoring the message, you are left to find an expert who can use header consistency analysis and other forms of circumstantial evidence to establish authenticity. That testimony is not worthless, but it is contestable.

The admissibility of that expert testimony is governed by Fed. R. Evid. 702 in federal proceedings and its Texas counterpart, Tex. R. Evid. 702, in state court. Both follow the Daubert framework, under which the trial court acts as a gatekeeper and evaluates whether the expert’s methodology is scientifically valid and reliably applied.³ An expert’s ability to ground conclusions in verifiable, reproducible methodology matters, even in California, New York, and the other states that still use the older Frye standard.⁴ Circumstantial header analysis is harder to defend on that ground than cryptographic verification.

DKIM2,⁵ currently working through the IETF standards process with operational deployment by major providers expected shortly,⁶ changes what the expert can offer. The protocol requires every forwarder (including mailing list operators) to add its own signature covering the recipient address of the previous hop.⁷ When a forwarder modifies a message, it must record a recipe that describes exactly what was changed, in sufficient detail to reconstruct the prior state.⁸ The original sender’s signature is not replaced. It is preserved in the chain, verifiable against the sender’s published public key, and accompanied by a cryptographic record of every subsequent modification.

For an expert, the chain of custody provided by DKIM2 will be a different kind of instrument. The question shifts from whether the message is consistent with having originated from the defendant’s domain to whether the message carries a verifiable signature from the purported sender’s domain covering content that has not changed since signing. “Consistent with” and “cryptographically verified” are not the same testimony.

While DKIM2 does not dispense with the so-called “Hacker X” defense,⁹ a flat denial that the purported author actually authored the message does not invalidate the signature. The absence of a copy in the Sent folder does not invalidate the signature, either. The signature either validates against the public key published in the defendant’s DNS at the time of sending, or it does not.

DKIM2 is not actually deployed anywhere yet. But it is coming.

As DKIM2 gains traction, it will change what prudent counsel should be asking when retaining an email expert to help authenticate (or undermine the authentication of) an email: not just whether the expert understands email authentication generally, but whether the expert understands DKIM2 specifically. That means determining whether they can explain the chain-of-custody structure to a factfinder and identify gaps or anomalies in a purported DKIM2 chain that would undermine its evidentiary value. The same questions apply when cross-examining an expert retained by the other side.

Expert witnesses in forensic email authentication have always been necessary. DKIM2 does not change that. It changes what a competent expert needs to know.

Footnotes

1. Scott Kitterman, Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1, RFC 7208 § 2.2 (Apr. 2014). ↩︎
2. Murray Kucherawy et al., DomainKeys Identified Mail (DKIM) Signatures, RFC 6376 (Sep. 2011). ↩︎
3. Daubert v. Merrell Dow Pharmaceuticals, Inc., 509 U.S. 579 (1993). Texas adopted the Daubert standard in E.I. du Pont de Nemours & Co. v. Robinson, 923 S.W.2d 549 (Tex. 1995). ↩︎
4. Frye v. United States, 293 F. 1013 (D.C. Cir. 1923). ↩︎
5. Richard Clayton et al., DomainKeys Identified Mail Signatures v2 (DKIM2), draft-ietf-dkim-dkim2-spec-01 (Apr. 2026). ↩︎
6. Laura Atkins, DKIM2: What It Means for the Future of Email, https://www.wordtothewise.com/2026/04/dkim2-what-it-means-for-the-future-of-email/ (last visited May 12, 2026) (“There is working code and the expectation that it will be deployed in some mailbox providers in the next few months.”). ↩︎
7. DKIM2, supra note 5 at § 8.2. ↩︎
8. Id. at §  4. ↩︎
9. This is the somewhat infamous defense that, in this instance, concedes that the message originated from the purported author’s account, but that the account had been compromised by an unknown hacker (“Hacker X”) and that someone else sent unauthorized messages from the account. ↩︎