What DKIM2 and ARC Retirement Mean for Your Email Authentication Setup

If you have set up DMARC, you are probably running DKIM. You may have heard of ARC. You probably have not heard of DKIM2 - or if you have, the details were thin.

That is about to change. DKIM2 is an RFC draft that will reshape how email authentication works. It is not imminent, but it is far enough along that understanding what it changes matters - especially if you manage email infrastructure or evaluate email vendors.

Here is what DKIM2 actually does, why ARC is being retired, and what you should start doing about it.

What DKIM does today

DKIM adds a cryptographic signature to email headers. Your email provider signs outgoing mail with a private key. Receiving servers look up the public key in DNS and verify the signature. Valid signature means the message was not altered in transit.

That part works. DKIM has been around since 2007 and it mostly does its job.

The problem is what happens when mail gets forwarded. Forwarding chains strip DKIM signatures. The forwarding server does not have the private key. The signature breaks. Authentication fails, even though the message was legitimate.

Forwarding is the reason ARC exists and the reason DKIM2 is being built.

What DKIM2 fixes

DKIM2 is designed to solve forwarding breakage and add a set of related improvements. The core changes:

Chain of custody signatures. DKIM2 lets forwarding servers add their own signature - a note that says "I forwarded this and it was clean when it came through." Receiving servers can verify the full chain, not just the original signature.

Message-Instance header with JSON recipes. A new header contains a JSON structure describing how the message was transformed at each hop: forwarded, had headers added, was list-handled. The receiving server replays those transformations against the original DKIM signature and verifies it held. This is the technical core of DKIM2.

mf= and rt= tags. Two new DKIM signature tags record the original sender (mf=, "mail from") and the forwarding route (rt=). A receiving server uses these to validate a message against the original signature, even when intermediate hops broke the original DKIM.

DSN handling. Delivery Status Notifications, bounces, read receipts, Auto-Replies, often failed DKIM in forwarding scenarios. DKIM2 specifies how these should be handled, which should reduce spurious authentication failures on automated messages.

Ed25519 support. DKIM2 allows Ed25519 keys alongside RSA. Ed25519 is faster to verify and produces shorter signatures. This is optional, RSA remains valid, but the option exists for providers that want it.

SHA-256 required. DKIM2 mandates SHA-256 for hashing. SHA-1 is removed. If you are generating DKIM keys today with RSA-SHA256, you are already aligned with this requirement.

Why ARC is being retired

ARC was introduced in 2016 as a workaround for exactly the forwarding problem. It created a chain of signatures, each intermediate server added its own ARC-Seal and ARC-Message-Signature headers. Receiving servers could see the authentication history even if the original DKIM broke.

It worked. ARC became standard practice for mailing lists, forwarded mail, and any infrastructure that forwards mail at scale.

The problem with ARC is that it is a band-aid on top of a system that does not natively support forwarding. DKIM2 fixes the underlying issue rather than patching around it. Maintaining two parallel systems for the same problem does not make sense.

ARC is not being removed because it failed. It is being retired because DKIM2 makes it unnecessary.

What this means for your aggregate reports today

Here is the part that matters right now: before DKIM2 arrives, your DMARC aggregate reports are the only way to see whether your DKIM signatures are surviving real-world forwarding or breaking silently.

When a forwarded message fails DKIM, it does not always fail DMARC, it depends on your policy and alignment. But you lose visibility either way. You do not know the message was forwarded, or whether it arrived correctly at the final destination. Your DKIM pass rate is only measuring straight-line delivery, not real-world delivery.

This is what aggregate report monitoring makes visible: DKIM pass rates broken down by sending domain and receiving infrastructure, so you can see where forwarding chains are breaking your signatures. That baseline is what makes the DKIM2 transition measurable instead of guessable. DMARCFlow aggregate reports give you that breakdown by domain, so you can establish the baseline before DKIM2 adoption starts and track progress as it rolls out.

What practitioners should do right now

DKIM2 is still a draft RFC. Widespread deployment is likely 2027 or later. There is no urgency to reconfigure anything today.

Use RSA-SHA256 for new DKIM keys. Already the standard and required under DKIM2. No extra step.

Keep your DKIM key length at 2048-bit minimum. DKIM2 does not change this requirement.

Keep ARC in place for now. If you run mailing list software or any forwarding infrastructure, continue using ARC. Removing it offers no benefit while DKIM2 receiving-side adoption is years away.

The honest timeline

DKIM2 is a draft RFC as of early 2026. The IETF process moves slowly. Major email providers will need to implement support before any of this matters in practice.

Expect a multi-year rollout. That is not a reason to ignore it, it is a reason to understand it before the next vendor procurement or infrastructure planning cycle.

What does not change

DKIM2 does not replace SPF or DMARC. It updates DKIM. SPF stays. DMARC stays.

DKIM2 does not happen all at once. It will roll out provider by provider.

Your DMARC policy, p=reject, p=quarantine, or p=none, continues to work exactly as it does today. DKIM2 is an addition to the authentication stack, not a replacement of it.