DMARC RFC 9989, 9990, And 9991 Replace RFC 7489

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. Although not an official term, the RFCs were together known in the community as DMARCbis, and are now published as the updated DMARC specification with the same version number.

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 is a meaningful jump, since it gives DMARC a stronger and more formal place in the Internet standards stack.

What Each RFC Covers

The DMARC specification has been split into three focused documents rather than one large file. RFC 9989 contains the core protocol, including policy evaluation, alignment rules, and record processing. RFC 9990 defines the aggregate (RUA) reporting format. RFC 9991 covers failure reports, often called forensic reports.

Your Existing DMARC Record Still Works

One of the most important points for domain owners is that this is not a breaking change. The protocol identifier stays the same, so records still begin with v=DMARC1. You do not need to rebuild your setup or republish all your records overnight.

If you want a refresher on how records are structured, our guide on DMARC tags walks through each field.

Key Technical Changes

A few updates stand out, and a couple of them are worth understanding in detail before you touch your record.

Public Suffix List replaced by DNS Tree Walk

Receivers no longer rely on the externally maintained Public Suffix List to figure out the Organizational Domain. Instead, they walk up the DNS hierarchy and look for _dmarc records at each level. In practice, a receiver starts at the domain in question and queries progressively higher labels, up to a maximum of eight lookups, until it finds a published DMARC record. This removes a third-party dependency and improves accuracy for complex domain structures.

There is a practical implication worth noting. Because the Tree Walk resolves the Organizational Domain differently from the old Public Suffix List method, a receiver running RFC 9989 may, in some cases, arrive at a different Organizational Domain than a receiver still on RFC 7489. If you run a complex subdomain hierarchy or use delegated domains, the safest approach is to publish an explicit DMARC record at every domain and subdomain you actually send email from. That removes any ambiguity about which policy applies, regardless of which version a given receiver is using.

New tags: np, psd, and t

RFC 9989 introduces three new tags. Here is what each one does and when you would actually use it.

np (non-existent subdomain policy)

The sp tag already lets you set a policy for subdomains, but np goes a step further by separating the policy for subdomains that do not exist at all, meaning DNS returns NXDOMAIN. This closes a real subdomain spoofing gap, since attackers often forge mail from subdomains that were never registered. For example, a record of v=DMARC1; p=none; np=reject; would apply no policy to the root domain and its genuine subdomains, but still reject mail from non-existent ones. If your domain is already at p=reject or sp=reject, the strict policy is automatically inherited, so np=reject adds nothing, and no change is needed. If you sit at a softer policy but want targeted protection against this specific attack, adding np=reject is well worth it.

t (testing mode)

This is the tag most likely to be misread. Setting t=y does not disable your policy. Instead, it asks receivers to apply the next less strict policy than the one you published: a reject policy is treated as quarantine, a quarantine policy is treated as none, and none is unaffected. This is far more precise than the old pct behaviour it effectively replaces. One important caveat: not every receiver supports RFC 9989 yet, so some will simply ignore t=y. During the transition period, the safer approach is to use both pct and t together, so older and newer receivers both understand your intent. A staged record might look like v=DMARC1; p=reject; pct=50; t=y;. You can read more about this shift in our earlier note on why t replaces pct.

psd (public suffix domain)

This tag helps receivers determine the Organizational Domain during the DNS Tree Walk. Most ordinary domain owners should simply leave it out. It is only relevant in two situations: an organisation that wants to declare a deliberate Organizational Domain boundary at a subdomain (set psd=n there), or an operator of a Public Suffix Domain such as .bank or .gov (set psd=y). Bear in mind that receivers still running RFC 7489 will ignore this tag entirely, so it is not a substitute for sound record design.

Three tags removed: pct, rf, and ri

RFC 9989 retires three tags. None of these removals will break an existing record, but it is worth understanding what each tag did and what to do about it. See the dedicated section below.

Clearer guidance for mailing lists and forwarding

Indirect mail flows still break SPF and DKIM alignment, and the new spec acknowledges this openly. It advises against aggressive p=reject policies where mailing list traffic is common, which reflects how email actually behaves in the real world.

Better defined conformance

The new text spells out what “full DMARC participation” means for both senders and receivers, which should reduce the patchy implementations that have been a problem for years.

Reporting URI size limit removed

A smaller change that is easy to miss: RFC 9989 removed the ability to specify a maximum report size in the reporting URI. Records that used a size suffix such as rua=mailto:[email protected]!10m are no longer meaningful, and receivers should now ignore any size limit attached to a rua or ruf address. If your reporting URIs include this syntax, you can safely strip the size limit portion.

Understanding the Removed Tags

If your current record uses pct, rf, or ri, here is exactly what each one did and what you should do now.

pct (percentage)

This tag was designed to let you roll out a policy gradually, applying it to a chosen percentage of mail. In practice, it was implemented inconsistently across receivers, which produced unpredictable results, and it has been replaced by the cleaner t tag. If you still rely on pct, do not lean on it alone going forward. During the transition, the sensible move is to run pct and t=y together so that both older receivers and RFC 9989 receivers understand that you are staging toward enforcement.

rf (report format)

This tag specified the format for failure reports, but the only ever valid value was afrf, which made the tag redundant in practice. It is safe to remove from any record where it appears.

ri (reporting interval)

This tag defined the requested interval between aggregate reports, in seconds. Most receivers ignored it and simply defaulted to a daily report, and RFC 9989 now formalises that by requiring receivers to send aggregate reports at least once a day. The tag is harmless to leave in place, but it is increasingly irrelevant and should not be relied on.

How to Update DMARC Record RFC 9989?

The publication of RFC 9989 doesn’t break anything you already have. Your record still lives in the same place – a DNS TXT record at _dmarc.yourdomain.com, and the version tag is still v=DMARC1.

So why update at all? Because RFC 9989 reflects how email actually works after a decade of real-world deployment, and a few of its changes are worth folding into your record now rather than discovering later.

Here’s What Domain Owners Should Do

Domain owners can work through the checklist below to update their records dynamically:

Remove the rf and ri tags. Both are deprecated and safe to delete.
Replace pct with t: use t=y for testing (in place of any pct<100), or drop the tag for full enforcement (t=n is the default)
Consider adding np=reject if you want to block spoofing from non-existent subdomains without changing your main policy.
Remove the reporting URI size limit suffix if your rua or ruf records include one.
Leave psd out unless you intentionally need to declare an Organizational Domain boundary or you operate a Public Suffix Domain.
Publish explicit DMARC records for every domain and subdomain you send email from, to avoid any DNS Tree Walk ambiguity between RFC 9989 and RFC 7489 receivers.

For a deeper walkthrough of the changes and how to prepare your records, see our full guide on DMARCbis explained.

A modernized record under RFC 9989 looks like this:

v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=s; aspf=s

Notice what’s not there: no pct. To stage it safely, append t=y, let the aggregate reports accumulate, then remove it when you’re ready for full enforcement.

You’ll also notice two valid RFC 9989 tags absent from this record – t and psd, and that’s intentional, because both are situational rather than standard.

The t tag is temporary test mode: you add it only while ramping toward enforcement, since it tells receivers to apply the next-lower policy than the one you’ve published. The psd tag, meanwhile, is a flag that declares a domain to be a public suffix. Public Suffix Operators must set psd=y, but for an ordinary domain owner, the default (u) is exactly right, and you should simply omit the tag.

Make Sure Your DMARC Platform Is Ready

Not every tool on the market has caught up with the new standards yet, and that gap matters. If your platform cannot read the new tags or process reports in the updated format, you lose visibility right when the protocol is evolving.

PowerDMARC is already aligned with the new specifications and supports:

RFC 9989, 9990, 9991 compatible record generation
Parsing of the new np, psd, and t tags
RFC 9990 aggregate report ingestion and reporting
DNS Tree Walk based organizational domain handling
Updated processing behaviour that reflects the new conformance rules

If you want to see how your current record holds up against the new standard, run it through our free DMARC checker and review what needs cleaning up.

Final Words

The updated RFCs are not a new protocol. It is the same DMARC, rewritten more clearly and lifted to standards-track status. After more than a decade of real-world deployment, the spec now reflects how email actually works, including its messy parts like forwarding and mailing lists.

For anyone responsible for domain security, the publication of RFCs 9989, 9990, and 9991 is a good prompt to audit your records and make sure your tooling is ready for the new tags and the DNS Tree Walk approach.

About
Latest Posts

Ahona Rudra

Domain & Email Security Expert at PowerDMARC

Ahona is the Marketing Manager at PowerDMARC, with 5+ years of experience in writing about cybersecurity topics, specializing in domain and email security. Ahona holds a post-graduation degree in Journalism and Communications, solidifying her career in the security sector since 2019.

DMARC RFC 9989, 9990, and 9991 Replace RFC 7489