The New DMARC Standard (RFC 9989): What Changed and What You Need to Update

DMARC got its first major update since 2015. RFC 9989 was published last week, replacing the original DMARC specification (RFC 7489) that has governed email authentication for the past decade.

Most of the changes happen at the infrastructure level and require no action from domain owners. But a few changes affect what should actually be in your DMARC record. This post covers everything that changed and what you need to do.

What stays the same

Before getting into the changes, the important part: your existing DMARC records still work. v=DMARC1 is still valid. p=reject still means reject. Mail receivers running on RFC 7489 will keep evaluating your records correctly, and receivers updating to RFC 9989 will read your existing records without breaking anything.

There is no urgent migration. There are, however, improvements worth making.

What changed in the record syntax

New tag: np (non-existent subdomain policy)

This is the most important practical change.

Under the old standard, p=reject covered your domain and all existing subdomains. It did not reliably cover subdomains that don't exist in DNS. So an attacker could send mail from wire@payments.yourcompany.com — a subdomain you never created — and receiver behavior was inconsistent.

np=reject closes that gap explicitly. It tells receivers: if mail arrives from any subdomain that doesn't exist in DNS, reject it.

This is the single cheapest spoofing protection win in the entire update. Real estate firms, financial services, and SaaS companies should add it immediately. The attack pattern of inventing plausible-sounding subdomains (billing., payments., wire., accounts., invoices.) is common and cheap to execute.

New tag: t (testing mode)

The old pct tag let you apply a DMARC policy to only a percentage of failing messages — useful for gradual rollouts. In practice, only pct=0 and pct=100 (the default) worked reliably across receivers. Everything in between produced inconsistent results.

t=y and t=n replace this. t=y tells receivers to apply a policy one level softer than what you've declared (so p=reject; t=y actually behaves like p=quarantine at the receiver). t=n is the default and means apply the policy as written.

Use t=y when you want aggregate reports without enforcement, then remove it once you're confident.

New tag: psd (public suffix domain flag)

This one matters only if you operate a public suffix domain — a TLD or sub-TLD that hosts independent organizations under it (like .uk hosts co.uk, ac.uk, etc.). For 99% of domain owners, this tag is irrelevant.

If you do operate a PSD, psd=y tells receivers your domain is a public suffix and policy inheritance should stop there.

Removed tag: pct

Gone. Replaced by t=y / t=n (see above). If your record still has pct= in it, you can remove it on the next update. Receivers ignoring pct won't break anything, but cleaning it up is good hygiene.

Removed tag: rf (report format)

The old standard let you specify a failure report format. In practice, only one format (afrf) was ever used. The tag was dead weight and has been removed.

Removed tag: ri (report interval)

Used to specify the desired interval between aggregate reports. In practice, all major receivers send reports daily regardless of what ri requested. Removed.

What changed in how DMARC works (infrastructure level)

These changes are invisible to domain owners but worth knowing about. They affect how mail receivers evaluate your records, not what you publish.

The Public Suffix List is gone

The old DMARC standard relied on the Public Suffix List (PSL) — a community-maintained list of domains that act as TLD-like boundaries (co.uk, com.au, etc.). Receivers used the PSL to figure out the "Organizational Domain" for any given email.

The PSL had real problems. Different receivers used different versions of the list. Updates were slow. New TLDs and sub-TLDs took years to be reflected. And reliance on a community-maintained list inside a critical email infrastructure protocol was always uncomfortable.

RFC 9989 replaces the PSL with a process called the DNS tree walk. Instead of consulting an external list, receivers walk up the DNS tree label by label, looking for a DMARC record. The first one they find (within an 8-label limit) determines the policy and Organizational Domain.

For most domains, this produces the same result as the old PSL approach. For domains with deep subdomain structures or complex organizational hierarchies, it produces more predictable results.

Reporting is now a separate document

The aggregate reporting (rua) and failure reporting (ruf) mechanisms got their own RFCs: 9990 and 9991, respectively. This is mostly a documentation cleanup. The XML schema for aggregate reports is slightly updated to reflect new tags, but parsers handling old reports will continue to work.

Failure reporting is officially discouraged

RFC 9989 and 9991 explicitly note privacy concerns with ruf= reports. Most major receivers (Google, Microsoft, Yahoo) have not been sending failure reports for years, and the new standard formalizes this position. If you have ruf= in your record, it's not harmful, but it's also not doing anything useful.

p=reject is now officially discouraged for mailing-list domains

The new standard explicitly warns that p=reject causes interoperability problems for domains whose users post to mailing lists. This isn't a new issue — it's been a known problem since 2015 — but RFC 9989 makes it an explicit recommendation: if your domain has general users who participate in listservs or mailing lists, use p=quarantine instead.

For real estate firms with agents on NAR, MLS, or regional association mailing lists, this matters. For pure transactional senders (SaaS, fintech, financial services with no listserv exposure), p=reject remains appropriate.

Old record vs new record

Here's a typical DMARC record under the old standard:

v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com; ruf=mailto:reports@yourdomain.com; pct=100; fo=1

Here's what it should look like under RFC 9989:

v=DMARC1; p=reject; np=reject; rua=mailto:reports@yourdomain.com

What changed:

• Removed ruf= (failure reports are discouraged and rarely sent)
• Removed fo= (only applies to ruf, no longer needed)
• Removed pct=100 (default behavior, no longer a valid tag)
• Added np=reject (blocks spoofing from non-existent subdomains)

For domains with mailing list exposure, swap p=reject for p=quarantine while keeping np=reject for the subdomain protection.

What you need to do

For most organizations, three actions:

1. Add np=reject to your DMARC record. This is the only material new protection in RFC 9989 and it costs nothing.
2. Remove pct=, rf=, ri=, and ruf= tags if they're in your record. They're either removed from the standard or no longer doing anything useful.
3. Review your p= value if your domain has users on mailing lists. Consider p=quarantine instead of p=reject.

If your DMARC management is delegated to a provider (Valimail, dmarcian, EasyDMARC, or us), your records will be updated automatically. If you manage DNS in-house, this is a 5-minute change.

A note on the RFC split

DMARC used to live in a single document (RFC 7489). It now lives in three:

• RFC 9989 — the core DMARC mechanism (record syntax, policy evaluation, tree walk)
• RFC 9990 — aggregate reporting (rua=)
• RFC 9991 — failure reporting (ruf=)

When people refer to "the new DMARC standard," they generally mean RFC 9989. The other two are companion documents for the reporting infrastructure.

Bottom line

RFC 9989 is a careful, conservative update. It cleans up tags that didn't work, replaces the unreliable PSL with a more predictable tree-walk algorithm, and adds one meaningful new protection (np=reject) that closes a real spoofing attack vector.

Nothing about this update is urgent. But adding np=reject to your DMARC record is the kind of cheap, high-leverage change that's worth doing this week rather than next quarter.

---

If you'd like us to check your current DMARC record and identify what needs updating, we offer a free deliverability assessment. We currently manage DMARC for 450+ organizations across real estate, SaaS, and financial services.