For years, DMARC lived in a corner of the internet that few marketers visited. Then the bulk sender requirements arrived, and DMARC became a gatekeeper for the inbox. In 2026, the standard itself changed.
In May 2026, RFC 9989 replaced the original DMARC specification — RFC 7489 — and moved DMARC onto the IETF Standards Track for the first time. The update is not a rewrite of how DMARC works. It is a formalisation, plus a set of tag changes that affect how you write and read records.
If you publish or manage DMARC records, this matters. A record still carrying a tag the new spec no longer defines can confuse tools and undercut the clean migration you want. This guide explains the changes in plain terms.
What you will learn:
- Why RFC 9989 matters and who issued it
- What changed in the DMARC record format
- How SPF, DKIM and alignment still work
- Why DMARC is not a reputation booster
- A safe upgrade path for your records
The Short Version
- RFC 9989 replaced RFC 7489 in May 2026 and moved DMARC to the IETF Standards Track.
- The pct tag is deprecated, replaced by a t (test mode) tag.
- Two new tags were added: np (subdomain policy) and psd (parent-subdomain declaration).
- DMARC evaluation is backward compatible — existing p=reject records still work.
- A DMARC pass only validates the author domain; it does not boost reputation on its own.
- Enforced DMARC (p=quarantine or p=reject) is the practical bar for Gmail, Yahoo and Microsoft.
What RFC 9989 Actually Is
RFC 9989 is the DMARC specification written by the IETF's DMARC working group, replacing the 2015 experimental RFC 7489. "Standards Track" matters because it signals maturity: DMARC is now a formally recognised Internet Standard rather than an experimental mechanism.
The practical result is clearer, more maintainable records and a defined way to handle subdomains. The underlying mechanism — verifying the From-domain with SPF and DKIM, then applying a policy — is unchanged.
| Attribute |
RFC 7489 (old) |
RFC 9989 (new) |
| Status |
Experimental |
Standards Track |
| Replaced |
— |
Replaces RFC 7489 |
| Sampling tag |
pct |
t (test mode) |
| Subdomain policy tag |
Inherits parent |
np |
| Parent-subdomain tag |
— |
psd |
| DMARC location |
_dmarc TXT |
_dmarc TXT (unchanged) |
The Tag Changes You Need to Know
pct is gone — use t (test mode) instead
The old pct tag let you apply a policy to a percentage of mail. In RFC 9989, that is replaced by a t test-mode tag. Test mode lets you publish your intended policy while receivers also keep sending you aggregate reports, so you can observe behaviour before you enforce.
If your record still uses pct=, tools built against the new spec may flag it as a tag that is no longer defined. The clean fix is to drop pct and, if you were using it for a staged rollout, adopt the t tag instead.
New subdomain tags: np and psd
np sets an explicit policy for subdomains that do not have their own DMARC record.psd marks a domain as a parent of subdomains, so its policy inheritance is explicit.
These make subdomain handling predictable. That matters for teams that separate marketing and transactional streams on subdomains — a pattern that protects transactional reputation. See how this fits into broader email authentication.
What did not change
- SPF and DKIM still provide the signing and authorisation.
- Alignment still decides whether the From-domain matches what SPF/DKIM validated.
- The
p policy (none / quarantine / reject) is still the heart of the record.
- Records are still published at
_dmarc.example.com as TXT.
Why DMARC is Not a Reputation Booster
One point in RFC 9989 is worth reading twice: a DMARC pass indicates only that use of the author domain was validated. It carries no value assertion about the message.
In plain terms, DMARC proves your domain is not being spoofed. It does not make your email more relevant, and it does not raise your reputation with the mailbox provider. Gmail, Yahoo and Microsoft require DMARC as a condition of entry for bulk senders, but once you are authenticated, engagement and list quality decide whether you reach the inbox.
This is why compliance alone is not enough. Authentication gets you through the door; clean lists and engagement keep you there. The gap between publishing DMARC and enforcing DMARC is where most deliverability risk now sits — a large share of domains are still at p=none, which reports failures but does nothing to stop spoofing.
How to Upgrade Your DMARC Record Safely
The good news is you do not need to rebuild anything. RFC 9989 is backward compatible. Follow these steps to move cleanly:
- Audit your current record. Remove any
pct tag and replace it with t if you still want a staged rollout.
- Confirm your policy. If you are at
p=none, plan a path to p=quarantine, then p=reject.
- Add explicit subdomain handling with
np and psd if you send from subdomains.
- Verify SPF and DKIM alignment across every sending source, including your ESP.
- Monitor aggregate reports before and after the change, then check with the email authentication health check.
Use the DMARC record generator to build a compliant record with the new tags, and confirm your domain's wider setup with the email authentication health check.
DMARC Record Examples: Before and After
A concrete record makes the changes obvious.
Old-style record (RFC 7489):
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com; ruf=mailto:forensics@example.com
Updated record (RFC 9989):
v=DMARC1; p=quarantine; t; np=quarantine; psd; rua=mailto:dmarc@example.com; ruf=mailto:forensics@example.com
The differences, line by line:
| Tag |
Old meaning |
New meaning |
pct=25 |
Applied policy to 25% of mail |
Deprecated |
t |
— |
Test mode: observe before enforcing |
np=quarantine |
— |
Policy for subdomains without their own record |
psd |
— |
Declares this domain is a parent of subdomains |
Most senders will simply publish the updated record with the same p policy they use today, drop any pct, and add np and psd only if they actively manage subdomains. The DMARC record generator produces a record with the current tags so you do not have to hand-edit DNS.
DMARC and BIMI: The Visible Layer
One area RFC 9989 does not change is how DMARC interacts with BIMI. BIMI lets you display your verified brand logo next to your messages in Gmail, Yahoo and Apple Mail — but only when your DMARC record is enforced at p=quarantine or p=reject.
That makes enforcement a prerequisite for the visible trust signal. If you are still at p=none, you cannot qualify for BIMI, and you are also not protecting recipients from spoofing. Moving to an enforced policy therefore does two things at once: it closes the spoofing gap, and it unlocks the branded inbox presence that measurably lifts engagement. For the full picture, see how DMARC and BIMI work together.
Key Takeaways
- RFC 9989 replaced RFC 7489 in May 2026 and moved DMARC to the IETF Standards Track.
- The
pct tag is deprecated; use the new t test-mode tag for staged rollouts.
- New
np and psd tags give explicit subdomain policy control.
- A DMARC pass only validates the author domain — it is not a reputation booster.
- Existing records are backward compatible; the safe move is to clean up
pct and confirm enforcement.
- Enforcement (p=reject) is the practical bar, but engagement and list quality still drive the inbox.
Sources and Further Reading
Related Articles
Related tools: Generate a compliant record with the DMARC record generator, verify your whole setup with the email authentication health check, and monitor domain reputation with the sender reputation checker.
This article summarises public specifications for informational purposes and is not legal or security advice. Consult qualified professionals for your own infrastructure.
