What changed in DMARC (RFC 9989/9990/9991)

DMARCbis replaces the 2015 spec — here's what's actually different, in plain English.

In 2026, the IETF published RFC 9989, 9990, and 9991, formally obsoleting the original DMARC specification, RFC 7489. Two things changed about its status as much as its content: DMARC is now a Proposed Standard (Standards Track) rather than an Informational document, and the spec is split across three documents — RFC 9989 (core authentication and policy), RFC 9990 (aggregate reporting), and RFC 9991 (failure reporting). Below are the changes that actually affect how your records get evaluated.

1. Domain discovery: DNS Tree Walk replaces the Public Suffix List

Under RFC 7489, Mail Receivers determined a domain's "Organizational Domain" (the domain a DMARC policy applies to when a subdomain has none of its own) by looking it up against the Public Suffix List — a community-maintained, externally-hosted file. RFC 7489 never mandated which PSL to use or how often to refresh it, which meant different receivers could reach different conclusions about the same domain.

RFC 9989 replaces this with the DNS Tree Walk: instead of consulting an external list, the receiver queries DNS directly, walking up the domain hierarchy one label at a time until it finds a DMARC record marked with psd=n (this is an Organizational Domain) or psd=y (this is a Public Suffix Domain, e.g. a registrar or hosting platform boundary). To prevent a malicious sender from forcing endless lookups with an artificially deep hostname, the walk is capped at eight DNS queries.

Practically: this moves control of organizational boundaries into your own DNS instead of a third-party list, which is why large organisations can now publish more precise, decentralised policies across subdomains.

2. Policy discovery order

When a receiver evaluates a message, it looks for an applicable DMARC record in this order:

1. A record at the exact sending (Author) domain
2. If none, the record at that domain's Organizational Domain (found via the Tree Walk)
3. If none, the record at the Public Suffix Domain

If the record actually applied belongs to the Organizational Domain or PSD rather than the exact sending domain, the policy used depends on whether the sending subdomain exists in DNS: the sp tag applies if it exists, the new np tag applies if it doesn't. If neither is set, the parent's p tag is used as the fallback either way.

3. Tags that were added or retired

4. p=reject is no longer a hard instruction

This is the change with the most real-world impact. RFC 9989's conformance requirements (Section 8) are explicit:

Receivers are now required to weigh a p=reject policy alongside other signals — sending patterns, content filtering, and so on — rather than rejecting purely because the record says so. The RFC goes further for who should publish it at all:

Domains that host users who post to mailing lists get the same guidance specifically, since list remailing frequently breaks DMARC alignment in ways the sender never intended. p=reject still has a role for domains that send no legitimate mail through unauthenticated paths (pure transactional/no-reply senders, for example) — but for a typical company domain, publishing it no longer guarantees rejection, and may just create a false sense of enforcement while quietly generating alignment failures on legitimate mail.

5. Aggregate and failure report changes

RFC 9990 adds a discovery_method field to aggregate reports, recording which policy-discovery step actually applied (exact match, Organizational Domain, or PSD) — useful for spotting when the Tree Walk picked a different record than you expected. RFC 9991 requires failure reports to include the DKIM selector when reporting a signature failure, giving more to work with when diagnosing a specific break.