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)
Weekly Adoption Trend
Last updated: July 27, 2026 at 00:20 UTC
Data period: Monday, July 21, 2025 to Monday, July 27, 2026
0.4%
DMARCbis Adoption Rate
19
DMARCbis Reporters
4,496
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 | Jul 26, 2026 06:59 UTC |
| WEB.DE | 100.0% | Jul 27, 2024 10:38 UTC | Jul 26, 2026 06:59 UTC |
| mail.com | 100.0% | Jul 27, 2024 10:39 UTC | Jul 26, 2026 07:02 UTC |
| DmarcDkim.com | 91.3% | Jul 19, 2026 16:07 UTC | Jul 26, 2026 21:04 UTC |
| eccentric.dk | 11.3% | Jul 07, 2026 05:59 UTC | Jul 25, 2026 06:57 UTC |
| woodpower.pl | 71.4% | Jul 16, 2026 13:03 UTC | Jul 25, 2026 18:32 UTC |
| splidex.com | 30.0% | Jul 18, 2026 16:28 UTC | Jul 23, 2026 16:56 UTC |
| autopilot-business.com | 100.0% | Jul 14, 2026 09:26 UTC | Jul 22, 2026 13:09 UTC |
| tomlab.cz | 4.3% | Jul 23, 2026 08:49 UTC | Jul 23, 2026 08:49 UTC |
| asche.co | 10.0% | Jul 15, 2026 15:43 UTC | Jul 15, 2026 15:43 UTC |
| datenschutz-ist-voll-doof.de | 33.3% | Jul 16, 2026 02:39 UTC | Jul 16, 2026 02:39 UTC |
| migration.bertha-online.de | 33.3% | Jul 16, 2026 16:26 UTC | Jul 16, 2026 16:26 UTC |
| h9t.eu | 50.0% | Jul 23, 2026 13:14 UTC | Jul 23, 2026 13:14 UTC |
| mordjunior.com | 50.0% | Jul 13, 2026 20:13 UTC | Jul 13, 2026 20:13 UTC |
| 4eb.com | 50.0% | Jul 17, 2026 09:29 UTC | Jul 17, 2026 09:29 UTC |
| caseof.de | 50.0% | Jul 20, 2026 13:29 UTC | Jul 20, 2026 13:29 UTC |
| wanderzirkus.at | 100.0% | Jul 25, 2026 15:21 UTC | Jul 25, 2026 15:21 UTC |
| boldhaus.de | 100.0% | Jul 18, 2026 14:42 UTC | Jul 18, 2026 14:42 UTC |
| vr.org | 100.0% | Jul 15, 2026 17:49 UTC | Jul 15, 2026 17:49 UTC |
| Yahoo | 0.0% |
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=rejectwitht=y(formerpct=0) may be treated asp=quarantine -
A policy of
p=quarantinewitht=y(formerpct=0) may be treated asp=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.commust pass DMARC checks. -
Any forged email from a non-existent subdomain like
secure-login.company.comwill 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.
Check domain and follow the instructions to nail down your DMARC configuration.
No expert knowledge needed!