DMARC has become one of the most important email authentication standards in the world. It helps organizations protect their domains from spoofing, phishing, and brand impersonation while providing visibility into who is sending email on their behalf. In May 2026, DMARC took a significant step forward. The original specification, published as RFC 7489, has been replaced by a new standards-track suite of documents commonly referred to as DMARCbis.

While most existing DMARC records will continue to work without modification, several changes are worth reviewing as organizations update their email authentication strategies.

From Informational RFC to Internet Standard

The original DMARC specification, RFC 7489, was published in 2015 as an informational document. It became widely adopted across the industry, but it was never part of the formal Internet Engineering Task Force (IETF) standards process. DMARCbis changes that.

The new standards include:

For most organizations, the biggest change is not how DMARC works day-to-day, but how policy discovery is performed behind the scenes.

Tags That Are Being Retired

Several tags from RFC 7489 have been moved to historic status and should be reviewed during future DMARC maintenance activities.

pct (Percentage)

The pct tag was intended to apply DMARC policies to only a percentage of messages. In practice, support varied between receivers, and many implementations treated values as either 0% or 100%.

ri (Report Interval)

The ri tag requested a preferred interval for aggregate reports. While many organizations included it in their records, most mailbox providers generated reports based on their own schedules regardless of the value supplied.

rf (Report Format)

The rf tag was used to request specific failure report formats. Support was inconsistent across receivers when considering the reports being sent.

Report Size Limits

RFC 7489 allowed senders to specify maximum report sizes within rua and ruf destinations.

Under DMARCbis, these modifiers are considered obsolete and should be removed when records are updated. Report generators are expected to ignore them.

Goodbye Public Suffix List, Hello DNS Tree Walk

Historically, DMARC relied on the Public Suffix List (PSL) to determine the Organizational Domain (aka: root, or apex domain).

The PSL is a community-maintained list that identifies boundaries between registries and domains. For example, it helps receivers understand that example.com and example.co.uk represent organizational domains, despite having different domain structures.

The challenge is that the PSL exists outside DNS, can vary between implementations, and needs to be manually maintained. DMARCbis replaces this dependency with a standardized DNS Tree Walk algorithm. Instead of consulting a third-party list, receivers discover DMARC policies by walking up the DNS hierarchy until they find a valid DMARC record.

The result is a more predictable, standards-based approach to policy discovery that reduces dependence on external data sources.

New Tags to Review

DMARCbis introduces several new tags designed to improve policy discovery, testing, and domain protection.

t (Testing)

The new testing flag provides a simpler way to indicate that a domain is evaluating a policy.

When present, receivers may apply a less restrictive policy while continuing to generate reports.

The t tag is intended to address many of the use cases that previously relied on pct. However, because DMARCbis is still relatively new, organizations should monitor receiver support and industry adoption before incorporating t=y into production deployment processes.

For now, it is worth understanding and testing, but there is no immediate need to replace existing workflows.

np (Non-Existent Subdomain Policy)

One of the most useful additions is the np tag.

This tag allows organizations to define a policy specifically for subdomains that do not exist in DNS.

This approach allows organizations to continue monitoring legitimate traffic while immediately rejecting spoofed messages sent from fake or non-existent subdomains.

For many organizations, np=reject may become one of the most valuable additions introduced by DMARCbis.

psd (Public Suffix Domain)

The psd tag helps identify whether a domain should be treated as a Public Suffix Domain.

Most commercial organizations are not operating public suffixes, so this value will typically be:

While not required for most deployments, organizations may wish to evaluate whether adding psd=n provides additional clarity for policy discovery under the new DNS Tree Walk model.

As support and operational guidance continue to mature, this tag may become a useful addition for organizations with complex domain structures.

Example Record Update

Legacy RFC 7489 Record

v=DMARC1; p=reject; pct=100; ri=86400; fo=1; rua=mailto:drua@example.net!10m; ruf=mailto:druf@example.net

Updated DMARCbis Record

v=DMARC1; p=reject; np=reject; psd=n; fo=1; rua=mailto:drua@example.net; ruf=mailto:druf@example.net

Changes Made

  1. Removed pct=100 because the tag is now historic.
  2. Removed ri=86400 because the tag is now historic.
  3. Removed the obsolete report size modifier (!10m).
  4. Added np=reject to protect non-existent subdomains.
  5. Added psd=n to support modern policy discovery.

What Should Your Organizations Do Next?

Most DMARC deployments do not require immediate changes. Existing records will continue to function, and DMARC implementations are designed to ignore tags they do not recognize.

That said, the publication of DMARCbis provides a good opportunity to review existing records and prepare for future updates.

Over the next several months, consider the following:

  • Review DMARC records for deprecated tags.
  • Remove pct, ri, and rf where present.
  • Remove report size modifiers from rua and ruf destinations.
  • Evaluate whether np=reject makes sense for your environment.
  • Monitor adoption of the new t testing flag before incorporating it into production workflows.
  • Consider whether psd=n would provide value for your domain structure.
  • Update DMARC documentation, deployment guides, and internal standards to align with DMARCbis.
  • Verify that DMARC reporting platforms, parsers, and validation tools support the new RFCs.

DMARCbis represents an evolution rather than a revolution.

The vast majority of existing DMARC deployments will continue to operate normally. However, the new standards provide a cleaner framework for policy discovery, modernize several areas of the protocol, and introduce useful new capabilities for organizations looking to strengthen their email authentication posture.

As you review your DMARC implementation, focus first on removing historic tags, understanding the new capabilities, and planning updates as part of your normal DNS maintenance cycle. The goal is not to rebuild a working DMARC deployment, but to ensure it remains aligned with the future direction of the standard.

Fun Fact:

You may notice the term DMARCbis used throughout industry discussions, documentation, conference presentations, and even this post. The suffix “-bis” is an IETF naming convention used during the development of a revised version of an existing standard. Derived from the Latin word meaning “again” or “a second time,” it indicates that a specification is being updated or replaced. While the official standards are now published as RFC 9989, RFC 9990, and RFC 9991, the name DMARCbis remains widely used as a convenient shorthand for the updated DMARC standards and the collection of changes they introduce.