Reference

RFC 9989 vs RFC 7489: what changed in DMARC

RFC 9989 obsoletes RFC 7489. What changed in DMARC: removed and new tags, the DNS Tree Walk, reporting in RFC 9990 and 9991, and what to check.

By Updated Last verified

On this page
  1. Which document is current
  2. What changed
  3. The DNS Tree Walk replaces the public suffix list
  4. Tags: removed, added and still active
  5. Reporting moved to RFC 9990 and RFC 9991
  6. What large senders publish (live DNS)
  7. What to check in your own record
  8. Sources

RFC 9989, published in May 2026, obsoletes RFC 7489 as the specification for DMARC (Domain-based Message Authentication, Reporting, and Conformance) (IETF Datatracker (opens in a new tab), RFC Editor (opens in a new tab)). In RFC 9989 the version tag v takes the single value DMARC1, and p, sp, adkim, aspf and rua, the tag listing the addresses that receive aggregate reports, are active (RFC 9989 section 4.7 (opens in a new tab), section 9.3 (opens in a new tab)). Among the changes RFC 9989 lists: the pct, rf and ri tags were removed, np, psd and t were added, reporting moved to RFC 9990 (opens in a new tab) and RFC 9991 (opens in a new tab), and a new method replaced the public suffix list for finding a domain's Organizational Domain (Appendix C (opens in a new tab)). Check your own record for the removed tags.

Which document is current

RFC 7489 was published in March 2015 by the Independent Submissions Editor as an Informational RFC, not as the product of an Internet Engineering Task Force (IETF) work stream (RFC 9989 Appendix C (opens in a new tab)). Its datatracker page now marks it obsoleted by RFC 9989, RFC 9990 and RFC 9991 (IETF Datatracker (opens in a new tab)).

RFC 9989 is an IETF Standards Track document. Its datatracker page (opens in a new tab) lists it as a Proposed Standard from May 2026, developed as the draft draft-ietf-dmarc-dmarcbis, and as obsoleting both RFC 7489 and RFC 9091.

RFC 9989 does not cover reports in detail. RFC 9990 (opens in a new tab) covers aggregate reports and RFC 9991 (opens in a new tab) covers failure reports, and both also obsolete RFC 7489.

Check your domain now

See the SPF, DKIM and DMARC records your domain publishes and what to fix first. Free, no account needed.

Create a free account

What changed

A DMARC record is a TXT (text) record in the Domain Name System (DNS) (opens in a new tab) at _dmarc in front of your domain (RFC 9989 section 4.1 (opens in a new tab)). Appendix C (opens in a new tab) of RFC 9989 lists what changed from RFC 7489 (opens in a new tab):

Area RFC 7489 RFC 9989
Status Informational RFC from the Independent Submissions Editor IETF Standards Track
Finding the Organizational Domain A public suffix list The DNS Tree Walk
Removed tags pct, rf and ri were defined Removed; listed as historic in the tags registry (opens in a new tab)
Added tags — np, psd and t, added since RFC 7489 was published
Reports Aggregate and failure reports described in RFC 7489 itself Moved to separate documents, RFC 9990 (opens in a new tab) and RFC 9991 (opens in a new tab)
Report size limit on a report address Allowed Removed
Terms added to the definitions — Seven, including Domain Owner Assessment Policy, Enforcement and Monitoring Mode
p=reject for general-purpose email domains No explicit advice Should not be deployed

The DNS Tree Walk replaces the public suffix list

RFC 7489 found a domain's Organizational Domain with a public suffix list, a list of DNS names reserved for registrations, and called the method a heuristic: no list is guaranteed to be accurate or current (RFC 7489 section 3.2 (opens in a new tab)).

RFC 9989 replaces the list with a discovery technique it calls the "DNS Tree Walk" (section 4.10 (opens in a new tab)). The change can cause interoperability issues: a receiver whose DMARC implementation follows RFC 7489 and relies on a public suffix list might arrive at a different Organizational Domain or record than the Tree Walk. Per RFC 9989, using strict alignment and publishing explicit DMARC records for all your Author Domains avoids the issue entirely (Appendix C (opens in a new tab)); an Author Domain is the domain taken from a message's From header field (section 3.2.2 (opens in a new tab)). In RFC 9989, relaxed alignment is the default for both adkim and aspf (section 4.7 (opens in a new tab)).

Tags: removed, added and still active

Removed. In RFC 7489, pct set the percentage of messages the policy applied to (default 100), rf the format of failure reports and ri the interval between aggregate reports (RFC 7489 section 6.3 (opens in a new tab)). RFC 9989 removed all three, and the DMARC Tags registry now lists them as historic: considered deprecated and not expected to be in use in any current implementation (RFC 9989 section 9.3 (opens in a new tab)). Operational experience showed that pct was usually not applied accurately unless its value was 0 or 100 (Appendix A.6 (opens in a new tab)).

Added. RFC 9989 added three tags (Appendix C (opens in a new tab), section 4.7 (opens in a new tab)):

  • np: the policy for non-existent subdomains, imported from RFC 9091.
  • psd: a flag for whether the domain is a Public Suffix Domain (PSD); public suffix operators set it to y.
  • t: test mode. With t=y, the domain owner asks receivers not to apply the policy but to apply any special handling they have in place, such as rewriting the From header field, and expects failing mail to get one level below the published policy: none instead of quarantine, and quarantine instead of reject. The default, t=n, asks them to apply the policy as published. t does not change reports and has no effect on a policy of none.

RFC 9989 introduces t=y and t=n as analogous to pct=0 and pct=100 in how mailbox providers and intermediaries apply them.

Still active. v, p, sp, rua, ruf, adkim, aspf and fo are active tags in RFC 9989. In both versions v must hold DMARC1, and both versions tell receivers to ignore unknown tags (section 4.8 (opens in a new tab)). p is no longer required: RFC 7489 required both v and p, in that order, while RFC 9989 only recommends p. Tags added to DMARC are meant to avoid changing what existing records mean to receivers that follow earlier versions.

Reporting moved to RFC 9990 and RFC 9991

RFC 7489 described both report types itself: aggregate reports designed to give domain owners precise insight into authentication results, among other things, and failure reports normally sent almost immediately after a receiver detects a DMARC failure (RFC 7489 section 7 (opens in a new tab)).

RFC 9989 moved both to separate documents (Appendix C (opens in a new tab)). RFC 9990 (opens in a new tab) covers aggregate reports and RFC 9991 (opens in a new tab) covers failure reports about individual messages that failed DMARC. You still request them in your DMARC record: rua lists the addresses for aggregate reports and ruf the addresses for message-specific failure information (RFC 9989 section 4.7 (opens in a new tab)).

One option in the record went away. RFC 7489 let a report address carry a maximum report size, for example mailto:reports@example.com!50m for reports up to 50 megabytes (RFC 7489 section 6.2 (opens in a new tab)); RFC 9989 removed it. Its record syntax keeps the ! suffix only as obsolete syntax that reporters should ignore (RFC 9989 section 4.8 (opens in a new tab)).

What large senders publish (live DNS)

Domain _dmarc TXT record
gmail.com v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com
outlook.com v=DMARC1; p=none; sp=quarantine; pct=100; rua=mailto:rua@dmarc.microsoft; ruf=mailto:ruf@dmarc.microsoft; fo=1
google.com v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com
microsoft.com v=DMARC1; p=reject; pct=100; rua=mailto:itex-rua@microsoft.com; ruf=mailto:itex-ruf@microsoft.com; fo=1
yahoo.com v=DMARC1; p=reject; pct=100; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com;

outlook.com, microsoft.com and yahoo.com still publish pct=100, RFC 7489's default value (RFC 7489 section 6.3 (opens in a new tab)), and a ruf address; gmail.com and google.com publish neither. These are observed values, not a template to copy.

What to check in your own record

This is the record DemiSignal's DMARC generator writes for a first monitoring step, using only tags that are active in RFC 9989:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the report address with a working mailbox before publishing. DemiSignal's check reads the public DNS records of the domain you enter, including your DMARC record, with no account needed.

Sources

Tools for this

Frequently asked questions

Is RFC 7489 still the DMARC standard?

No. RFC 9989, published in May 2026, obsoletes it, and RFC 9990 and RFC 9991 took over aggregate and failure reporting. RFC 7489 was an Informational RFC; RFC 9989 is an Internet Standards Track document.

Do I need to change my DMARC record for RFC 9989?

Check it for the removed pct, rf and ri tags and for size limits on report addresses. The v tag still takes the value DMARC1, and p, sp, rua, adkim and aspf are still active.

Is there a replacement for the pct tag?

Partly. RFC 9989 adds the t tag as a replacement for some of what pct did: t=y asks receivers not to apply the policy but to use any special handling they have, and is meant to be analogous to pct=0; failing mail is then expected to get one level below the published policy. t=n, the default, asks for the policy as published.

Check your domain now

See the SPF, DKIM and DMARC records your domain publishes and what to fix first. Free, no account needed.

Create a free account