Daily DMARC News
6 min read By Excello Mail Team

RFC 9989 Is Here: How Excello Mail Already Supports the New DMARC Standard

RFC 9989 (May 2026) is the long-awaited DMARCbis update. It obsoletes RFC 7489, removes the pct tag, adds np, t and psd, and replaces the Public Suffix List with a DNS Tree Walk. Here is what changed, and how Excello Mail already supports it.

The IETF published RFC 9989 on May 12, 2026, finalizing the work that the email security community has been calling “DMARCbis” for the past five years. It is the first substantive revision of DMARC since RFC 7489 shipped in 2015, and it carries enough changes that every DMARC monitoring platform, every report receiver, and every domain owner publishing a record needs to pay attention.

We have been tracking the draft through forty-one revisions inside the IETF DMARC working group. Today we are happy to confirm that Excello Mail already parses, validates, and generates DMARC records using the new RFC 9989 tag set, and that our aggregate report ingestion pipeline reads the RFC 9990 schema additions out of the box.

What RFC 9989 Actually Changes

RFC 9989 obsoletes RFC 7489 and RFC 9091. The two companion documents, RFC 9990 (aggregate reporting) and RFC 9991 (failure reporting), carry the parts of the reporting format that used to live inside the original spec. Together they make up the new DMARC standard.

The substantive changes break into three groups.

1. The Tag Set Is Different

Three new tags arrive, one is removed, and the rest are unchanged.

  • np= (new). The Non-existent Subdomain Policy. Receivers apply this when mail claims to come from a subdomain that does not exist in DNS. Values: none, quarantine, or reject. Section 4.7.
  • t= (new). Test Mode. When set to y, the published policy is in test mode and receivers should treat policy actions as advisory rather than enforced. The new replacement for the old pct tag’s role. Section 4.7.
  • psd= (new). Public Suffix Domain flag. Used by Public Suffix operators (the operators of .co.uk, .gov.au, and so on) to signal whether their record is at a PSD or at an Organizational Domain. Values: y, n, u. Section 4.10.
  • pct= (removed). The percentage tag is gone. Appendix A.6 of RFC 9989 documents the removal. Existing records keep working, but new records should use t=y for test-mode handling.

2. The Organizational Domain Now Comes From DNS, Not a List

The most architecturally significant change. RFC 7489 told receivers to derive the Organizational Domain (the domain that owns the policy you should fall back to for subdomains) by consulting a Public Suffix List. The PSL is maintained by Mozilla, depends on a centralized GitHub repository, and produces inconsistent results across receivers that use different snapshots of it.

RFC 9989 replaces the PSL with the DNS Tree Walk. The algorithm is in Section 4.10. In plain English: starting from the domain in the message’s From header, the receiver queries _dmarc.<that-domain>. If nothing is there, it strips the left-most label and queries again. It keeps walking up the tree until it finds a DMARC record or runs into a Public Suffix operator’s psd= tag. The walk is capped at eight queries to prevent abuse.

The result: the DNS itself, rather than an external list, determines where an Organizational Domain boundary sits. Suffix operators can publish their own DMARC records with psd=y to mark the boundary explicitly. Domain owners get the side benefit that a subdomain without its own DMARC record now reliably inherits from the parent through DNS, not through whatever PSL snapshot the receiver happened to have loaded.

3. Reporting Formats Got Schema Additions

The aggregate (RUA) XML format in RFC 9990 now carries optional version, discovery_method, np, and testing elements on policy_published, makes the DKIM selector element a required part of each auth_results entry, and adds human_result and scope optional fields for richer diagnostics.

The failure (RUF) format in RFC 9991 introduces a required Identity-Alignment header listing which mechanisms failed to authenticate an aligned identity, plus DKIM-Domain, DKIM-Identity, DKIM-Selector, and SPF-DNS fields with the same purpose. It also gives Auth-Failure: dmarc a formal blessing.

What This Means for Your Domain

Nothing breaks immediately. RFC 7489 records continue to be parsed correctly by every implementation we are aware of, including ours. Receivers will roll out RFC 9989 support gradually, with major mailbox providers expected to be first.

That said, two practical recommendations:

  1. If you publish pct= today, plan to migrate to t=y when you next revise your record. Receivers will continue tolerating the deprecated tag for a long time, but the cleanest signal for “policy in test mode” is now the new tag.
  2. If you manage a domain with multiple subdomains, consider whether you want to set np= explicitly. Today many platforms get tripped up by mail forged from non-existent subdomains, and np=reject is the cleanest way to shut that vector down.

How Excello Mail Supports It

Our work over the past two weeks brought every part of the platform up to RFC 9989, RFC 9990, and RFC 9991:

  • DMARC record analyzer. Our /details/dmarc page now surfaces np, t, and psd when present, with full descriptions of what each tag means. If your published record uses pct=, we display it (no record is broken) but call out the RFC 9989 deprecation in the field’s tooltip.
  • DNS Tree Walk. Our policy discovery module walks up the DNS hierarchy from the author domain, honors psd= boundaries, and respects the 8-query cap. Subdomains without their own DMARC record now inherit correctly from the Organizational Domain.
  • Aggregate report ingestion. Our RUA pipeline extracts every new RFC 9990 element. The DKIM selector, human-readable diagnostic strings, SPF scope, and envelope-from / envelope-to identifiers are all parsed and stored relationally. No JSON blobs.
  • Failure report processing. Our ARF parser reads the new Identity-Alignment, DKIM-Selector, DKIM-Domain, DKIM-Identity, and SPF-DNS fields, and recognizes Auth-Failure: dmarc as a first-class failure type.
  • Record generator. Our /generate/dmarc tool offers np and t as configurable options. We removed the pct field for new records because RFC 9989 removes it, and we explain that change next to the form. Translated into English, Spanish, and Portuguese.

If you are publishing or monitoring DMARC records, your tooling needs to keep up with the new standard. The simplest way to stay current is to outsource the work.

Try Excello Mail

Excello Mail is a fully managed DMARC monitoring platform. We receive your aggregate and failure reports, parse them against the latest standards (now including RFC 9989, RFC 9990, and RFC 9991), surface what your traffic actually looks like across every authenticating source, and guide you from p=none to p=reject without breaking your legitimate mail streams.

Start your free trial at excello.email

Have a question about how a specific RFC 9989 change affects you? Sign up for an account and our team will walk through your published record with you.