DMARCbis:
The next generation of email authentication

DMARCbis brings stronger reporting, clearer policies, and smarter boundary detection with the DNS Tree Walk.

Sendmarc supports DMARCbis, so you can adopt the updated standard without disruption. One exception is the psd tag, which we have not added support for since it applies specifically to Public Suffix Domains.

What is DMARCbis?


What is changing in DMARCbis: Key updates


Secure your domain for the future

DMARCbis FAQs

What is DMARCbis, and how is it different from the original DMARC standard?

DMARCbis is RFC 9989, the IETF’s 2026 update to DMARC. It replaces RFC 7489, moving DMARC from an Informational document to a Proposed Standard. The mechanism is unchanged: domain owners publish a policy, and receivers evaluate the message against it and act accordingly. What DMARCbis adds is precision: clearer definitions, formal conformance requirements, and updated tags.

Do companies need to change their DMARC records now for DMARCbis?

No immediate action is required. Existing records still work, and the deprecated pct, rf, and ri tags are ignored. Businesses should remove the deprecated tags at the next scheduled DNS update.

Who should pay attention to DMARCbis, and why?

DMARCbis affects anyone who publishes or evaluates a DMARC record, including domain owners, IT and email administrators, mailbox providers, and MSPs.

What is the DNS Tree Walk, and why does it matter?

The DNS Tree Walk is how DMARCbis locates a domain’s Organizational Domain, replacing the old Public Suffix List method. A receiver queries levels until it finds a published DMARC record.

What is the np tag, and how is it different from sp?

The sp tag sets policy for existing subdomains. The new np tag, added in RFC 9989, sets policy for subdomains that don’t exist in the DNS at all, closing a gap that let attackers send from fabricated subdomains.

Why was the pct tag removed, and how does testing work now?

RFC 9989 removes the pct tag, along with rf and ri, because pct was applied accurately only at 0 or 100 percent. It’s replaced by a simpler t (testing mode) tag. Staged rollout still works the same way: progress from p=none to p=quarantine to p=reject, using aggregate reports to confirm authentication at each stage.

What changes for receivers and reporting under DMARCbis?

RFC 9989 adds a conformance section defining what full participation in DMARC requires of domain owners and mail receivers, formalizing what was previously informal best practice. RFC 9990 and RFC 9991 update the aggregate and forensic report information.

How does DMARCbis improve email security?

DMARCbis doesn’t change what enforcement does. A domain at p=reject still causes receivers to reject unauthenticated email; it doesn’t stop attempts, and it doesn’t cover lookalike domains or compromised accounts. What DMARCbis improves is consistency: a standard Tree Walk method, the np tag for unused subdomains, and a conformance section teams can cite for audits and compliance reporting.

How does DMARCbis address mailing list challenges?

DMARCbis doesn’t solve the underlying issue: forwarding and mailing lists can still break DMARC alignment. RFC 9989 adds guidance instead, discouraging p=reject for domains whose users send to mailing lists.