DKIM2 and DMARCbis: What Changed and How to Implement

Two separate standards are reshaping email authentication at the same time. DMARCbis, formalized as RFC 9989 in May 2026, brought the first Standards Track revision of DMARC. DKIM2 is a newer signing standard with open-source implementations available. Both matter for email administrators, but they are not the same thing and they do not require the same actions.

This guide covers what actually changed, what you need to do today, and what can wait.

What DMARCbis (RFC 9989) Changes in Practice

RFC 9989 is the first Standards Track version of DMARC. RFC 7489 was Informational. That distinction matters: Standards Track means the protocol is considered stable enough for production deployment across the internet.

Most of what changed in RFC 9989 happens on the receiver side. But a few changes affect what you publish in your DNS records.

The pct Tag Was Removed

RFC 9989 removed the pct tag. It was used to apply DMARC policy to only a percentage of messages, which was useful for gradual rollout. That behavior is now ignored.

If your DMARC record looks like this:

v=DMARC1; p=reject; pct=50; rua=mailto:dmarc@example.com

The pct=50 is now ignored. All mail will be subject to p=reject. If you intended to phase in your policy, you need a different approach: deploy p=none first, monitor aggregate reports, then move to p=quarantine and finally p=reject as you confirm legitimate mail is passing authentication.

Action item today: remove the pct: tag from your DMARC record. It has no effect and clutters your DNS.

Should You Use the np Tag?

RFC 9989 introduced the np (No Policy) tag for non-existent domains. It signals that a subdomain genuinely never sends mail. The intended use case: large organizations with many subdomains can set one policy at the parent level instead of publishing individual records.

Here is what an np record looks like:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; np=none; rua=mailto:dmarc@example.com"

Do NOT add np to your record unless three conditions are all true:
1. The domain genuinely never sends any email
2. You control the parent domain's DNSSEC signing
3. You have verified your entire DNSSEC chain with dig +sigchase or an equivalent tool

The reason for the caution: the np tag interacts with DNSSEC in an unreliable way. If DNSSEC validation fails at any point in the DNS lookup chain, receiver behavior becomes unpredictable. Some receivers treat the domain as p=none. Others reject the message because the np guarantee cannot be cryptographically confirmed. The result is inconsistent mail handling across different providers.

This is not a theoretical edge case. It is a known property of how np behaves when DNSSEC is present but broken somewhere in the chain. You will see it as sudden authentication failures at specific receivers with no clear pattern.

If you are already using np, check your aggregate reports for receiver-specific asymmetries. If you see certain providers consistently failing DMARC for a domain that passes everywhere else, that is the signature of np DNSSEC handling differences.

Policy Discovery Changes for Subdomains

RFC 9989 changes how receivers determine which DMARC policy applies to a subdomain in complex DNS hierarchies. The previous method used a simpler parent-domain lookup. RFC 9989 uses a DNS tree walk that can result in a different policy being found in some nested subdomain scenarios.

If you manage domains with complex subdomain structures and third-party senders, compare your aggregate reports before and after moving to RFC 9989-compliant receivers to confirm you are not seeing unexpected policy discovery results.

What DKIM2 Changes and How It Differs from DKIM1

DKIM2 is a proposed new version of the DKIM signing standard. It is not yet a finalized RFC, but open-source implementations exist and some receivers are beginning to support it.

The core differences from DKIM1 (RFC 6376):

| Property | DKIM1 (RFC 6376) | DKIM2 |
|---|---|---|
| Key algorithm | RSA (1024-bit minimum) | Ed25519 (mandatory) |
| Canonicalization | Simple or Relaxed | Relaxed only |
| Multi-key support | Single key | Key chain model |
| Status | Finalized RFC | Draft, open-source implementations available |

The most practical difference for email administrators is key size. Ed25519 public keys are roughly 4 times smaller than RSA-2048 keys. For domains that publish DKIM records via DNS TXT records, smaller records mean faster DNS lookups and less chance of hitting UDP packet size limits during validation.

DKIM2 does not change DMARC alignment. If you sign with DKIM2 and your signing domain aligns with your RFC 5321 From domain, DMARC passes the same way it does with DKIM1. The alignment modes (relaxed or simple) work identically.

Important: DKIM2 is not a replacement for DKIM1. Receivers must support both during the transition period. You do not need to migrate today.

How to Implement DMARCbis Changes Today

Here is what to do now, in order.

Step 1: Audit your DMARC records.
Run a DMARC record lookup for each domain you manage. Check for:

Any pct: tag - remove it

Any np: tag - do not add unless the three conditions above are met

Confirm your rua aggregate report endpoint is still reachable

Step 2: Review your aggregate reports for anomalies.
Look for receiver-specific inconsistencies. If certain providers are failing DMARC for a domain that passes everywhere else, that is a sign of np DNSSEC handling differences or policy discovery changes.

This is where a monitoring tool helps. DMARCFlow surfaces per-receiver authentication results in aggregate reports, making it straightforward to spot these asymmetries. When you change DMARC settings, you need to know what breaks before your users do. A sudden spike in authentication failures at one specific receiver after updating to RFC 9989-compliant receivers is a clear signal that something in your policy discovery or np handling has changed.

Step 3: Validate your DNSSEC chain.
If you run DNSSEC-signed domains and are considering the np tag, validate your chain first:

dig +sigchase _dmarc.example.com

Or use an online DNSSEC checker. If the chain fails at any point, the np tag behavior becomes unreliable.

Step 4: Plan to revisit DKIM2 when the RFC is closer to publication.
Watch the IETF DKIM2 draft status. Keep an eye on which receivers in your aggregate reports are validating DKIM signatures. When DKIM2-capable receivers start appearing, you will have a signal for when to begin testing.

Frequently Asked Questions

What is the difference between DKIM and DKIM2?

DKIM (RFC 6376) uses RSA signatures with a minimum 1024-bit key. DKIM2 proposes Ed25519 signatures, which are smaller and faster to validate. DKIM2 is not yet a finalized standard but has open-source implementations available.

Is DKIM2 ready for production use?

No. DKIM2 is not yet a finalized RFC. You can test it in staging environments using open-source implementations, but production DKIM2 signing should wait until the standard is further along and receiver support is broader.

What did RFC 9989 (DMARCbis) change about DMARC?

RFC 9989 formalized DMARC as a Standards Track protocol for the first time. Key changes: the np (No Policy) tag for non-existent domains, removal of the pct tag, and changes to how subdomain policy discovery works in complex DNS hierarchies.

Should I remove the pct tag from my DMARC record?

Yes. The pct tag is now ignored by RFC 9989-compliant receivers. Remove it from your DMARC record. All messages will now be subject to your full policy regardless of what pct used to specify.

Can I use the np tag on domains that never send email?

Only if your domain genuinely never sends email AND you have validated your complete DNSSEC chain is intact. If DNSSEC validation fails anywhere in the lookup chain, receiver behavior for np becomes unpredictable and mail may be handled inconsistently across different providers.

How does DKIM2 affect DMARC alignment?

It does not. DKIM2 signatures work with the same relaxed and simple alignment modes as DKIM1. If your DKIM2 signing domain aligns with your From domain, DMARC passes exactly as it did before.