DMARC is now RFC 9989: what changed in May 2026

The DMARC specification was replaced in May 2026. The pct tag is gone, np and psd arrived, and policy discovery no longer uses the Public Suffix List.

By the Maborak engineering team · 2026-10-29 · 4 min read

The DMARC specification was replaced. RFC 9989, published in May 2026, obsoletes RFC 7489 and RFC 9091. Reporting moved into two companion documents, RFC 9990 and RFC 9991. The Gmail and Yahoo bulk-sender requirements have not changed, but the standard underneath them did.

Checked 29 October 2026. The tag changes and discovery changes below are quoted from RFC 9989. This describes a specification change, not a new vulnerability or a change in mailbox-provider policy.

What replaced what

RFC 9989 is a Standards Track document. That is a maturity change as well as an editorial one: the record format and discovery rules are now the normative reference.

Tag changes

• pct is removed. RFC 7489 allowed a percentage so a domain could move gradually from p=none to quarantine or reject. Operational experience showed the value was usually applied correctly only at 0 or 100 and varied between implementations, so RFC 9989 removes the tag entirely. A record that still contains pct= is not a way to stage a rollout any more.
• p is RECOMMENDED, not required. If a syntactically valid record omits p, it is treated as p=none. The record still exists, so the domain still participates; it just requests no handling preference.
• np is added for non-existent subdomains of the organizational domain. It was imported from RFC 9091.
• psd is added to mark a domain as a public suffix domain, so policy discovery can treat it correctly.
• t is added as a test mode. t=y asks the receiver not to apply the declared policy as-is, but to apply the next-lower policy (for example quarantine becomes none, reject becomes quarantine), while still generating reports. It defaults to n. It is a request, not a guarantee, and it has no effect on a policy of none.

Policy discovery changed

RFC 7489 used the Public Suffix List to find the organizational domain. RFC 9989 replaces that with a DNS Tree Walk: the receiver derives the candidate policy domains from the DNS itself and applies the record found for the domain. The change removes a dependency on an external list that could disagree with the actual DNS delegation.

sp still sets policy for existing subdomains, and np now covers non-existent ones. If neither applies, p governs.

What this means for a sender

• Audit records for pct=. It is no longer the staging mechanism. If a record relies on pct between 1 and 99, its behaviour is now defined by p, not by the percentage. Decide whether that is what you want.
• Use t=y for a controlled move, not pct. When changing p to quarantine or reject, t=y gives receivers a documented request to apply one level lower while you watch reports. Confirm the receiver honours it; it is optional behaviour, not an enforcement.
• Add np deliberately. A strict np=reject can break mail that uses a non-existent subdomain in the From header. Check aggregate reports before adopting it.
• Re-check psd only if you operate a public suffix. For an ordinary organizational domain, leave it at the default unless your DNS makes you a public suffix operator.

Gmail and Yahoo are unchanged

The mailbox-provider rules that most senders are measured against did not change with the RFC. For bulk senders they still require SPF and DKIM, a DMARC record with a policy of at least p=none that passes with alignment, one-click unsubscribe under RFC 8058, and a spam-complaint rate below 0.3%. What changed in late 2025 was enforcement: Gmail documented that non-compliant traffic would see temporary and permanent rejections. The requirements were stable; the consequence of ignoring them was not.

The primary references are RFC 9989, RFC 9990 and RFC 9991, plus the Gmail sender guidelines and Yahoo Sender Hub.

Topics: email, security