What changed in DMARC with RFC 9989, and what do I do now?

RFC 9989 is the DMARC standard since May 2026. It replaces RFC 7489, the version from 2015 that most guides still describe, and while it was a draft it was called DMARCbis. You do not need a new record: v=DMARC1 is still the only version, and a mailbox provider ignores a tag it does not know. What changes is a handful of tags. pct is retired, and a new t tag takes over its use for testing. np sets a policy for subdomains that do not exist, and psd is for the registries that run endings such as .com. RFC 9990, published at the same time, sets the format of the aggregate reports.

What changed

It is a standard now. RFC 7489 was published for information only. RFC 9989 is an Internet Standards Track document.
Three tags in, three out. np, psd and t are new. pct, rf and ri are removed. The other tags, such as p, sp, rua and ruf, keep their meaning.
The organizational domain is found in DNS. A mailbox provider on RFC 9989 no longer looks it up in the Public Suffix List. It walks up your domain name one label at a time, looking for DMARC records. The RFC calls this the DNS tree walk.
Reports have documents of their own. Aggregate reports are in RFC 9990, and failure reports, which we call forensic reports, are in RFC 9991.
Reject comes with a warning. RFC 9989 asks that domains whose users might post to mailing lists do not publish p=reject, or reach it only after at least a month at none and as long at quarantine. The section Reject and mailing lists quotes it.

In Mailmoni, the record builder leaves ri and rf out of the record it proposes, and says so for each.

pct is retired

In RFC 7489, pct applied the policy to part of the failing mail, so that a domain could move to quarantine or reject gradually. RFC 9989 removes it. Its appendix A.6 gives the reason: the tag “was usually not accurately applied, unless the value specified was either 0 or 100 (the default), and the inaccuracies with other values varied widely from one implementation to another.” The registry of DMARC tags now lists pct as historic.

What to do with it:

No pct, or pct=100. Nothing. pct=100 means the same as no pct, so you can leave it or remove it.
pct between 1 and 99. Do not count on it to limit the harm. Before you publish it, be ready for the policy to act on all failing mail.
pct=0. Some mailing lists and mailbox providers read it as a signal to rewrite the From address of your messages. RFC 9989 keeps that use under a new name, the t tag below.

In Mailmoni, the policy ladder has p=quarantine; pct=25 as its second step. The readiness rule is the same for every step, so when a domain is ready for this step, its sources already pass as well as full quarantine needs. The Readiness page counts the messages that failed DMARC, then estimates how many of them this step would send to spam from its share. Read the first number as the most the step can send to spam. The DNS check warns when pct is below 100, in this finding. The record builder on the Records tab offers pct, and leaves it out at 100 unless your record already spells it out.

t marks a policy as a test

t=y asks mailbox providers to apply the policy one level below the one you state: p=quarantine; t=y is handled as none, and p=reject; t=y as quarantine. t=n, the default, applies the policy as written. RFC 9989 adds that the tag “does not affect the generation of DMARC reports, and it has no effect on any policy ("p", "sp", or "np") that is "none".” In its place, the RFC asks whoever checks the message to apply “any special handling rules it might have in place, such as rewriting the RFC5322.From header field”. That header is the From address your recipients see. Appendix A.6 says t=y and t=n are meant to work as pct=0 and pct=100 did.

A mailbox provider that still follows RFC 7489 does not know t. RFC 7489 says “unknown tags MUST be ignored”, so that provider applies your policy as written. Publish t=y only with a policy you could accept in full, and remove the tag when you want the policy to apply everywhere.

In Mailmoni, the DNS check reads t. At t=y, the DMARC card says the policy is in test mode, and which policy mailbox providers that follow RFC 9989 apply instead. Readiness counts the policy one level below, as those providers do, so p=reject; t=y is not counted as reject. The record builder has a test mode checkbox, ticked when your record says t=y. The record readiness offers for the next step leaves test mode. A change to t in your record raises the DMARC policy changed alert.

np covers subdomains that do not exist

np sets the policy for mail from a subdomain that does not exist in DNS, such as a made-up billing.example.com in a From address. It takes the same values as p. Without it, such names follow sp, and without sp they follow p. A name does not exist when DNS answers that there is nothing at it or below it. A name with any record, even the address of a website, exists, and sp or p covers it. RFC 9989 takes np from RFC 9091, an experiment that it replaces.

What to do with it:

Consider np=reject early. It acts only on mail that fails DMARC from a name that does not exist, so you can add it while your own domain is still at none.
Check your subdomains first. No service should send for you from a subdomain that has no DNS records of its own. A subdomain that sends as you appears under your domain in Mailmoni once it shows up in a report.
Spell the value right. Under section 4.10.1, when np or sp holds a value that is not valid, a mailbox provider treats the whole record as p=none, as long as rua holds a valid address. A typo in np switches off the policy you have. If the DNS check says your np is not valid, correct it in your DNS.

In Mailmoni, the DNS check reads np and shows it in your record. A value other than none, quarantine or reject gets a warning that the tag is not valid. The record builder has no field for np, so add the tag by hand. When the builder updates your record, it keeps a valid np as written, and leaves out one that is not valid, with a note that says so. A report's page shows np when the report states it, and a change to np in your record raises the DNS record changed alert.

psd is for registries

psd says whether a DMARC record belongs to a public suffix, a name under which other people register their domains, such as .com or .co.uk. RFC 9989 needs it because of the DNS tree walk. A mailbox provider looking for the organizational domain asks for DMARC records name by name, upwards from the From domain, and stops at a record that says psd=y or psd=n.

psd=y is for the operators of public suffixes.
psd=n says the domain is not a public suffix, and is the organizational domain for itself and its subdomains.
psd=u, the default, leaves the answer to the tree walk.

A company domain needs none of them, so leave psd out. If your record has one, the record builder keeps it as written.

Reject and mailing lists

RFC 9989 is more careful about reject than RFC 7489 was. Section 7.4 says: “domains that host users who might post messages to mailing lists SHOULD NOT publish Domain Owner Assessment Policies of "p=reject".” A domain that wants reject anyway should first learn from its reports, “by publishing "p=none" for at least a month, followed by publishing "p=quarantine" for an equally long period of time”.

The reason is forwarding by mailing lists. A message that a list sends on under your From address can fail DMARC, and the RFC notes that such mail “is frequently rejected due to a "p=reject" policy.” The same section tells mailbox providers not to refuse mail on p=reject alone, and to treat it as quarantine when they have nothing else to go on.

So if people at your company write to mailing lists from their work address, quarantine may be the place to stop. Mailmoni's ladder ends at reject, and its readiness rule looks by default at 14 days of reports. To give each step the month the RFC asks for, wait longer before you take it. From Pro up, an admin can also make the rule look back as far as 30 days, on the domain's Readiness page. Forwarded mail explains how list mail shows in your reports.

What RFC 9990 changes in the reports

RFC 9990 sets the format of aggregate reports, which used to be part of RFC 7489. A report is still an XML file, and should be gzipped. What is new in the file:

policy_published carries np, testing, which is the value of t, and discovery_method, which is psl or treewalk and says how the mailbox provider found your record. It has no pct.
A row's disposition can be pass, beside none, quarantine and reject.
An override reason can be policy_test_mode: the message was spared by t=y. The RFC 7489 reasons forwarded and sampled_out are gone.
Every DKIM signature in a report names its selector.
One report covers one domain with a DMARC record. A subdomain with a record of its own gets reports of its own.
The file can carry a version of 1.0, and a generator element that names the program that wrote it.

Mailmoni reads both formats, and its sources, explanations and readiness treat them the same way. A row whose disposition is pass reads as "not applied", as none does: the mailbox provider applied no policy to it.

A report's page shows the policy the report states, np included when it is there. An RFC 9990 report has no pct, so its page shows pct=100, the default.
The API returns testing with each report's policy, and with the policy in a domain's summary.
Override reasons, policy_test_mode among them, show as written when you press Explain on a row, and in the override_reasons column of an export.
Each selector a report names for your own domain joins the DNS check's list, so the DKIM check looks for the key under it.