DMARCbis Checker

DMARCbis: what changes for your domain

DMARCbis (sometimes called DMARC v2) is not a simple update. It is a complete overhaul of the DMARC protocol, split into three separate RFCs. Running a DMARCbis checker against your domain reveals exactly which adjustments are needed:

1. Core mechanism (draft-ietf-dmarc-dmarcbis): policy discovery, alignment, evaluation
2. Aggregate reporting (draft-ietf-dmarc-aggregate-reporting): XML format, schema, distribution
3. Failure reporting (draft-ietf-dmarc-failure-reporting): ARF reports, privacy, rate limiting

New tags

Removed tags

DNS tree walk

The most significant change in DMARCbis is the replacement of the Public Suffix List (PSL) with a native DNS traversal algorithm.

Why? The PSL is a community-maintained list managed by Mozilla volunteers. It suffers from update delays, inconsistencies between implementations and the absence of an IETF specification on which version to use. The DNS tree walk solves these issues by relying solely on actual DNS data.

How it works: the receiver queries _dmarc.<domain>, then walks up one label at a time. If a record contains psd=n, that is the organizational domain. If psd=y is found, the domain one level below is the organizational domain.

Who is adopting DMARCbis today?

As of March 2026, only GMX, mail.com and WEB.DE (United Internet group) send reports in the DMARCbis format. Widespread adoption is expected after the official RFC publication. DMARCbis records maintain backward compatibility: receivers that do not understand the new tags simply ignore them.

Get ready now

Even though migration is not urgent, preparing your domain now lets you:

• Identify deprecated tags to remove before they start generating warnings
• Add the np tag to protect non-existent subdomains
• Understand the tree walk and verify that your organizational domain is correctly determined
• Anticipate reporting changes in your DMARC analysis tools

DMARC vs DMARCbis: comparison table

This table summarizes the structural differences between the two protocol versions. If your record contains tags from the DMARC column that no longer exist in DMARCbis, the checker flags them automatically.

How does the DNS tree walk work?

The DNS tree walk is the core innovation of DMARCbis. It replaces Public Suffix List lookups with a hierarchical DNS traversal. Here is a detailed example to understand each step.

Example: an email received from user@sub.mail.captaindns.com

The receiver needs to find the applicable DMARC policy. With DMARCbis, it performs the following queries in order:

1. Query _dmarc.sub.mail.captaindns.com: the DNS server responds NXDOMAIN (no record found). The receiver moves up one label.
2. Query _dmarc.mail.captaindns.com: the DNS server responds NXDOMAIN. The receiver moves up again.
3. Query _dmarc.captaindns.com: a TXT record is found, e.g. v=DMARC1; p=reject; psd=n.

The psd=n tag indicates that captaindns.com is an organizational domain (not a public suffix). The tree walk stops. Result: organizational domain = captaindns.com, discovery method = tree walk.

What happens with psd=y? If _dmarc.captaindns.com contained psd=y, it would mean that captaindns.com is a public suffix (like .co.uk). In that case, the organizational domain would be mail.captaindns.com, the domain one level below the suffix.

Security limit: the tree walk performs a maximum of 8 DNS queries to prevent amplification. Beyond 8 levels without a result, discovery fails and the domain is treated as if it has no published DMARC policy.

Key advantage: unlike the PSL, which requires manual updates and varies across implementations, the tree walk relies on real-time DNS data. DNS administrators retain full control over their organizational boundary.

Why the np tag is essential

The np tag (non-existent domain policy) closes a security gap that DMARC v1 could not address: spoofing of non-existent subdomains.

The attack vector: an attacker sends an email from fake123.captaindns.com. This subdomain does not exist in your DNS zone. With DMARC v1, the receiver applies the sp policy (if present) or falls back to p. If your configuration is p=reject; sp=none (a common setup to allow legitimate subdomains), the attacker bypasses your protection.

The DMARCbis solution: the np=reject tag applies exclusively to subdomains for which DNS responds NXDOMAIN. You can maintain a flexible policy on your existing subdomains (sp=none or sp=quarantine for subdomains with legitimate email flows) while blocking subdomains invented by attackers.

Recommended configuration:

• If p=reject: add np=reject for maximum coverage
• If p=quarantine: add np=reject (fictitious subdomains deserve strict blocking)
• If p=none: add np=quarantine as a first step toward hardening

The np tag is particularly effective against CEO fraud attacks, where attackers invent credible subdomains such as secure-payment.captaindns.com or internal-hr.captaindns.com to deceive recipients.

DMARCbis adoption timeline

The transition to DMARCbis follows a gradual timeline driven by the IETF and major email providers.

DMARCbis records are backward compatible: you can add the new tags today without waiting for the official publication. Receivers that do not understand np, t, or psd silently ignore them.

Complementary tools

Useful resources

• RFC 7489 - DMARC
• draft-ietf-dmarc-dmarcbis
• RFC 9091 - PSD DMARC
• DMARCbis: every change and how to get ready

FAQ - Frequently asked questions

Q: What is DMARCbis?

A: DMARCbis is the new version of the DMARC protocol, being finalized at the IETF as a Proposed Standard. It replaces RFC 7489 (2015) and RFC 9091 (PSD DMARC). The three documents (core mechanism, aggregate reporting, failure reporting) have been in the RFC editor queue since 2025.

Q: What are the differences between DMARC and DMARCbis?

A: DMARCbis adds three new tags (np, t, psd), removes three tags (pct, rf, ri), replaces discovery via the Public Suffix List with a DNS tree walk algorithm, and restricts SPF validation to MAIL FROM only.

Q: Should I migrate to DMARCbis right away?

A: There is no rush. Current DMARC records continue to work because the version stays v=DMARC1. However, it is recommended to check your DMARCbis compatibility now to remove deprecated tags and add the new np and psd tags before widespread adoption begins.

Q: Is the pct tag really removed?

A: Yes. Operational experience showed that the pct tag was applied inconsistently by receivers. Only the values 0 and 100 were reliable. It is replaced by the binary t tag (t=y for testing mode, t=n for full enforcement).

Q: What is the DNS tree walk?

A: The DNS tree walk is the policy discovery algorithm in DMARCbis. Instead of consulting an external Public Suffix List, the receiver walks up the DNS hierarchy by querying _dmarc at each level until it finds a valid record. This eliminates the dependency on the PSL.

Q: Is the fo tag removed in DMARCbis?

A: No. The fo tag (failure reporting options) is retained in DMARCbis. Only the pct, rf and ri tags are removed.

Q: How do I know if my domain is ready for DMARCbis?

A: Run an analysis with our DMARCbis checker. The tool performs a full DNS tree walk, detects deprecated tags (pct, rf, ri), verifies the presence of the np tag, and displays the discovered organizational domain. The result shows a clear status: compliant, compatible, or non-compliant with DMARCbis.

Q: Does the DNS tree walk slow down email delivery?

A: No. The tree walk performs a maximum of 8 DNS queries, and receivers cache results based on the TTL of each record. In practice, for most domains, the tree walk resolves in 2 or 3 queries. The impact on delivery time is negligible.