DKIM2 and DMARCbis have landed, and Stalwart speaks them first | Stalwart

Skip to content Search CtrlK Cancel

Stalwart<br>Platform Mail Server<br>Collaboration<br>MTA<br>Anti-spam<br>Architecture<br>Integrations<br>Editions Enterprise<br>Community<br>Compare<br>Pricing<br>Evaluate<br>Solutions Managed e-mail<br>Migration<br>Documentation Get started<br>Configuration<br>Management<br>Development<br>FAQ<br>Linux / macOS<br>Windows<br>Docker<br>Company About<br>Blog<br>Contact<br>Legal

[email protected] GitHub<br>Twitter<br>Mastodon<br>Discord<br>Reddit<br>Matrix

DKIM2 and DMARCbis have landed, and Stalwart speaks them first

Jul 6, 2026 - 27 min read<br>Mauro D.<br>Project Maintainer

Email authentication has quietly held the internet’s mail together for two decades, and it has just taken its biggest step forward yet. Two efforts arrived at once. DKIM2 (currently at draft -04) reworks DKIM so that a signature is no longer a lonely statement about content but one link in a verifiable chain of custody that follows a message from author to final recipient: forwarding stops breaking signatures, replayed mail no longer verifies, and a bounce can prove it is genuine. DMARCbis (published in May 2026 as RFC 9989, RFC 9990, and RFC 9991) is the long-awaited successor to DMARC: it replaces the static Public Suffix List with a live DNS tree walk, retires the tags that never worked, and folds a decade of hard-won operational lessons back into the standard.

Both matter because email authentication is what keeps a phisher from putting your bank’s domain in the From: line, and until now the machinery that does it has been showing its age. This post walks through what each protocol changes and why it matters.

It is also an announcement. As of Stalwart v0.16.12, both DKIM2 and DMARCbis are fully implemented, and Stalwart is the first mail server to support them. Anyone curious can sign and verify DKIM2 messages, and run DMARCbis checks, directly from the browser at the mail-auth playground, no install required. More on that at the end; first, the protocols.

Meet DKIM2<br>Section titled “Meet DKIM2”

DKIM (DomainKeys Identified Mail, RFC 6376) does one deceptively simple thing: it lets a domain take responsibility for a message. The sending server hashes a chosen set of header fields and the body, signs the result with a private key, and staples the outcome to the message in a DKIM-Signature header. The matching public key lives in DNS at selector._domainkey.domain, so any receiver can fetch it, recompute the hashes, and confirm two things: the message really was authorised by that domain, and nothing covered by the signature changed along the way.

That is the whole promise. A valid signature means “this domain vouches for this content.” It says nothing about who the message was for, where it has been, or where it is going next. For nearly twenty years that was enough, and DKIM quietly became one of the load-bearing walls of email authentication.

On its own, a DKIM pass is just a true statement about some domain. DMARC is what turns it into a decision. DMARC ties authentication to the domain a human actually sees, the one in the From: header, through a rule called identifier alignment : a DKIM result only counts toward DMARC if the signing domain (d=) lines up with the From: domain. Pass alignment on either DKIM or SPF and the message clears DMARC; fail both and it meets the domain’s published policy, which can mean quarantine or outright rejection.

This is exactly why a broken DKIM signature is not a cosmetic problem. When DKIM breaks on a message from a domain publishing p=reject, and SPF cannot save it either, that message is gone. Which brings us to the reason DKIM2 exists: over two decades of real-world routing, DKIM1 signatures break far more often than anyone would like, and in a few cases they hold when we wish they wouldn’t.

Issues with DKIM1<br>Section titled “Issues with DKIM1”

None of what follows is a knock on the original design. These are the seams that two decades of deployment pulled apart, and they are the exact list DKIM2 sets out to close.

Anyone could be the recipient. A DKIM1 signature is bound to the content, not to a destination. Capture one legitimately signed message and you can replay it to millions of other addresses, unchanged, and every copy still verifies. The replay rides on the original signer’s good reputation, which is precisely what makes it valuable to abusers.

Forwarding breaks the signature, silently and ambiguously. The moment a mailing list tags a subject, a gateway rewrites a link, or a forwarder appends a footer, the signed hashes no longer match and the signature fails. Worse, a verifier cannot tell an innocent [list] prefix from wholesale replacement by an attacker. Both look identical: broken.

There was no record of the road travelled. DKIM1 leaves no trustworthy trace of the path a message took. The Received and Return-Path headers are unauthenticated and trivial to forge, so there is no chain of custody to reason about.

ARC was a patch that receivers struggle to...