RFC 9989 DMARC Support Study

RFC 9989 (formerly known as DMARCbis) was published on 20 May 2026, officially retiring the pct tag and the Public Suffix List. Nearly four months later, only one mail server claims support. We reviewed release notes and codebase updates to see how open-source projects and major mailbox providers are adopting the new rules.

No switch-over date

RFC 9989 keeps the v=DMARC1 tag, making new and legacy records appear identical to receivers.

The main change is the Public Suffix List lookup, which is replaced by the DNS tree walk to discover domain policies.

Legacy RFC 7489 receivers remain functional, since Section 6.3 explicitly says that unknown tags must be ignored.

In practice, adoption will happen gradually:

dmarcian, Ash Morin: "Support will roll out gradually and not simultaneously across providers."

Here is the implementation status as of 14 September 2026:

Two receivers have shipped support

Stalwart released v0.16.12 on 6 July 2026, announcing itself as the first mail server to support DMARCbis and DKIM2. Even so, its v0.16.22 release on 13 September had to resolve three DMARC conformance issues.

The Perl library Mail::DMARC added RFC 9989 support in version 1.20260612, implementing the tree walk, parsing t= and np= tags, and ignoring pct. SpamAssassin's DMARC plugin relies on this library. Fedora 43 and 44 ship this release, while Debian and Ubuntu still distribute older versions.

Two non-filtering Python utilities have also adopted the standard: checkdmarc 6.0.0 validates records via the tree walk, and parsedmarc 10.0.0 parses RFC 9990 aggregate reports.

OpenDMARC implemented the code, but hasn't released it

OpenDMARC is a widely packaged DMARC filter for Postfix setups, links into Exim, and comes pre-installed in Mail-in-a-Box and docker-mailserver.

Its develop branch added tree walk support on 21 June 2026, the t= tag on 22 June, and RFC 9990 report fields on 22 July. However, none of these changes have been released. The latest official release, 1.4.2, dates back to 20 December 2021 and is still distributed by Debian, Ubuntu, Fedora, EPEL, Alpine, and FreeBSD.

Even the unreleased develop branch defaults to legacy behavior: opendmarc.conf.sample documents DMARCbisWalkMode as defaulting to Auto (falling back to the Public Suffix List or RFC 7489 label walk) and defaults DMARCbisIgnorePct to false (meaning pct still gates policy enforcement).

Rspamd and other tools show no public progress

Rspamd, used by mailcow and Mailu, shows no RFC 9989 activity in its repository, issue tracker, or changelogs up to version 4.1.5. Its DMARC plugin still relies on the Public Suffix List for organizational domains and evaluates pct.

The Go-based mail servers maddy and mox also continue using the Public Suffix List and randomized pct evaluation. An issue requesting RFC 9989 support in mox (#442) has been open since 23 May.

In the Node.js ecosystem, mailauth 5.0.3 parses np, t, and psd tags, but its RFC 9989 test suite explicitly skips tree walk and tag evaluation tests as unimplemented features.

Gmail and Microsoft have made no public statements

Major mailbox providers—including Gmail, Microsoft 365, Yahoo, Apple, Fastmail, Proton, Naver, and Kakao—have issued no public statements regarding RFC 9989.

Documentation from Google and Microsoft still references the legacy standard. Microsoft Learn (updated 17 July 2026) states that RFC 7489 exhaustively describes DMARC TXT records, while Google's DMARC setup guide still links to RFC 7489. Furthermore, both providers' deployment guides still teach pct.

While documentation remains unchanged, active server evaluation behavior is unannounced.

Receivers using RFC 9990 aggregate reporting can signal their evaluation method via the discovery_method field (psl vs. treewalk).

How to structure records for both standards

Adding np= or t= tags will not break evaluation on legacy receivers.

Discrepancies only arise when the new tree walk and the old Public Suffix List identify different organizational domains. Appendix C.3 of RFC 9989 details the solution:

RFC 9989, Appendix C.3: "This issue is entirely avoided by the use of strict alignment and publishing explicit DMARC Policy Records for all Author Domains used in an organization's email."

First, publish an explicit _dmarc record for every domain used in your From: headers, INCLUDING subdomains.

Publishing explicit records ensures every receiver applies the same policy. Alignment can still differ between receivers until strict alignment is on.

Then, after receiving aggregate reports and confirming that all mail streams align completely, you can move on to configuring adkim=s; aspf=s.

Do you know which DMARC filter is your mail server running today?

References

1. RFC Editor — RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) (May 2026, IETF Standards Track)
2. RFC Editor — RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) (March 2015; obsoleted by RFC 9989)
3. RFC Editor — RFC 9990: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Aggregate Reporting (May 2026, IETF Standards Track)
4. dmarcian — DMARC RFC Guide: Updates You Need to Know (updated 14 August 2026)
5. Stalwart — DKIM2 and DMARCbis have landed, and Stalwart speaks them first
6. Stalwart — v0.16.12 release notes (6 July 2026) and v0.16.22 release notes (13 September 2026)
7. Mail::DMARC — CHANGELOG (1.20260612: "implement RFC 9989 DMARC")
8. Fedora Packages — perl-Mail-DMARC (read 14 September 2026)
9. checkdmarc — CHANGELOG (6.0.0)
10. parsedmarc — CHANGELOG (10.0.0)
11. OpenDMARC — rel-opendmarc-1-4-2 (20 December 2021) and opendmarc.conf.sample on develop (read 14 September 2026)
12. Rspamd — ChangeLog (to 4.1.5, 14 August 2026)
13. mox — Issue #442: RFC9989 (DMARCbis) changes (opened 23 May 2026)
14. mailauth — rfc9989-compliance-test.js (read 14 September 2026)
15. Microsoft Learn — Set up DMARC to validate email in Microsoft 365 (updated 17 July 2026)
16. Google Workspace Admin Help — Set up DMARC (read 14 September 2026)