DMARCbis Is Now RFC 9989, 9990, and 9991 - Here's What Changed

After years of drafts, the IETF DMARC working group has published the updated DMARC specification as three new RFCs: 9989, 9990, and 9991. They replace RFC 7489 from 2015 - the original DMARC spec that most email admins know today.

Here is what actually changed and what it means for your setup.

What was removed

Three tags got dropped from the spec. None of them were widely used in practice, and some caused confusion.

pct (percent) - was meant to selectively apply DMARC checking to a percentage of messages. Most receivers ignored it or handled it inconsistently. Removed.

rf (report format) - specified the format for failure reports (FREB). Only a small fraction of senders ever used it. Removed.

ri (reporting interval) - controlled how often aggregate reports were sent. Again, widely ignored or overridden by receivers. Removed.

None of these were central to how DMARC works in practice. If you have pct, rf, or ri in your DMARC record today, those are simply informational to receivers.

What was added

Three new tags made it into the updated spec.

np (nonexistent domain policy) - new to RFC 9989. Specifies how a receiver should handlmail sent from nonexistent subdomains under a valid organizational domain.

psd (Public Suffix Domain) - used for DMARC processing at Public Suffix Domains.

t (tree walk) - part of the DNS Tree Walk mechanism that replaces Public Suffix List lookups in RFC 7489.

The PSL is gone - long live DNS Tree Walk

One of the bigger changes is how sender organizational domains are determined.

The old spec used the Public Suffix List (PSL) - a static list maintained by Mozilla - to figure out where a domain sits relative to its parent.

The new spec replaces PSL lookups with DNS Tree Walk. Instead of consulting a static list, receivers perform a series of DNS queries walking up the domain tree until they find a domain that responds authoritatively.

What this means operationally: for most senders with standard domain setups, the behavior will be similar. But for complex domain structures - especially multi-level subdomains used in large organizations or cloud deployments - DNS Tree Walk may produce different results than PSL-based logic.

Does your existing DMARC record still work?

Yes. Your existing v=DMARC1; p=reject; rua=mailto:... record is still valid and will remain valid under the new RFCs.

The removed tags (pct, rf, ri) were optional and already widely ignored by most receivers. Removing them from your record is optional.

If you are running a DMARC monitoring tool, check with your vendor that they are updating their parser to handle the new tags (np, psd, t). Most aggregate report parsers need updates to recognize and store these new fields. Depending on what provider you are using they may or may not track these updates. Some vendors, including DMARCFlow, say they are updating their parsers to support RFC 9989 tags - their aggregate report handles RFC 7489 tags and they are currently implementing the new RFC 9989 vocabulary, so reports from providers like DMARCFlow adopting the new format will parse correctly without breaking your existing monitoring setup. 

What DMARC report senders need to do

If you are a mailbox provider or email platform that generates DMARC aggregate reports:

• Update your report generation to include the new np tag and potentially the psd and t tags
• Expect receiver-side changes in how organizational domain detection works - some of your sending domains may now be evaluated differently
• If you use DMARC report parsers internally, update them to handle the new tag vocabulary

For most senders who are consuming reports rather than generating them, the immediate action is: nothing urgent. Your existing records and monitoring setup will continue to work.

What DMARC monitoring tools need to do

This is where it gets practical for the people actually reading DMARC reports.

Aggregate report parsers that only understand RFC 7489 tags will not break when they see np, psd, or t in incoming reports - they will just skip over unknown tags. But they also will not store or surface the new information. If you are running your own parsing pipeline, update your schema to capture the new tags.

If you are using a commercial tool, check whether they have committed to supporting the new format. DMARCFlow handles both old and new tag formats in its parser, so you do not need to migrate anything when providers start sending the updated reports.

The real-world problem that did not change

One thing worth noting: the new RFCs do not fix the fact that DMARC aggregate reports from major providers are still frequently non-compliant with RFC 7489 itself.

Multiple studies have shown that the majority of aggregate reports arrive with malformed XML, incorrect filenames, missing required fields, or invalid tag values. The new RFCs do not introduce special handling for non-compliant reports - that is a separate problem that senders and receivers need to work out operationally.

That is a real consideration when choosing a DMARC monitoring platform: parsing robustness matters as much as spec coverage.

Summary

• Three new RFCs replace the 2015 DMARC spec: 9989, 9990, 9991
• Removed: pct, rf, ri - none were widely used or critical
• Added: np (nonexistent domain policy), psd (Public Suffix Domain), t (tree walk)
• PSL is replaced by DNS Tree Walk for organizational domain detection
• Your existing DMARC record still works - no urgent changes needed
• If you run a DMARC monitoring tool or parsing pipeline, check for upcoming parser updates

FAQ

Does p=reject still work under the new RFCs?

Yes. The core p= policy values (none, quarantine, reject) are unchanged.

Do I need to update my DMARC record immediately?

No. Removing pct, rf, or ri is optional and has no effect on receiver behavior. Your existing record is valid under RFC 9989.

What is DNS Tree Walk in practice?

Instead of looking up a static Public Suffix List entry, receivers now walk up the DNS tree by querying for SOA records until they find an authoritative answer. This determines the sending organization domain for DMARC alignment purposes.

Will DNS Tree Walk change results for my domain?

For most domains, no. For complex multi-level subdomain structures, possibly - particularly in large cloud deployments where subdomains map to different services or tenants.

Do I need to switch DMARC tools because of the new RFC?

Not necessarily. If your current tool can handle both RFC 7489 and the new tags, you are covered. DMARCFlow already tracks parser updates for the new spec. If your tool does not commit to RFC 9989 support, that is a reasonable signal to evaluate alternatives and to ask those companies if they do.