After years of work inside the IETF DMARC working group, the long-anticipated update to the DMARC standard has been published. Three new documents, RFC 9989, RFC 9990, and RFC 9991, now formally replace the original RFC 7489 from 2015. Together, they are commonly referred to as DMARCbis.

The new specifications were published in May 2026 and moved DMARC from its earlier Informational status to a Proposed Standard on the IETF Standards Track. This gives DMARC a stronger and more formal place in the Internet standards stack.

I. What Each RFC Covers

Table comparing DMARC RFC 7489 features with new DMARCbis specifications across structure, status, discovery method, testing, and policy

The DMARC specification has been split into three focused documents rather than one large file:

  • RFC 9989: Defines the core DMARC protocol, including policy evaluation, identifier alignment, record processing, and DNS Tree Walk procedures.
  • RFC 9990: Defines DMARC aggregate reporting, also known as RUA reporting.
  • RFC 9991: Defines DMARC failure reporting, sometimes called forensic reporting, which can provide message-level detail about authentication failures when supported by receiving systems.

This split makes the standard easier to implement, maintain, and reference.

II. Your Existing DMARC Record Still Works

Stat card showing 100% backward compatibility for existing DMARC records with v=DMARC1 tag, no rebuild required

This is not a breaking change for domain owners.

DMARC records still begin with:

v=DMARC1

You do not need to rebuild your DMARC deployment or republish all records immediately. Existing records remain valid, but the update is a good reason to review your configuration, remove outdated behavior, and confirm your monitoring platform supports the new specifications.

III. Key Technical Changes

Table comparing new DMARC tags np, psd, t with historic deprecated tags pct, rf, ri and their purposes

Several changes matter for security teams, DNS administrators, and email authentication platforms.

DNS Tree Walk Replaces Public Suffix List Dependency

DMARCbis replaces reliance on the externally maintained Public Suffix List for organizational domain discovery with DNS Tree Walk procedures.

Receivers can now walk up the DNS hierarchy and look for relevant _dmarc records at each level. This reduces dependence on a third-party list and improves handling for complex domain structures, delegated domains, and public suffix domain operators.

New Tags: np, psd, and t

RFC 9989 updates the DMARC tag registry and introduces active support for:

  • np: policy for non-existent subdomains.
  • psd: public suffix domain handling.
  • t: testing flag, with t=y for testing and t=n for normal operation.

The np tag is especially important for organizations with large or complex domain footprints because it helps address spoofing attempts against non-existent subdomains.

Historic Tags: pct, rf, and ri

RFC 9989 marks several older tags as historic:

  • pct
  • rf
  • ri

The pct tag was originally intended to support partial policy rollout, but implementation was inconsistent across receivers. DMARCbis replaces this approach with clearer testing behavior through the t tag.

Organizations should review existing DMARC records for historic tags and plan cleanup where appropriate.

Clearer Guidance for Forwarding and Mailing Lists

Indirect mail flows, such as forwarding and mailing lists, remain difficult for DMARC because SPF or DKIM alignment can fail even when the message is legitimate.

DMARCbis gives more explicit guidance around these real-world scenarios. This matters because many production failures are not caused by malicious mail, but by legitimate mail passing through systems that alter routing, headers, or authentication context.

Better Defined Conformance

The updated specifications provide clearer definitions for DMARC participation and implementation behavior.

This should help reduce inconsistent interpretation across senders, receivers, and vendors. For organizations, it also makes it easier to ask whether a tool or provider is actually aligned with the current DMARC standard.

IV. RFC 9989: Core DMARC Protocol

RFC 9989 replaces RFC 7489 as the primary DMARC specification.

It defines the core protocol, including:

  • DMARC policy discovery.
  • Record processing.
  • Identifier alignment.
  • Policy evaluation.
  • DNS Tree Walk behavior.
  • Updated tag handling.
  • Conformance expectations.

Policy Discovery and Inheritance

RFC 9989 clarifies how DMARC policy discovery works across domain hierarchies.

This matters for organizations with many subdomains, delegated domains, or regional domains. Without clear policy discovery, teams may believe a domain is protected when a receiver does not discover or apply the expected policy.

Identifier Alignment

DMARC still depends on identifier alignment.

A message passes DMARC only when at least one of the following is true:

  • SPF passes and the SPF-authenticated domain aligns with the visible From domain.
  • DKIM passes and the DKIM signing domain aligns with the visible From domain.

SPF passing alone does not mean DMARC passes. DKIM passing alone does not mean DMARC passes. Alignment is what ties authentication back to the domain the recipient sees.

DNS Tree Walk

DNS Tree Walk is one of the most important operational changes in RFC 9989.

Instead of relying on the Public Suffix List to determine the organizational domain, receivers use DNS lookups through the domain hierarchy to discover the applicable DMARC policy.

This improves the standard’s ability to handle complex delegation models and public suffix domain scenarios.

V. RFC 9990: Aggregate Reporting

RFC 9990 defines the DMARC aggregate reporting format.

Aggregate reports give domain owners visibility into how their domain is being used across the email ecosystem. These reports typically include:

  • Source IP addresses.
  • Authentication results.
  • Alignment results.
  • Policy disposition.
  • Sending volume.
  • Reporting organization.

The dedicated aggregate reporting RFC should improve consistency across implementations and make reporting behavior easier for vendors and domain owners to interpret.

For security teams, aggregate reports remain one of the most useful ways to discover legitimate senders, identify unauthorized sources, and monitor DMARC enforcement progress.

VI. RFC 9991: Failure Reporting

RFC 9991 defines DMARC failure reporting as a dedicated Standards Track specification.

Failure reports can provide message-level detail about authentication failures, depending on receiver implementation and privacy controls.

These reports can be useful for troubleshooting and threat investigation, but they must be handled carefully. Failure reports may contain sensitive metadata and, depending on implementation, may include message headers or content elements. Organizations should consider privacy, volume, retention, and access controls before enabling or relying on failure reporting.

Not all receivers send failure reports. Security teams should treat them as a supplemental signal, not as a complete monitoring source.

VII. What Domain Owners Should Do

Domain owners do not need to panic-edit DNS records, but they should review their DMARC posture against the updated specifications.

A practical review should include:

  • Confirm that all DMARC records still use v=DMARC1.
  • Identify and plan cleanup for historic tags such as pct, rf, and ri.
  • Review whether the np tag is relevant for non-existent subdomain protection.
  • Confirm how subdomains are protected.
  • Check whether third-party senders are properly aligned.
  • Review aggregate report visibility.
  • Confirm that your DMARC platform supports RFC 9989, RFC 9990, and RFC 9991.
  • Ask vendors how they handle DNS Tree Walk policy discovery.
  • Review whether failure reporting is useful, appropriate, and privacy-safe for your organization.

The goal is not urgent migration. The goal is controlled alignment with the current DMARC standard.

VIII. What DMARC Platforms Need to Support

DMARCbis readiness is not only a domain owner issue. Platforms that manage or monitor DMARC must also adapt.

A DMARCbis-ready platform should support:

  • RFC 9989 core protocol behavior.
  • DNS Tree Walk based policy discovery.
  • Parsing and interpretation of np, psd, and t.
  • Recognition of historic tags such as pct, rf, and ri.
  • RFC 9990 aggregate report ingestion and analysis.
  • RFC 9991 failure report handling where enabled.
  • Clear distinction between authentication and alignment.
  • Visibility across subdomains and delegated domains.
  • Updated conformance behavior as receiver implementations evolve.

If a platform cannot interpret the updated tags or reporting behavior, security teams may lose visibility into important authentication changes.

IX. How Skysnag Protect Helps

Skysnag Protect helps organizations prepare for DMARCbis by supporting updated record analysis, reporting visibility, and policy monitoring as receiver implementations evolve.

The platform is designed to help organizations:

  • Monitor DMARC enforcement posture.
  • Track SPF and DKIM alignment.
  • Identify legitimate and unauthorized sending sources.
  • Maintain visibility across domains and subdomains.
  • Interpret aggregate report behavior.
  • Support updated DMARC tag handling.
  • Prepare for DNS Tree Walk based policy discovery.
  • Reduce manual complexity in ongoing DMARC management.

As the industry adopts RFC 9989, RFC 9990, and RFC 9991, organizations need tooling that keeps pace with the standard without forcing unnecessary operational disruption.

X. Migration and Conformance Considerations

DMARCbis is not a new protocol. It is a clearer, standards-track version of DMARC based on more than a decade of operational experience.

Organizations should treat the update as a structured review point:

Review Records

Check for historic tags, inconsistent subdomain policies, missing reporting addresses, and outdated assumptions about policy rollout.

Review Senders

Confirm that every legitimate sender can pass aligned SPF or aligned DKIM. This is especially important for marketing platforms, CRMs, ticketing systems, helpdesk tools, and other third-party services.

Review Reporting

Make sure aggregate reporting is being processed correctly and that any failure reporting is handled with proper privacy and access controls.

Review Vendors

Ask email security vendors whether they support RFC 9989, RFC 9990, and RFC 9991, including DNS Tree Walk policy discovery and updated tag interpretation.

XI. Final Words

DMARCbis is the same DMARC, but clearer, more formal, and better aligned with how email actually behaves.

The publication of RFC 9989, RFC 9990, and RFC 9991 is a good prompt for domain owners to review their records, validate sender alignment, check subdomain coverage, and confirm their tooling is ready for the current standard.

For organizations responsible for brand protection, phishing prevention, and email trust, the change is not disruptive. It is an opportunity to improve implementation quality.

XII. Key Takeaways

  • RFC 9989 replaces RFC 7489 as the core DMARC protocol specification.
  • RFC 9990 defines DMARC aggregate reporting.
  • RFC 9991 defines DMARC failure reporting.
  • Existing DMARC records still use v=DMARC1.
  • DNS Tree Walk replaces reliance on the Public Suffix List for policy discovery.
  • RFC 9989 introduces active support for np, psd, and t.
  • pct, rf, and ri are now historic tags.
  • DMARCbis improves clarity and implementation consistency rather than changing the basic purpose of DMARC.
  • Organizations should review records, subdomains, senders, reporting, and vendor readiness.

Ready to align your email authentication program with DMARCbis? Explore Skysnag Protect.