DKIM2 and DMARCbis: Incoming Email Auth Standards

What is DKIM2?

DKIM2 is the proposed next version of DKIM (DomainKeys Identified Mail), the email authentication standard that lets senders sign outbound messages with a cryptographic key published in DNS. When a receiving mail server gets a signed message, it looks up the DKIM public key in DNS and verifies the signature. If the signature checks out, the message has not been altered in transit and the sending domain vouches for it.

The current DKIM standard (RFC 6376) has been in use since 2011. It works, but it has limits that the email community has been addressing in the draft DKIM2 specification.

The most significant changes DKIM2 introduces:

New cryptographic algorithm: DKIM2 specifies Ed25519 as the primary signing algorithm. Ed25519 keys are smaller than RSA keys and sign faster, which matters when you are processing millions of messages. An Ed25519 DKIM2 key is typically 32 bytes; an RSA DKIM key at equivalent security strength is 256 bytes or more. For high-volume senders, this size difference compounds across headers and log volumes.

Smaller DKIM records: Because Ed25519 keys are smaller, the DNS TXT record published for DKIM2 is shorter. This matters because DNS lookups have size limits and latency implications. Shorter records are faster to fetch and less likely to hit UDP fragmentation issues.

Simplified header fields: DKIM2 reduces the number of signed header fields and simplifies how they are processed. The current DKIM spec leaves some room for interpretation in how header canonicalization works. DKIM2 tightens that.

Multi-key workflows: DKIM2 includes a more structured approach to key rotation and multiple signing domains. Managing key rotation without service disruption is one of the harder operational problems in DKIM today. DKIM2 addresses this with explicit timing fields in the key record.

One important thing DKIM2 is not: it is not a replacement for DKIM that invalidates existing signatures. DKIM2 and DKIM (RFC 6376) can coexist. A DKIM2 signer can produce signatures that DKIM validators will simply skip. This means the transition can be gradual.

What DMARCbis actually changes

DMARCbis is the planned revision of DMARC (Domain-based Message Authentication, Reporting, and Conformance), originally specified in RFC 7489. RFC 7489 is the DMARC standard most email operators are running today. DMARCbis is not a ground-up rewrite. It is a targeted update that clarifies ambiguities, addresses known gaps, and incorporates lessons learned from a decade of DMARC deployment.

The original DMARC RFC was published in 2015. Since then, the community has identified several areas where the spec is vague or where real-world deployments have diverged. DMARCbis addresses some of those.

Here is what DMARCbis actually changes from RFC 7489:

Aggregate report format updates: RFC 7489 specifies the DMARC aggregate report format inXML. DMARCbis incorporates updates that align with RFC 9990 (DMARC Reporting Extensions), which introduced new record types and updated field definitions. If your DMARC parser is strict about schema compliance, DMARCbis alignment matters.

Policy application refinements: The original DMARC RFC has several areas where the policy application logic is described in prose rather than precise state machines. DMARCbis tries to remove that ambiguity. One specific area is how subdomains interact with the organizational domain policy. RFC 7489 defines an algorithm for finding the organizational domain, but edge cases exist that DMARCbis clarifies.

New np tag (non-published policy): DMARCbis introduces an np (none published) tag that some implementations have already shipped. This tag addresses a specific scenario: a domain that has no DMARC record at all. The np tag allows a receiver to distinguish between "this domain has explicitly published p=none" and "this domain has no DMARC record at all." This matters for reporting accuracy.

Reporting enhancements: DMARCbis incorporates and extends the RFC 9990 reporting extensions. The np tag and additional disposition fields are part of this.

Alignment mode clarification: DMARC allows two alignment modes: relaxed and strict. The difference matters for subdomain handling. DMARCbis clarifies how alignment is evaluated across forwarding scenarios, which has been a persistent source of confusion in troubleshooting.

What DMARCbis does not do: it does not change the fundamental DMARC mechanism of aligning SPF and DKIM results against the RFC 5321 From domain. That core logic remains. Your p=reject policy and your reporting address stay the same.

What does not change when the new standards arrive

If you are running DKIM today and you have a DMARC policy in place, the arriving standards do not require you to tear anything down and start over.

Your DKIM keys still work. Your DMARC policy still works. Mail that passes DKIM today still passes DKIM tomorrow under a DKIM2-aware receiver. The new standards add capabilities, they do not invalidate the old ones.

The email authentication stack has a deliberate backwards-compatibility design. DKIM2 signatures are processed by DKIM2-aware receivers and ignored by DKIM-only receivers. DMARCbis is a superset of RFC 7489 behavior, not a replacement.

If you are an email operator with a functioning DKIM setup and a published DMARC record, the practical impact of both standards arriving is:

Your DKIM keys remain valid indefinitely
Your DMARC policy continues to apply
You may over time want to add DKIM2 keys alongside your existing DKIM keys
Your DMARC reporting may gain additional fields as receivers implement DMARCbis

The risk of doing nothing is low. The opportunity cost of not preparing is higher.

Will my existing DKIM and DMARC setup still work?

Yes. Neither DKIM2 nor DMARCbis invalidates existing DKIM or DMARC configurations.

The more relevant question is whether you want to be early with DKIM2. For most operators, waiting until DKIM2 is broadly supported by major mailbox providers makes sense. Right now (mid-2026), DKIM2 is a draft standard and major receiver support is limited.

The practical timeline looks like this:

DKIM2: W3C or IETF draft stage, early open-source implementations available
DMARCbis: Working group stage, some providers already ship np tag support
Broad receiver adoption: Likely 12 to 24 months for meaningful coverage

This is not a rushed migration. You have time to understand what is changing and to plan your key management updates.

How to prepare your email authentication for the next generation

Here is what makes sense to do now, before either standard is mandatory:

Audit your current DKIM key management. If you are rotating DKIM keys manually or have not rotated them in years, DKIM2 is a good reason to get serious about automated key rotation. DKIM2 has better support for scheduled rotation built into the key record format.

Track DMARCbis adoption among your receivers. As mailbox providers implement DMARCbis support, your aggregate reports may include new fields. Check that your DMARC parsing pipeline handles unknown fields gracefully - a common failure mode when standards add new XML elements.

Monitor your aggregate reports for new fields. When receivers start sending DMARCbis-compliant reports, you may see previously empty fields populated. If your parser drops the entire report on unknown fields, you have a gap that DMARCbis will expose.

Test DKIM2 in a non-production domain first. If you run email infrastructure in-house, set up DKIM2 on a test domain and validate signing and verification. Several open-source DKIM libraries already have experimental DKIM2 support.

For teams managing multiple domains, the key operational challenge in the transition will be managing two parallel DKIM key sets without disrupting mail flow. The domains that get this wrong will see sudden DKIM alignment failures when a receiver starts requiring DKIM2 and an operator has not yet published a DKIM2 key. DMARCFlow monitors DKIM authentication status across your full domain portfolio and can alert when a domain's DKIM setup looks like it is missing DKIM2 coverage before a receiver transition creates a problem. That proactive coverage monitoring is the practical reason to track this now rather than after the transition is forced.

Frequently asked questions

Is DKIM2 backwards compatible with DKIM?

Yes. A DKIM2 signer can produce signatures that DKIM-only receivers will ignore rather than reject. The standards are designed to coexist during the transition period. You do not need to choose one or the other.

Will DMARCbis break my existing DMARC policy?

No. DMARCbis is a superset of RFC 7489 behavior. Your existing p=reject or p=quarantine policy continues to work exactly as it does today. Receivers implementing DMARCbis will apply the same policy logic, potentially with additional reporting fields.

Can I start using DKIM2 now?

You can sign mail with DKIM2 today if your mail sending software supports it. However, major mailbox providers will not verify DKIM2 signatures until they implement support, which is still limited in mid-2026. A DKIM2 signature on mail sent to a DKIM2-ignorant receiver adds overhead with no benefit. Test environments are the right place for DKIM2 right now.

How does DMARCFlow handle DKIM2 as a new standard?

DMARCFlow will track DKIM2 adoption as receiver support grows. The focus right now is monitoring DKIM pass/fail rates and alerting on authentication changes that affect deliverability. As DKIM2 becomes verifiable by major receivers, DMARCFlow will incorporate DKIM2 key tracking into the domain monitoring dashboard.

What happens to emails that fail DKIM2 but pass DKIM?

During the transition period, receivers that support DKIM2 will likely apply a fallback: if DKIM2 fails, check DKIM. If DKIM passes, the message still authenticates. This behavior is receiver-specific and not yet standardized. The email authentication ecosystem is still working through the transition logic.