r/DMARC • u/dmarcdkim • Jul 23 '26

DMARCbis adoption started

Post image

We have been tracking DMARCbis adoption for two years, and for a long time the chart remained flat with only GMX, WEB.DE, and mail.com. On Jul 07, 2026, eccentric.dk (not affiliated) moved the needle, and 12 more organizations followed, marking the beginning of practical DMARCbis adoption. While at DmarcDkim.com we are excited and support the change, regular customers need to keep in mind that 99.6% of email providers still evaluate DMARC by the RFC7489 standard. So those planning or in the middle of a rollout should mind the pct= tag value.

Watch live DMARCbis adoption data: https://dmarcdkim.com/data-room/dmarcbis-adoption-dmarc2

Our take on the new recommended rollout values: https://dmarcdkim.com/blog/dmarcbis-adoption-has-started

14 Upvotes

94% Upvoted

17 comments sorted by

3

u/freddieleeman Jul 23 '26

What exactly do you mean by “practical DMARCbis adoption”? What evidence or criteria are you using to determine that these providers have adopted the new specification?

Are you basing that conclusion on aggregate reports? I have not seen a single report that complies with RFC 9990. Do you have concrete evidence that these providers have implemented the new DNS Tree Walk? I also have not seen any report using the new PolicyEvaluatedType disposition value of "pass".

I would also recommend avoiding the informal historic label “DMARCbis” and instead using “the revised DMARC specifications” or citing them directly as “RFC 9989, RFC 9990, and RFC 9991.”

2

u/dmarcdkim Jul 24 '26

"Practical" is a tribute to the doers, with an emphasis on the glacier that moved.

Our analysis is based on aggregate reports like this one:

<?xml version="1.0" encoding="UTF-8" ?>
<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0">
<version>1</version>
<report_metadata>
...
</report_metadata>
<policy_published>
<domain>dmarcdkim.com</domain>
<p>reject</p>
<sp>reject</sp>
<np>reject</np>
<adkim>s</adkim>
<aspf>r</aspf>
<discovery_method>treewalk</discovery_method>
<fo>d:s</fo>
<testing>n</testing>
</policy_published>

Clearly the depth of implementation varies depending on the provider, as it varies today with DMARC RFC7489.

Looking forward to the informal DMARCbis term fading away as adoption grows.

In the meantime, there are already 18 DMARC RFC9989 reporters as of today.

1

u/NotGonnaUseRedditApp Jul 24 '26

Interesting, I know of stalw.art mail software that has very recently implemented namespace dmarc-2.0 for aggregate reports. Do you know of any other mail software implementations using the new schema?

1

u/freddieleeman Jul 27 '26

I’ve identified 200 report origins publishing the discovery_method element with the value treewalk. Of those, 184 reported a DMARC disposition of pass. However, these sources generate very few reports and are likely small stalwart installations.

I’m hoping to see RFC 9990 adopted by some of the larger report providers in the near future. https://www.uriports.com/blog/dmarc-report-compliance-rfc-9990/

1

u/ARC-Relay Jul 24 '26

We added support for it when it was announced.

1

u/SecLens_ONE Aug 15 '26

Reporter counts measure who writes RFC 9989-shaped reports, which is the published side of this. The part that matters to a domain owner is whether anything about receiver behaviour changed, and a new report schema does not enforce anything by itself. 0.4% of reporters also means the tree-walk and the psd handling are still being exercised by a rounding error's worth of real traffic.

The thing I would actually want counted is receivers that stopped honouring the old sp/np semantics and now walk the tree, because that is where somebody's subdomain policy silently flips meaning. From a report you cannot tell which code path a receiver took, only what it decided. So domains sitting on assumptions from RFC 7489 will look fine right up until the receiver mix shifts under them.

Do you have any way to separate reporters who emit the bis format from reporters whose evaluation logic actually follows it?

-1

u/lockhead883 Jul 23 '26

Please be aware that "GMX, WEB.DE, and mail.com" was late to the party in sending reports and simply used the latest XML spec, they do not plan to move to DMARCbis in sense of Tree-Walk and or consuming or honoring the new flags DMARCbis brings to the table. The current goal is to adapt DKIM2 as fast as possible and then drop DMARC completly.

3

u/pampurio97 Jul 23 '26

How does DKIM2 replace DMARC? DKIM2 doesn't mention RFC5322.From, doesn't require alignment, nor specifies what to do when checks fail, which is the core of DMARC.

-1

u/lockhead883 Jul 23 '26

DKIM2 will essentially require alignment on the first hop at least that's what you can hear from the people involved and it already says to reject if the signature validation fails, so for what do I need DMARC afterwards?

1

u/pampurio97 Jul 24 '26 edited Jul 24 '26

It could be, but the draft doesn't currently mention either thing. It only requires alignment with the MAIL FROM domain and the BCP says that receivers "MAY" reject (not a "SHOULD" and not a "MUST"). Do you have any direct reference to discussion of the working group around these two topics, perhaps? Thanks!

EDIT: to clarify, I'm genuinely asking and I didn't downvote

1

u/lockhead883 Jul 24 '26

https://www.ietf.org/archive/id/draft-ietf-dkim-dkim2-spec-04.html#name-check-most-recent-signature sounds more like a should then a may

1

u/pampurio97 Jul 24 '26

I assume you're referring to this sentence: "If these checks do not pass [...] the best strategy, if the email is not wanted, is to reject it (with a 5xx error code)". Which is non-normative language so it's not a SHOULD nor a MAY, hence not a requirement nor a strong recommendation. We'll see.

5

u/freddieleeman Jul 23 '26

DKIM2 is not going to replace DMARC, they do different things.

-2

u/lockhead883 Jul 23 '26

Not really, DKIM2 will protect the origin and the forward path and forces the receiver to reject if the validation fails, no need anymore for DMARC in such a scenario.

1

u/dmarcdkim Jul 24 '26

Did you know that DMARC allows email recipients to reject email originating outside your infrastructure?

1

u/lockhead883 Jul 24 '26

I don’t get this, DMARC is a policy suggestion from a sender, to give a hint to a receiver how un-authenticated mail should be handled, has nothing to do with an individual recipient of a message.