What changed in DMARCbis: RFC 9989, 9990 and 9991
DMARCbis is the name the IETF work went by. It was published in May 2026 as three Standards Track RFCs: RFC 9989 (the protocol), RFC 9990 (aggregate reporting) and RFC 9991 (failure reporting). All three obsolete RFC 7489, and RFC 9989 also obsoletes RFC 9091. For a record you publish, the visible changes are these: pct, rf and ri are removed; t, np and psd are added; and a report address outside your own domain still has to authorize you in its DNS.
How to check your record
- Read the record
dig +short TXT _dmarc.example.com - List the removed tags; no output means none are present
dig +short TXT _dmarc.example.com | grep -oE '(pct|rf|ri)=[^;"]*' - List the added tags; no output means you use none of them
dig +short TXT _dmarc.example.com | grep -oE '(np|psd|t)=[^;"]*'
Check your DMARC record Reads your live record and shows the policy it publishes and your reporting setup.
It is now a Standards Track document
RFC 7489 was Informational. RFC 9989 Appendix C.1:
This document, by contrast, is an Internet Standards Track document.
Tags removed: pct, rf and ri
RFC 9989 Appendix C.5.2, "Tags Removed", quoted as published (the ri line has no colon in the RFC):
pct: Tag requesting application of the DMARC policy to only a percentage of messages. See Appendix A.6 for discussion.
rf: Tag specifying requested format of failure reports.
ri Tag specifying requested interval between aggregate reports.
If your record still carries any of them, Your DMARC record still has pct. RFC 9989 removed it. shows what to change for each one.
Tags added: t, np and psd
RFC 9989 Appendix C.5.1, "Tags Added":
np: Policy for non-existent domains (imported from [RFC9091]).
psd: Flag indicating whether a domain is a PSD.
t: Replacement for some "pct" tag functionality. See Appendix A.6 for further discussion.
t replaces pct=0 and pct=100
Appendix A.6 gives the reason:
Because of the value provided by "pct=0" to Domain Owners, it was logical to keep this functionality in the protocol; at the same time, it didn't make sense to support a tag named "pct" that had only two valid values. This version of the DMARC mechanism, therefore, introduces the "t" tag as shorthand for "testing", with the valid values of "y" and "n", which are meant to be analogous in their application by mailbox providers and intermediaries to the "pct" tag values "0" and "100", respectively.
Section 4.7 defines the tag. The value y does more than switch the policy off: it asks the receiver to apply the policy one level below the one you published.
t: DMARC policy test mode (plain-text; OPTIONAL; default is "n"). For the Author Domain to which the DMARC Policy Record applies, the "t" tag serves as a signal to the actor performing DMARC validation checks as to whether or not the Domain Owner wishes the Domain Owner Assessment Policy declared in the "p", "sp", and/or "np" tags to actually be applied. This tag does not affect the generation of DMARC reports, and it has no effect on any policy ("p", "sp", or "np") that is "none". See Appendix A.6 for further discussion of the use of this tag. Possible values are as follows:
y: A request that the actor performing the DMARC validation check not apply the policy, but instead apply any special handling rules it might have in place, such as rewriting the RFC5322.From header field (see Appendix A.6). The Domain Owner is currently testing its specified DMARC assessment policy and has an expectation that the policy applied to any failing messages will be one level below the specified policy. That is, if the policy is "quarantine" and the value of the "t" tag is "y", a policy of "none" will be applied to failing messages; if the policy is "reject" and the value of the "t" tag is "y", a policy of "quarantine" will be applied to failing messages, irrespective of any other special handling rules that might be triggered by the "t" tag having a value of "y".
np: a policy for subdomains that do not exist
RFC 9989 section 4.7:
np: Domain Owner Assessment Policy (Section 3.2.8) for non-existent subdomains of the given Organizational Domain (plain-text; OPTIONAL). For this tag, the definition of "non-existent subdomain" is the same as that used for "non-existent domains" in Section 3.2.13. The policy expressed by this tag indicates the message handling preference of the Domain Owner or PSO for mail using non-existent subdomains of the prevailing Organizational Domain and not passing DMARC validation. It applies only to non- existent subdomains of the Organizational Domain queried and not to either existing subdomains or the domain itself. Its syntax is identical to that of the "p" tag defined below. If the "np" tag is absent, the policy specified by the "sp" tag (if the "sp" tag is present) or the policy specified by the "p" tag (if the "sp" tag is not present) MUST be applied for non-existent subdomains.
So with no np tag, a non-existent subdomain falls back to sp, and without sp to p. Section 3.2.13 ties "non-existent" to an NXDOMAIN answer. An example record that sets it:
v=DMARC1; p=quarantine; np=reject; rua=mailto:dmarc@example.compsd: for public suffix operators
Section 3.2.15 defines a Public Suffix Domain as one that lets independent organizations register names under it, with ".com", ".org", ".us" and ".co.uk" as its examples. The tag is OPTIONAL and its default is u, which section 4.7 describes as a record "published for a domain that is not a PSD". A record that leaves the tag out is read that way.
The Organizational Domain is found by a DNS Tree Walk
RFC 9989 Appendix C.3:
The algorithms for DMARC policy discovery and for determining the Organizational Domain have been changed. Specifically, reliance on a PSL has been replaced by a technique called a "DNS Tree Walk", and the methodology for the DNS Tree Walk is explained in detail in this document.
The same appendix says receivers still running RFC 7489 code with a public suffix list may reach a different answer, and gives the way around it:
This issue is entirely avoided by the use of strict alignment and publishing explicit DMARC Policy Records for all Author Domains used in an organization's email.
Reporting moved to RFC 9990 and RFC 9991
RFC 9989 Appendix C.4:
Discussion of both aggregate and failure reporting has been moved to separate documents dedicated to the topics.
In addition, the ability to specify a maximum report size in the DMARC URI has been removed.
In RFC 7489 the size limit was a suffix on the URI; its section 6.2 gives mailto:reports@example.com!50m as the example. RFC 9989 no longer defines that suffix.
External report destinations must still authorize you
If your rua address is in another organization's domain, the receiver checks that domain before sending. RFC 9990 section 4:
When a Mail Receiver discovers a DMARC Policy Record in the DNS, and the Organizational Domain at which that record was discovered is not identical to the Organizational Domain of the host part of the authority component of a [RFC3986] specified in the "rua" tag, the following verification steps MUST be taken:
The destination can authorize every domain at once:
A Report Consumer that is willing to receive reports for any domain can use a wildcard DNS record. For example, a TXT resource record at "*._report._dmarc.example.com" containing at least "v=DMARC1" confirms that example.com is willing to receive DMARC reports for any domain.
Failure reports (ruf) follow the same procedure. RFC 9991 section 5:
In case of external destinations, a Mail Receiver who generates failure reports MUST use the Verifying External Destinations procedure described in Section 4 of [RFC9990], substituting the "ruf" tag where the "rua" tag appears in that procedure.
To see whether a destination has authorized you, query the name the procedure builds. A TXT answer beginning v=DMARC1 means yes; no answer means the receiver must ignore that address:
dig +short TXT example.com._report._dmarc.reports.example.netWhich destinations publish the wildcard and which name each customer: Who can receive your DMARC reports.
One cross-reference in the RFCs disagrees with itself. RFC 9989 section 11.6 sends the reader to "Section 3 of [RFC9990]" for this mechanism. In RFC 9990 it is section 4, "Verifying External Destinations", and RFC 9991 section 5 cites it as section 4.
What we do not claim
We quote what the three RFCs say and read what your DNS publishes. We do not state which receivers have implemented RFC 9989 or how any of them treats a record that still carries pct: those choices are theirs, they are not published, and we cannot measure them from here. Humerly's plans are on the pricing page.
Questions
What is DMARCbis?
DMARCbis was the working name for the revision of DMARC. It was published in May 2026 as RFC 9989 (the protocol), RFC 9990 (aggregate reporting) and RFC 9991 (failure reporting). All three obsolete RFC 7489.
Which DMARC tags were removed?
pct, rf and ri. RFC 9989 Appendix C.5.2 lists them as removed.
Which DMARC tags were added?
t, np and psd. RFC 9989 Appendix C.5.1 lists them: np is a policy for non-existent subdomains, psd flags a public suffix domain, and t replaces some of what pct did.
What does t=y do?
RFC 9989 section 4.7 says t=y asks the receiver not to apply the published policy and expects failing mail to get the policy one level below: none instead of quarantine, quarantine instead of reject.
Can my DMARC reports go to another company's domain?
Yes, if that domain authorizes you. RFC 9990 section 4 has the receiver look up a TXT record at yourdomain._report._dmarc.theirdomain, or a wildcard at *._report._dmarc.theirdomain. RFC 9991 section 5 applies the same check to failure reports.
Reviewed by Venkat Nookala, last reviewed 2026-11-01.