In May 2026, the IETF published RFC 9989 as the new Proposed Standard for DMARC. It replaces RFC 7489 and RFC 9091 and formalizes important changes to policy discovery, testing, subdomain handling and reporting. This does not mean every organization must immediately rewrite its DMARC record. It does mean that security teams, DMARC platforms and technical documentation should stop treating RFC 7489 as the current specification.
Why RFC 9989 matters
RFC 7489 introduced DMARC in 2015 as an Informational RFC. RFC 9989 moves the base protocol onto the IETF Standards Track as a Proposed Standard and incorporates operational experience from more than a decade of deployment.
The new specification also replaces RFC 9091 and changes how organizational domains and policies are discovered through the DNS tree. The practical outcome is a clearer current baseline for implementers, domain owners and assessment tools.
The pct tag has been removed
RFC 7489 allowed a pct value between 0 and 100 to request that enforcement apply to only a percentage of failing messages. In practice, mailbox providers did not apply intermediate values consistently.
RFC 9989 therefore removes pct. Existing records containing pct may still be interpreted by older implementations, but pct is no longer part of the current DMARC base specification. Organizations should not design new rollout plans around percentage-based receiver behavior.
The new t tag signals testing mode
RFC 9989 introduces t as a testing signal for quarantine or reject policies. A value of t=y requests that the receiver apply handling one level below the published policy while the policy is being tested.
The t tag replaces part of the former pct functionality, but it is not a percentage control. A controlled rollout still depends on sender discovery, alignment remediation, monitoring and deliberate policy decisions.
Support will not appear everywhere at the same time. An older receiver that does not recognize t is expected to ignore it and may therefore apply the published p policy without the requested one-level reduction. Organizations should validate receiver and platform support before relying on t=y as a production rollout control.
Policies for existing and non-existent subdomains
The specification adds np to the current base protocol for policy on non-existent subdomains. The existing sp tag continues to describe policy for existing subdomains when it differs from the organizational-domain policy.
If np is absent, non-existent subdomains inherit sp when it is present, or otherwise p. This makes np most useful when an organization deliberately wants stricter treatment for names that do not exist. For example, p=quarantine; sp=quarantine; np=reject keeps existing domains at quarantine while requesting reject for spoofed mail using non-existent subdomains.
The extensible DMARC record format allows this tag to be introduced safely: older receivers that do not support np ignore it and continue to use the policy behavior they understand through sp or p.
- sp: policy for existing subdomains.
- np: policy for non-existent subdomains, with fallback to sp and then p when it is absent.
Policy discovery now uses a DNS tree walk
RFC 9989 replaces the Public Suffix List approach described in RFC 7489 with a bounded DNS tree walk for finding the applicable policy and organizational domain. The same mechanism incorporates PSD policy discovery and redefines the earlier experimental approach from RFC 9091.
The psd tag helps the tree walk identify domain boundaries. A value of psd=y identifies a Public Suffix Domain, psd=n explicitly identifies a non-public-suffix domain as an organizational boundary, and psd=u is the default unknown state. Most ordinary organizational domains do not need to publish psd, although psd=n can be relevant in complex or decentralized DNS structures.
- psd=y: the record is published by a Public Suffix Operator for a Public Suffix Domain.
- psd=n: the domain explicitly forms the organizational boundary for itself and its subdomains.
- psd=u: the default; the tree walk determines the applicable organizational boundary.
Record processing has also changed
RFC 9989 lists p as recommended rather than unconditionally required. Implementations should not automatically equate a published record without a valid p value with no DMARC record. The policy-discovery rules determine whether processing continues as if p=none or whether no DMARC processing applies, including whether a syntactically valid rua destination is present.
The former size suffix on reporting URIs, such as an exclamation mark followed by a maximum report size, is now obsolete. Report generators should ignore that suffix when it is encountered in an existing record.
Reporting now has dedicated specifications
The DMARC base protocol remains in RFC 9989, while reporting is defined in two dedicated documents. RFC 9990 specifies aggregate reporting requested through rua. RFC 9991 specifies message-specific failure reporting requested through ruf.
The former rf and ri tags have been removed from the base specification. Failure reports also remain subject to receiver support, privacy considerations and possible out-of-band agreements.
What organizations should review now
- Check whether published DMARC records still contain pct, rf or ri.
- Verify whether DMARC tooling and internal documentation reference RFC 9989 rather than only RFC 7489.
- Review how subdomain and non-existent-domain policies are handled.
- Confirm that aggregate and failure-report processing follows RFC 9990 and RFC 9991.
- Do not change enforcement policy solely because a specification changed; validate legitimate senders and alignment first.
A practical transition approach
Start by inventorying records, platforms and documentation. Identify obsolete tags and determine whether any operational process still depends on them. Then test how your receiving, reporting and monitoring providers implement the current specification.
RFC 9989 also makes explicit that p=reject is not automatically the right end state for every domain. Domains used for general-purpose user email, especially where users participate in mailing lists, should assess indirect mail flows carefully before publishing reject. A staged move through monitoring and quarantine remains essential where reject is appropriate.
Treat the update as a governance and validation exercise rather than a rushed DNS change. The goal remains the same: keep legitimate mail aligned, make unauthorized exact-domain use visible and move toward enforcement only when the sender landscape is understood.
Sources and next steps
Does your DMARC setup still reflect the current standard?
Sender Integrity helps review your records, sender landscape, alignment and safe route toward enforcement against the current DMARC specification.
Start with Sender Integrity Scan