DMARCbis Adoption Data (DMARC2)

Track the adoption of DMARCbis across major email providers

DMARCbis is now an official IETF Standards Track standard, published in May 2026 as RFC 9989 (with RFC 9990 and RFC 9991), obsoleting RFC 7489. Monitor how email providers are adopting the new standard.

RFC 9989 (DMARCbis) RFC 9990 (Aggregate Reporting) RFC 9991 (Failure Reporting)

RFC9989 DMARCbis Reporters
RFC7489 DMARC Reporters
Weekly Adoption Trend

Last updated: August 16, 2026 at 04:20 UTC
Data period: Monday, August 11, 2025 to Sunday, August 16, 2026

As of August 16, 2026, there are 39 DMARCbis reporters globally. Current DMARCbis adoption is at 0.8%. Data updates daily.

0.8%

DMARCbis Adoption Rate

39

DMARCbis Reporters

4,598

Total DMARC Reporters

Adoption by top DMARC Reporters
DMARC Reporter DMARCbis Rate First DMARCbis Report Last DMARCbis Report
GMX 100.0% Jul 27, 2024 10:39 UTC Aug 16, 2026 03:52 UTC
WEB.DE 100.0% Jul 27, 2024 10:38 UTC Aug 16, 2026 03:52 UTC
mail.com 100.0% Jul 27, 2024 10:39 UTC Aug 16, 2026 03:52 UTC
DmarcDkim.com 94.6% Jul 19, 2026 16:07 UTC Aug 14, 2026 15:06 UTC
eccentric.dk 19.2% Jul 07, 2026 05:59 UTC Aug 15, 2026 06:02 UTC
splidex.com 58.8% Jul 18, 2026 16:28 UTC Aug 13, 2026 18:24 UTC
woodpower.pl 83.3% Jul 16, 2026 13:03 UTC Aug 07, 2026 18:29 UTC
vr.org 100.0% Jul 15, 2026 17:49 UTC Aug 11, 2026 23:34 UTC
asche.co 25.0% Jul 15, 2026 15:43 UTC Aug 06, 2026 12:16 UTC
buschmann-ge.de 75.0% Aug 01, 2026 07:20 UTC Aug 12, 2026 18:10 UTC
wanderzirkus.at 100.0% Jul 25, 2026 15:21 UTC Aug 15, 2026 14:51 UTC
oschly.me 100.0% Jul 29, 2026 14:07 UTC Aug 05, 2026 15:58 UTC
mldsc.de 100.0% Jul 28, 2026 11:41 UTC Aug 08, 2026 09:28 UTC
boldhaus.de 100.0% Jul 18, 2026 14:42 UTC Aug 12, 2026 17:02 UTC
tomlab.cz 8.3% Jul 23, 2026 08:49 UTC Aug 13, 2026 12:26 UTC
chmurka.email 50.0% Jul 29, 2026 11:14 UTC Jul 31, 2026 14:47 UTC
h9t.eu 66.7% Jul 23, 2026 13:14 UTC Aug 11, 2026 14:44 UTC
mordjunior.com 66.7% Jul 13, 2026 20:13 UTC Jul 28, 2026 07:01 UTC
chaosadresse.de 100.0% Aug 04, 2026 12:29 UTC Aug 14, 2026 16:42 UTC
autopilot-business.com 100.0% Jul 14, 2026 09:26 UTC Jul 22, 2026 13:09 UTC

DMARCbis in Practice: Understanding t, psd, and np

DMARCbis introduces new tags to help domain owners and email service providers refine how authentication policies are tested and enforced. Below is an explanation of how each of these affects email authentication, along with real-world usage scenarios.

t=y
Testing Mode

Setting t=y indicates that a domain is in "testing mode." This new tag replaces the pct= tag from the original DMARC specification, providing a clearer way to signal testing intent. When t=y is set, Mail Receivers are encouraged to treat the policy as less strict. Specifically:

  • A policy of p=reject with t=y (former pct=0) may be treated as p=quarantine
  • A policy of p=quarantine with t=y (former pct=0) may be treated as p=none

This approach allows domain owners to monitor the impact of stricter policies without immediately enforcing them, thereby reducing the risk of legitimate email being rejected during the testing phase.

Example:

v=DMARC1; p=reject; rua=mailto:[your-domain.com]@rua.dmarcdkim.io; t=y

psd=y
Public Suffix Domain Policy

The psd=y tag allows a Public Suffix Domain (PSD) like gov.uk or bank to publish a DMARC policy that applies to all domains beneath it, even if those subdomains haven't explicitly set DMARC records.

This is particularly helpful in environments where:

  • Security policy needs to be enforced at a registry or sector level.
  • Many subdomains are registered or operated independently (e.g., by municipalities or banks).
  • Centralized governance of domain security is required.

Example (published at the PSD level):

_dmarc.bank. IN TXT "v=DMARC1; p=quarantine; psd=y"

np=reject
Subdomain Policy for Non-Existent Domains

The np= tag specifies a DMARC policy for subdomains that do not exist (NXDOMAIN), but may still be spoofed.

This closes a loophole where attackers could forge emails from random.nonexistent.company.com to bypass the main DMARC policy of company.com

Example:

v=DMARC1; p=reject; np=reject; rua=mailto:[your-domain.com]@rua.dmarcdkim.io

With this configuration:

  • Legitimate mail from company.com must pass DMARC checks.
  • Any forged email from a non-existent subdomain like secure-login.company.com will be rejected.

Together, these new tags give domain owners more control over authentication behavior and improve protection across edge cases. Use t=y during rollout, psd=y for registry-level policy, and np= to block spoofing from unregistered subdomains.

Bulletproof emails with DMARC

Check domain and follow the instructions to nail down your DMARC configuration.
No expert knowledge needed!