Where can you track DMARCbis and DKIM2 adoption by mailbox providers?
The closest public provider-level tracker is the DMARCbis adoption data. It counts reporting organizations that emit DMARCbis-style aggregate reports and shows a rate for each listed reporter. It does not measure every mailbox provider, every deployed receiver, or support for each new DMARCbis rule. I cannot point to a comparable public DKIM2 receiver-adoption dashboard.
For Google, Yahoo, and Microsoft, I would record the status of each behavior as unverified until there is a provider statement or a reproducible receiver test. Absence from a reporting table is not evidence of no support. The useful places to watch are the public reporting dataset, the IETF Datatracker for DKIM2 specification changes, provider release notes, and aggregate reports from domains you control.
What the available tracker measures
The public dataset is useful because it offers named reporting organizations, first and last observed DMARCbis reports, a weekly trend, and each reporter's proportion of reports classified as DMARCbis. On its September 30, 2026 snapshot, it listed 143 DMARCbis reporters among 5,053 tracked DMARC reporters, or 2.8%. That is a share of observed reporters in this dataset. It is not a share of all inboxes, mailboxes, messages, or receiving servers.
I read that number as evidence of reporting-format adoption. A receiver that sends an RFC 9990-style aggregate report can still have a separate rollout schedule for RFC 9989 policy discovery or enforcement. A gateway can also validate messages without sending aggregate reports to a particular domain, so report absence leaves a gap.
|
|
|
|---|---|---|
GMX | 100% | Observed reports |
WEB.DE | 100% | Observed reports |
mail.com | 100% | Observed reports |
Google | Not listed | Unknown |
Yahoo | Not listed | Unknown |
Microsoft | Not listed | Unknown |
Public reporting signals in the September 30, 2026 snapshot.
The 100% entries mean all reports attributed to those reporters in the measured sample were classified as DMARCbis. Their first observed dates precede publication of the final RFCs, so the dates also show why a report-format label cannot be treated as proof of complete, final-standard behavior. I would ask which XML fields triggered the classification before using the rate as an implementation claim.
Do not equate a reporter with a provider rollout
A large provider can operate several receiving systems, send reports through different organizations, or expose a new format before every policy path uses it. A published percentage also depends on the tracker's sample and time window. Record the denominator and observation date next to every rate.
The same distinction applies to the word adoption. A domain publishing a DMARCbis tag is a domain-owner signal. A receiver parsing that tag is a parser signal. A receiver changing disposition because of it is enforcement evidence. Those are separate observations, even when they concern the same mailbox provider.
What to watch for at Google, Yahoo, and Microsoft
I use a feature matrix for the large receivers rather than one adoption percentage. Each row needs a public announcement or a dated test result. The reporting dataset above does not show a named rate for Google, Yahoo, or Microsoft in its displayed top-reporter table, and I did not find a reliable public rate for their DKIM2 verification. That leaves these cells unknown, not zero.
DMARCbis receiver checks
Look for an RFC 9990 report, then inspect how the receiver discovers and applies policy.
- Tree walk: Does policy discovery use the DNS tree walk for an appropriate subdomain?
- Testing: Does the receiver recognize t=y and apply the documented lower policy level?
- Nonexistent names: Does np= govern a name that does not exist in DNS?
DKIM2 receiver checks
Look for an explicit receiver declaration or a controlled signed message with a visible verification result.
- Parsing: Does the receiver recognize DKIM2-Signature and Message-Instance headers?
- Validation: Does it validate the signature chain under the current draft?
- Treatment: Does the result affect acceptance, filtering, or reporting?
A provider might support only part of either list. For example, it can parse a tag yet ignore it in local policy, or validate a DKIM2 signature without exposing the result in a message header. I mark those outcomes separately. I also note whether the result came from a consumer inbox, a business tenant, or a third-party gateway in front of one.
That last detail matters with Google Workspace and Microsoft 365 tenants. The visible mailbox brand does not always identify the first receiving gateway. MX records, message Received headers, and the reporter organization help establish which system actually made the decision. A test sent to one tenant is not a universal provider claim.
How to check DMARCbis behavior yourself
Start with passive evidence: receive aggregate reports for a domain you own, group them by reporting organization, and preserve the raw XML. The RFC 9990 namespace, the optional discovery_method field, and the reported testing or np policy give more precise clues than a dashboard badge. I keep the original XML because parser summaries often omit optional fields.
RFC 9990 report fields to inspectxml
<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0"> <version>1.0</version> <policy_published> <domain>example.com</domain> <np>reject</np> <testing>y</testing> <discovery_method>treewalk</discovery_method> </policy_published> </feedback>
In that example, the XML namespace is a report-format signal. The version element still reads 1.0, and the DNS DMARC record still begins with v=DMARC1. Neither a version element nor a new tag by itself proves the receiver enforced the intended policy. The discovery_method value is stronger evidence for tree-walk use when the reporter actually supplies it.
For active testing, use mailboxes and domains you control. Publish a small, isolated test policy, send known signed and unsigned messages, and compare delivery results with reports and the receiver's Authentication-Results. Test one behavior at a time. Keep the messages, DNS answers, timestamps, MX route, and report files so the result can be repeated.
- Tree walk: Place a distinct policy on an intermediate subdomain and check which policy domain the receiver reports.
- Testing mode: Compare p=reject with and without t=y using authorized failing test mail; check actual disposition.
- Nonexistent name: Test a From subdomain that returns NXDOMAIN and compare the outcome with np= absent.
- Evidence: Record per-provider results as confirmed, partial, or unverified, with a date and test route.
The testing tag is deliberately narrow. Under RFC 9989, t=y asks for one policy level less severe on DMARC failures: reject becomes quarantine, and quarantine becomes none. It is not the old percentage rollout. The np tag applies to nonexistent subdomains; simply seeing np in a published record does not show that any receiver honors it.
DNS examples for separate tests
Use domains you control and confirm all legitimate mail paths before changing a production policy. These separate records isolate testing mode from nonexistent-subdomain policy.
Example DMARC TXT recordsdns
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; t=y" _dmarc.example.net. IN TXT "v=DMARC1; p=none; np=reject"
When I check a domain's own published policy, the DMARC checker confirms its DNS record and basic syntax. It does not certify whether Google, Yahoo, or Microsoft has implemented every DMARCbis behavior. For a broader audit of a sending domain, the domain health checker also examines SPF and DKIM configuration.
How to track DKIM2 without a public dashboard
DKIM2 remains an Internet-Draft, so I track the current draft on the IETF Datatracker before interpreting any compatibility claim. The draft has changed its signature format and JSON-based message-change recipes. A pilot built against an older draft does not establish compatibility with the current one. I would log the exact draft revision in any test record.
IETF Datatracker page showing the DKIM2 draft status and revision.
The draft is a place to track the specification, not deployment. To establish receiver support, send a message carrying valid DKIM2 signatures through a controlled route and inspect the receiving system's validation output. Also test a deliberately invalid signature. A difference in handling is useful only when the receiver exposes an attributable result or its operator confirms the implementation.
The presence of a DKIM2-Signature header proves that a sender or intermediate system signed a message. It says nothing about the destination verifier. Likewise, a receiver accepting a message that contains DKIM2 does not prove it checked DKIM2: ordinary DKIM, SPF, or local policy can explain acceptance. I would avoid assigning an adoption percentage without a defined sample of messages, receivers, and draft versions.
|
|
|---|---|
Receiver | MX and mailbox route |
Draft | Exact revision |
Result | Valid and invalid test |
Visibility | Header or operator log |
Date | UTC observation date |
A compact evidence log for DKIM2 receiver tests.
This log also helps distinguish a software implementation from a provider rollout. A mail server project can announce DKIM2 verification support, yet a mailbox provider using that code still needs to enable, configure, and expose it. I would only label that provider confirmed after provider-specific evidence.
Where Suped fits in the workflow
Suped is our DMARC reporting and email authentication platform. Its practical role here is to monitor domains you control while receiver standards change: collect DMARC reports, identify sending sources, flag authentication issues, and track policy health. Suped's real-time alerts and issue steps help keep the ordinary SPF, DKIM, and DMARC rollout sound while new receiver behavior is tested.
I would use public adoption evidence for the industry question, then compare it with reports from my own domain. The DMARC monitoring workflow keeps those domain-specific reports and source changes visible. That is useful when a provider starts emitting a different report format or a policy change affects delivery, but it is not a universal DKIM2 adoption counter.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
Before changing t=y or np on a production domain, review the real traffic mix and confirm that legitimate senders authenticate and align. A receiver-specific experiment is easier to interpret when baseline failures are already understood. Suped's issue detection can identify sources that need configuration work; the feature matrix above remains the place to record receiver-specific DMARCbis and DKIM2 evidence.
For policy discovery questions across subdomains, keep a dated copy of each DNS record and the reporting interval you compare against. Reports arrive after mail is received, so an immediate dashboard change is not a sound pass or fail test. If a provider's evidence conflicts with your test, check the gateway route and raw report first.
Views from the trenches
Best practices
Record the reporter, sample size, date, and XML evidence before calling a DMARCbis rate adoption.
Test tree walk and policy tags on controlled domains, then preserve the full message and report.
Common pitfalls
A DMARCbis report does not prove that a receiver enforces every new policy rule for all inboxes.
Publishing an np or t tag measures domain-owner intent, not the receiver behavior that follows.
Expert tips
Treat DKIM2 draft revision as part of the test result because the verification rules are changing.
Separate signer, gateway, and final mailbox evidence when attributing DKIM2 support to a provider.
Marketer from Email Geeks says a comprehensive provider-by-provider adoption table had not surfaced, so receiver tests still need individual evidence.
2026-09-22 - Email Geeks
Marketer from Email Geeks says DMARCbis questions should target receiving gateways and mailbox providers, because sender service readiness is a different measure.
2026-09-22 - Email Geeks
Use evidence that matches the question
For DMARCbis, the public reporting dataset is the closest named-provider tracker available today. It establishes that some receivers emit the newer report format, with GMX, WEB.DE, and mail.com visible in its sample. It does not establish a Google, Yahoo, or Microsoft rate for t=y, np, or tree-walk enforcement. For DKIM2, the IETF Datatracker shows where the protocol stands; provider adoption still requires a statement or a controlled receiver test.
I would keep a short, dated matrix with separate columns for report format, tree walk, t=y, np, and DKIM2 verification. That makes new evidence useful without turning an unknown into a zero or a reporting percentage into a claim about every inbox.
