DMARCbis: What RFC 9989 Changes in Your DMARC Record
DMARCbis is the revised DMARC specification, published in May 2026 as a Standards Track document. The full text of RFC 9989 retires three tags (pct, rf, ri), adds three (np, psd, t) and swaps the Public Suffix List for a DNS Tree Walk. Asking yourself “does my DMARC record still work”? Relax: it still begins with v=DMARC1, and you are looking at a review job, not a rebuild.
What Is DMARCbis and Which RFCs Does It Replace?
DMARCbis is the working name; the update is published as RFC 9989 and obsoletes RFC 7489 and RFC 9091. The earlier document was only Informational, while the new DMARC standard sits on the Standards Track. The core ideas are untouched: the policies remain none, quarantine and reject, and a message still passes when SPF or DKIM authenticates a domain aligned with the visible From address.
Reporting has been split out of the core text. Aggregate reports are now defined in the separate RFC 9990 document, which requires mail carrying DMARC feedback to produce an aligned pass itself, lowering the risk of report consumers processing fraudulent data.
Which Tags Are Removed: pct, rf and ri
RFC 9989 drops pct, rf and ri from the record format:
- pct - the share of failing mail the policy applied to.
- rf - the format requested for failure reports.
- ri - the requested interval between aggregate reports.
The headline “dmarc pct tag removed” means gradual percentage rollout is gone: you can no longer ask receivers to enforce a policy on only part of your failing mail, and the t tag takes over the testing role. Delete the leftovers during cleanup, because a receiver following the new document has no reason to honour them.
What the New np, psd and t Tags Do
RFC 9989 adds three tags:
- np - the policy for subdomains that do not exist in DNS.
- psd - a flag stating whether the domain is a Public Suffix Domain, read during the Tree Walk.
- t - a testing flag that replaces the old pct-based rollout.
Why should a small company care about the dmarc np tag? Because spoofers often invent hostnames that were never created. Nothing legitimate sends from those names, so a strict setting there carries little risk.
Subdomain policy now has two layers: sp governs real subdomains, whereas np handles the ones that do not exist. A separate subdomain used for outreach needs its own decision: a team sending cold email follow-ups from it depends on that hostname being authenticated and covered by a policy you chose on purpose.
How the DMARC DNS Tree Walk Replaces the Public Suffix List
Instead of consulting an external Public Suffix List, a receiver now queries DNS label by label up the domain to find the applicable policy record and the Organizational Domain. That term means the domain at the top of your own namespace, whose policy covers subdomains without a record of their own.
The change removes an outside dependency and keeps the answer inside the domain owner’s zone.
For a typical small company, the dmarc dns tree walk usually produces the same result as before and requires no action. Pay attention only if you run deep subdomain structures or publish records at several levels, because the psd tag and intermediate records influence which policy is found.
What RFC 9989 Says About p=reject and Mailing Lists
The document is blunt: p=reject can break indirect mail flows such as mailing lists, forwarders and role-based aliases. Domains publishing that policy must not rely on SPF alone and must apply valid DKIM signatures. Forwarding changes the sending server, as explained in our guide to what happens when DMARC alignment fails.
The recommended path is staged. Publish p=none first. Then move to p=quarantine for an equally long period, and compare the disposition results in your aggregate reports before going further.
Receivers are told not to reject solely because of p=reject. But the text admits that few apply any mitigation, so list mail forwarded with an unmodified From line is frequently rejected. Mailing list software has responded with workarounds that rewrite the From address.
What to Check in Your Existing DMARC Record Today
The whole review fits in seven steps:
- Look up the record published at
_dmarc.yourdomain. - Remove
pct,rfandri. - Decide whether
tis needed while you are still testing. - Add
npfor non-existent subdomains. - Review
spfor subdomains that really send mail. - Confirm DKIM signing on every sending source before moving to reject.
- Confirm the
ruaaddress still receives aggregate reports.
Step six takes the longest, as each newsletter tool, CRM and billing system signs separately. In MailCraft, those sending-domain records are configured through the SPF/DKIM/DMARC setup wizard, with a custom sending domain available on Pro and higher plans.
My advice: treat dmarcbis as a cleanup of an existing record, not a migration. Look up your _dmarc TXT entry and delete the retired tags.
FAQ
Do I need to change v=DMARC1 after DMARCbis?
No. The version tag stays the same. Existing records remain valid in form, so nothing has to be republished from scratch.
What replaces the pct tag in the new DMARC standard?
Nothing one for one, because pct is removed outright. The t tag signals testing mode instead, and staged rollout follows the none - quarantine - reject sequence described in the RFC.
Does the DNS Tree Walk require new DNS records?
Not for a typical single-domain setup, where the walk finds the same policy as before. The psd tag is relevant mainly to public suffix operators. Complex subdomain trees deserve a check.
