DKIM2: What the New Email Signature Standard Really Changes (and What It Exposes)

A security gateway adds a warning banner. A mailing list changes the subject line. A forwarder sends a message to a different address. These are ordinary parts of email delivery, yet they can break authentication or make legitimate traffic difficult to distinguish from abuse.

DKIM2 proposes a way to authenticate the route and account for changes made by participating systems. That could address problems that DKIM alone cannot solve, including replay attacks and signatures broken by intermediaries. It also creates work for the operators of gateways, mailing lists, forwarding services, and sending domains.

DKIM2 is still under development. The working group specification is an Internet-Draft, and deployment practices and policy integration remain unsettled. Here is what the proposal means in practice and what you can prepare today.

What DKIM proves and what it leaves open

 
A successful DKIM check verifies that the signed content of the received message matches what the signing domain signed, subject to DKIM's canonicalization rules. It does not authenticate the SMTP recipient or bind delivery to a particular route. These are the boundaries of classic DKIM, which we will call DKIM1 here.

That leaves room for replay: someone can obtain a legitimately signed message and send copies to new recipients while retaining its valid signature. A receiver must distinguish that abuse from legitimate redistribution.

The opposite problem appears when a legitimate intermediary changes signed content. A footer or subject-line prefix can invalidate DKIM1. If forwarding also prevents SPF from passing with the required domain alignment, the message can fail DMARC.

DKIM2 aims to give receivers more evidence about these situations. It does not remove the need to judge whether a sender, intermediary, or declared modification is trustworthy.

How DKIM2 records a message's route

 
The proposal uses two main headers. Message-Instance records hashes of a message's headers and body at a stage in its journey. DKIM2-Signature authenticates those records and the preceding signature chain, alongside information about that hop's SMTP envelope.

When a participating intermediary changes a message, it records a new instance. A transformation recipe can describe how to reconstruct the earlier version. For example, a mailing list that adds a footer can supply enough information for a verifier to check the content before that footer was added.

This is a chain of participating systems, with exceptions and limits. A transparent relay may leave the chain unchanged when it changes neither the message nor the envelope. Some transformations can also use a null body recipe, which does not allow reconstructing the earlier body. Header changes cannot use a null recipe.

The main signature fields show what a verifier has to work with:

Key DKIM2-Signature tags

The i=, m=, t=, d= and s= tags are required in every signature. A signature also carries either mf= and rt=, or nd= in their place. The delegation test below shows both forms.

For the newest signature, the receiver compares the declared envelope with the live SMTP session. MAIL FROM must match; every actual RCPT TO recipient must be covered, although the signed list may contain additional recipients. The MAIL FROM domain's relationship to the signing domain uses relaxed matching rather than requiring identical domains.

Freshness rules are still being refined. In revision 06, the t= tag section (§8.4) says implementations may ignore signatures more than 14 days old, while the timestamp check (§11.3) says verifiers should return a failure for them. Treat exact expiry behavior as a draft detail to verify against the version you implement.

The DNS proposal retains the selector._domainkey lookup structure and compatible key records. Existing compatible keys may be reusable; keeping every current key is not a requirement. The protocol distinguishes message hashes, SHA-256 and SHA-512, from signature algorithms, RSA-SHA256 and Ed25519-SHA256.

What changes for email operators

 

1. Forwarding requires clear responsibility for domains

 
An address at an acquired company, an alumni domain, or an alias service may receive mail under one domain and forward it through another. DKIM2 needs a verifiable relationship between those stages.

The draft's “imaginary hop” mechanism addresses certain gaps through an additional signature or an explicit next-domain handoff. Depending on the route, the forwarding operator may need authority to sign for the recipient domain. A DNS-based key delegation can grant that authority without sharing an existing private key.

Domain owners will need to know who controls each delegation, why it exists, and when to revoke it. Access to an authentication dashboard does not grant signing authority.

2. Security gateways must account for their edits

 
A gateway that adds banners, rewrites links, or changes a subject becomes a reviser in a DKIM2 path. Its changes need to be represented in a way the downstream verifier can evaluate. Installing a signer at the origin will not make an unaware intermediary's edits verifiable.

Gateway edits already cost DKIM1 a lot. In one week of DMARC reports we processed, 72% to 96% of the sender-signed messages relayed through three gateway groups had no passing DKIM signature.

Even transport conversions matter. The DKIM2 demonstration site describes disabling Postfix's MIME output conversion because a later 8-bit-to-7-bit conversion invalidated signatures. Test the whole path, including changes made after signing.

This is why DKIM2 could help with gateway-related failures without automatically fixing every existing deployment. Both the processing order and intermediary support matter.

3. Bounce routing becomes part of authentication

 
The draft ties delivery-status notifications to the newest authenticated MAIL FROM. If the check of the newest signature fails, no notification may be generated for that message at all (§10.1). The recommended handling for unwanted mail is to reject it with a 5xx code during the SMTP session, so nothing is ever sent to a forged return address.

That is a proposed defense against backscatter. It does not establish that providers will send more delayed bounces, or guarantee safe return routing across every legacy path.

4. Sender flags create delivery tradeoffs

 
Flags such as donotmodify and donotexplode restrict modification and redistribution. They can be useful when a message must not be altered or expanded to additional recipients.

The tradeoff is delivery. Strict restrictions can conflict with a recipient's legitimate gateway or forwarding arrangement. The best-practices draft recommends donotmodify when an unacceptable change is worse than losing delivery. Apply that test to each message stream rather than enabling restrictive flags for every password reset, invoice, or alert.

5. Recipes need a privacy review

 
Reconstructing earlier content may require carrying text that an intermediary removed. A gateway could redact sensitive information from the visible body while preserving it inside a recipe.

A null body recipe can avoid carrying reconstructable earlier content, but limits what downstream systems can independently verify. An individual deployment-profile proposal discusses these privacy concerns. It is a design discussion, not a finding that a particular deployment complies with privacy law.

Ask the gateway and list vendors what their recipes retain after redaction, malware removal, or attachment stripping. Test the resulting message headers as well as the visible message.

Where DMARC, ARC, and reporting fit

 
The current DMARC specification evaluates SPF and DKIM1 with domain alignment. A DKIM2 pass does not, by itself, become a DMARC pass under that specification.

There is a concrete integration proposal: draft-chuang-dkim2-sender-policy describes using DKIM2 within DMARC policy and discusses reporting. It is an individual draft, not an approved extension. Do not treat its proposed DNS tags as production configuration guidance.

Reporting is a separate dependency. The base schema in RFC 9990 does not define dedicated DKIM2 results or chain details, though it permits extensions. Useful DKIM2 monitoring will require receivers to expose results and tools to support the chosen format. Ordinary aggregate reports should not be assumed to contain that evidence today.

The proposal to move ARC to Historic status also discusses ARC's future. That proposal is not a completed retirement. Existing deployments still need to work with the authentication mechanisms their providers support.

Keep these three questions separate: can this receiver verify DKIM2, does its policy use that result, and can your monitoring system obtain it? Support for one does not establish the others.

Reading results during the transition

 
The DKIM2 Authentication-Results proposal defines per-message results including pass, fail, none, permerror, and temperror. These are header-level results, not a ready-made aggregate-report schema.

The examples below assume a DKIM2-capable receiver. Use results generated by a receiver you trust, its logs, or a controlled test verifier. An arbitrary incoming Authentication-Results header is not reliable evidence.

How to read DKIM1 and DKIM2 results

These are diagnostic examples, not a complete matrix. No DKIM2 result is different from dkim2=none: an unaware receiver may not evaluate the protocol at all. Where several DKIM1 signatures exist, inspect them individually and identify which, if any, align with the From domain.

A DKIM2 pass can coexist with declared modifications. It does not establish that those changes were harmless, that the message is wanted, or that it reached the inbox.

What happened when we tried it

 
On October 5, 2026, we ran a small version of the pilot this article recommends. We signed test messages for glocksoft.com, one of our own domains, and sent them to the reflector addresses on the public DKIM2 demo. Each address makes a defined change, adds its own DKIM2 signature when it can verify the incoming one, and sends the result back to the envelope sender. We sent ten plain-text messages, one to every reflector address except reflector-delayedbounce.

Setup

 
We signed with Steve Atkins' Go library, which implements revision 06. One 2048-bit RSA key, published as an ordinary v=DKIM1 record under a single selector, produced both DKIM1 and DKIM2 signatures. The DNS point above held up: nothing about the key record had to change.

Each DKIM2 signature carried the real SMTP envelope: our sending address in mf= and the reflector address in rt=. The message then had to go out with exactly that MAIL FROM and RCPT TO, so we delivered it straight to the demo's mail server. A relay that rewrites the envelope sender would have failed the envelope check before anyone looked at the content.

Results

 
The demo verifies incoming mail with a separate implementation, written in Perl. It reported dkim2=pass for our signature on all six messages it reflected, so the two implementations agreed. Then we verified the replies ourselves:

The subject and footer rows are the Fail / Pass case from the table above. Our DKIM1 signature broke, and the DKIM2 chain verified. The demo recorded each change in a new Message-Instance header with a recipe; the verifier used it to rebuild the original subject and body, and our first signature verified against the rebuilt version.

The redacted row is the null body recipe tradeoff from the privacy section, seen from the verifier's side: we could check the demo's signature, and nothing earlier. A receiver in that position has to decide whether it trusts the intermediary. The damage row is an edit made after signing and not declared. It failed, which is the point.

Our own mailbox server doesn't verify DKIM2, so it only saw DKIM1. Its spam filter gave the unchanged reply credit for a valid author signature and gave every modified reply a penalty for "No valid author signature". That's the unaware receiver from the section above, on a real server.

Delegation and the imaginary hop

 
Two more addresses exercise the forwarding and delegation ideas. We published one CNAME, dkim2test._domainkey.glocksoft.com, pointing at a key the demo controls. No private key changed hands. The demo then sent us a new message from an address at glocksoft.com with two DKIM2 signatures: i=1 as glocksoft.com with the delegated key, and i=2 as dkim2.com. Both verified. The demo also added a DKIM1 signature for glocksoft.com with the same delegated key; it verified too, and it aligned with the From domain.

In the second variant, i=1 carried nd=dkim2.com instead of envelope fields: the explicit next-domain handoff of the imaginary hop. nd= matched the d= of the next signature, and the chain verified the same way.

What didn't work the first time

 
The step on capturing receiver-side evidence says to save test messages. When we re-verified the saved replies, every one failed DKIM2. Our mailbox server runs Exim, which adds Envelope-to and Delivery-date header fields at local delivery. DKIM2 hashes every header field except those on a short list in the draft, and these two aren't on it. With them removed, every reply matched what the demo describes for that address.

A receiver that verifies during the SMTP session won't see those fields. Anyone who re-checks stored mail will, so strip them, or verify before delivery, when you collect evidence. The same rule applies in transit: an intermediary that adds an ordinary header field without taking part in DKIM2 breaks the chain. Fields whose names start with X- are excluded.

The demo had a bounce-routing bug of its own. Its DSN address signs the notification with an empty envelope sender, mf=<>, as the draft expects for bounces, but delivered it with MAIL FROM reflector-bounces@dkim2.com. The signature itself verifies. Checked against the live session, it's a permanent error. It's a small bug in a demo, but bounce paths need the same testing as every other route.

What the test doesn't show

 
A demo server isn't a gateway or a mailing list. It didn't rewrite links, re-encode MIME parts, strip attachments, or expand to multiple recipients, and all our messages were plain text. It also says nothing about policy: no receiver used the DKIM2 result in a DMARC decision. What it shows is that the mechanism works between two independent implementations on a simple route.

To repeat the test with your own domain, use the tool we built for it: dkim2test on GitHub. It creates a key and prints the DNS record to publish, checks that the record is live, and sends the test messages. The reflectors reply to your own mailbox; save a reply with its full headers, and the tool verifies it, including the delivery header fields that tripped us up. You'll need a mailbox at the domain and a host that can send mail on port 25, which many cloud providers block.

Five useful steps to take now

 

Inventory senders, selectors, and delegations

 
Record every ESP, CRM, helpdesk, mailing list, and internal application that sends for your domain. Identify the configuration owner and any delegated keys. Use DMARC reports as evidence of observed traffic, then reconcile them with your own service inventory.

Map forwarding and modification paths

 
Include aliases, acquired domains, security gateways, and list expansion. DKIM1 pass with SPF failure can help identify forwarding candidates; it does not prove the route by itself. Check message headers and logs before assigning a cause.

Ask vendors specific implementation questions

 
Ask which draft version they implement, whether they sign, revise, or verify, and where they expose failures. Check support for delegations, redaction recipes, and changes made after signing. A general promise of “DKIM2 support” is not enough to plan a pilot.

Choose a small, controlled pilot

 
Use test recipients and a representative route. Exercise an unchanged message, a banner or link rewrite, forwarding, and list expansion. Check both successful and deliberately broken cases. Keep working DKIM1, SPF, and DMARC configurations in place while evaluating the additional mechanism.

Capture receiver-side evidence

 
Save test messages, trusted authentication results, SMTP outcomes, and relevant logs. Compare what was sent with what the final receiver checked. Verify how restrictive flags and privacy-sensitive changes behave before extending the pilot.

DMARKOFF can support today's baseline by organizing DMARC reports around sending sources, SPF and DKIM results, and selectors. That helps domain owners find routes worth investigating. DKIM2 chain diagnostics will need a supported source of DKIM2-specific data; they cannot be inferred from existing DKIM1 results alone.

Use DMARKOFF to establish your current authentication baseline before piloting DKIM2.
 
Secure Your Brand
 

What to expect next

 
Interoperability work is already visible in implementations and test services. That gives operators a practical way to evaluate the proposal, but it does not establish a schedule for widespread mailbox-provider adoption.

The immediate opportunity is to learn where your mail is forwarded, modified, and signed - and who owns each stage. That knowledge improves current troubleshooting and provides the starting point for a DKIM2 pilot.

FAQ