DKIM2: Making Every System That Handles an Email Sign for What It Did

The old problem in email security has never really been solved: how many systems an email passes through on its way from sender to recipient, and what each system actually did, is something existing protocols basically can't explain. The idea behind DKIM2 is direct—any system that has touched the email must sign for what it did.

The Blind Spot in Existing Email Authentication

DKIM was designed to verify the authenticity of the sending domain. It adds a signature to the email bound to the domain, so the recipient can determine whether the email came from the domain it claims and whether the content has been tampered with. But DKIM's signature covers the behavior on the "sender" side; once the email leaves the sending server, DKIM can't govern its journey.

The actual path of an email often passes through multiple layers of intermediate nodes such as forwarding services, mailing lists, security gateways, and archiving systems. These systems may rewrite headers, append tags, strip attachments, or even rewrite the body. Traditional DKIM either fails outright in the face of these subsequent modifications or barely passes thanks to lenient alignment policies. As a result, there is an unexplained gap between the authentication result the recipient receives and what the email actually went through.

DKIM (DomainKeys Identified Mail) is an email authentication mechanism standardized by the IETF. Its core is that the sending server signs specified header fields and the body by computing a hash and signing it with a private key bound to the domain, while the public key is published in a DNS TXT record, so the recipient verifies the signature by querying DNS. The signature typically includes tags such as d= (signing domain) and i= (identity), and allows the signed body length to be limited via the l= tag. This design naturally assumes that the content remains essentially unchanged after the email leaves the sending domain, so once an intermediate system rewrites the content (even just appending a footer), the signature becomes invalid. DKIM itself does not specify whether an email should be rejected or flagged; it only outputs a verification result, and the actual handling depends on the combination of policies such as DMARC and SPF.

The Core Claim of DKIM2

DKIM2 extends the signing subject from the "sending domain" to "every system that has handled the email." According to the project's introduction on Hacker News, its basic claim is: every system that handles an email signs for the operations it performs.

This means that each hop the email takes along the delivery chain adds another layer of verifiable operation records. A forwarding service signs "I forwarded this email," a gateway signs "what checks I performed and whether I modified the content," and the receiving end can verify layer by layer along these signatures instead of seeing only a final pass or fail.

This design turns the email's processing history into a traceable chain of credentials rather than a binary authentication conclusion.

Relationship with Existing Protocols

DKIM2 is not intended to overturn DKIM. Judging from its name and positioning, it is more like extending DKIM's signing mechanism to every hop of email transport, making "who did what" itself a verifiable object.

This is especially critical for mailing lists and forwarding scenarios. The invalidation of traditional DKIM signatures after forwarding has long been a problem plaguing email delivery, and various workarounds can only mitigate it. If every intermediate system signs for its own modifications, the recipient can distinguish "the original text was modified by a legitimate forwarding service" from "the content was maliciously tampered with," without having to choose one of the two.

In mailing list and forwarding scenarios, the invalidation problem of traditional DKIM is usually mitigated through several workarounds: first, ARC (Authenticated Received Chain), which allows intermediate nodes to append their own signature chain while preserving the original authentication results, so the recipient can see the authentication status of the email at each hop; second, rewriting the From domain (e.g., a mailing list replacing the sender address with the list address), trading the original identity for alignment passing; third, lenient alignment policies that accept signatures from subdomains or similar domains. The difference between DKIM2 and ARC is that ARC mainly protects the integrity of "authentication results" during forwarding, whereas DKIM2's signing object is "the operations performed by intermediate systems" themselves—with finer granularity, and with greater emphasis on accountability for processing behavior, not just on conveying authentication conclusions.

Practical Problems in Implementation

The idea is logically clear, but there are many hard nuts to crack in engineering.

First, deployment inertia. The email ecosystem demands extremely high compatibility, and any new signing mechanism must coexist with a large number of existing systems, so its penetration will not be fast. Second, the trust model for the signature chain needs to be clarified: who endorses the signatures of intermediate systems, and on what basis the recipient trusts the key of a particular hop—the answers to these questions determine whether DKIM2 becomes usable trust infrastructure or degenerates into yet another layer of forgeable markings. Third, privacy and storage costs: the signature at each hop increases the email's size and leaves traces of the processing path.

The discussion of this item on Hacker News currently has low engagement, indicating that it is still in an early stage of exposure and that the community has not yet formed sufficient practical feedback. This also means the above issues are more open-ended questions than settled conclusions.

The trust model for the email signature chain can be likened to the approach of certificate chains or Certificate Transparency: for the signatures of intermediate systems to be accepted by recipients, three problems must be solved—public key discovery, proof of key ownership, and revocation mechanisms. DNS is a ready-made public key distribution channel (DKIM itself relies on DNS), but the trustworthiness of DNS records is limited by the deployment rate of DNSSEC; another possibility is to introduce a trust anchor independent of the email protocol or a consortium whitelist, but this brings governance and admission issues. In addition, the longer the signature chain, the greater the verification cost and the larger the failure surface—an expired key or misconfiguration at any hop may cause the entire chain to fail verification, so a degradation strategy must be designed to clarify "how the recipient should handle an incomplete chain," otherwise it may repeat the mistake of DMARC's early days, when overly strict policies caused legitimate emails to be wrongly affected.

Directions Worth Watching

The evolution of email authentication has always been rather conservative, but precisely for that reason, any attempt to introduce "verifiable processing" into the email chain is worth noting. DKIM2's value proposition lies in advancing the granularity of authentication from "who sent it" to "who did what." If this direction works out, the improvement in email trustworthiness would be structural.

In the short term, a more realistic thing to watch is whether it can produce a runnable reference implementation in pain-point scenarios such as forwarding and mailing lists, and whether the community is willing to build consensus around the trust problem of intermediate system signatures.