DMARCbis RFC 9989: Does It Change Your Email Setup?

After years of discussion, drafts, and industry feedback, the work on a DMARC revision, DMARCbis. is finally complete. In May 2026, the Internet Engineering Task Force (IETF) published RFC 9989, the new official specification for Domain-based Message Authentication, Reporting, and Conformance (DMARC). Alongside RFC 9990 and RFC 9991, it replaces the original DMARC specification (RFC 7489) that organizations have relied on since 2015.

What is DMARCbis?

Think of DMARCbis as a DMARC1.1, minor improvements and backward compatibility from lessons learned through actual use during the last decade. DMARCbis is an update to the DMARC standard that adds a few tags, deprecates a few tags and splits the DMARC protocol from the reporting requirements to allow for innovation on each without ratification of changes to all.

The actual DMARC protocol portion has changed a bit.

Deprecated Tags

DMARCbis removes a couple of tags that have become unnecessary and reduces the complexity of setting up a new DMARC policy.

  • pct – Allows the sender to allocate a portion of their email to testing a new policy (Quarantine or Reject). This is being replaced by a testing mode. Since it was confusing to adopters and often ignored by inbox providers.
  • rf – Specifies the format of RUF reports. There is only one value currently supported, so it became unnecessary.
  • ri – Corresponds to the aggregate reporting interval. It must be daily (86400 seconds) or longer. Most providers report daily, which is the maximum frequency allowed, so this tag is mostly useless.

New Tags

The system allows for greater simplicity in rolling out new policies and handles a couple of important issues not covered in the original DMARC specification.

  • np – Defines a policy for non-existent subdomains, separating this policy from actual email sending domains. For example, email.example.com might be your primary email domain, while mail.example.com might not exist. Both appear valid, but could open you to risk of being used in fraud and phishing if not locked down by policy.
  • psd – Support Public Suffix Domains and enables DNS-based organizational boundary discovery. It will be used primarily by registry operators and large domain administrators.
  • t – Sets your policy in testing mode. This simplifies staged rollout of new policies while maintaining reporting.

New Policy Handling

Previously, the DMARC standard required that Inbox Providers adhere to the DMARC policy of a standard, quarantining or rejecting email that failed to DMARC compliance tests. In practice, Inbox Providers made their own email acceptance decisions, largely ignoring the DMARC policy or using it only as a trust metric. DMARCbis now formally acknowledges this practice and simplifies the deployment of new policies in a testing mode rather than an odd percentage.

For example, the new policy split will allow setting up a series of subdomain DMARC records with different policies secure to your root domain and person-to-person email (reject policy), handle the complex compliance issues of mailing lists and forwarding systems (quarantine) on a subdomain and building trust in outbound marketing campaigns (reject) through another subdomain. Other sources like order fulfillment, accounting/billing, etc. may require different policies to maintain trust.

What does your organization need to do?

If you have already adopted DMARC and you’re comfortable with your settings: Do nothing. DMARCbis is fully backwards compatible and simply provides new configuration options.

If you have not adopted DMARC, you need to do so as soon as possible to ensure email deliverability. When you do, consider leveraging the new simpler standard. When rolling out a new DMARC policy, the t (testing) option will simplify the testing and while maintaining reporting.

Did DMARC really need an update?

Over the last decade, DMARC adoption has increased dramatically, offering Inbox Providers a clear method to differentiate senders that take ownership of their email from those that do not or potential spammers. In that time, there has been the opportunity to learn and improve the standard especially since email has evolved from a single sending domain utilizing internal email servers to multiple email sending subdomains and multiple 3rd-party providers while dealing with sending systems that often break DMARC like mailing lists and forwarding.

In addition, moving DMARC from an Informational document to a Proposed Standard also provides some benefits:

  • Clearer requirements
  • Better interoperability
  • More consistent implementations
  • Less ambiguity between mailbox providers

How can MxToolbox help?

Regardless of where you are on the journey to adopt DMARC, you will need a tool to interpret the DMARC reports and help with your email delivery. MxToolbox Delivery Center is fully compatible with the latest DMARC standards. Whether you use the initial DMARC standard or the new DMARCbis tags, MxToolbox has you covered. If you would like to adopt DMARC with a trusted partner, MxToolbox offers a Managed Services approach that handles all your email delivery issues. Our experience team can get your email delivery on the right path and allow you to focus on your business.