How to update your DMARC record for RFC 9989

The new DMARC specification, RFC 9989, was published in May 2026. The good news is that it keeps the fundamental DMARC mechanism unchanged, so existing records remain valid and you don’t need to relearn how DMARC works.

However, RFC 9989 removes three record tags, introduces three new ones, and changes how receivers discover DMARC records and apply relaxed alignment. In this article, we’ll explain these changes and help you decide whether your domains’ DMARC records need updating.

It’s still “DMARC1”

The DMARC record is changing, but the changes are not considered breaking changes, and therefore the DMARC protocol version stays at “1”.

In practice, this means that your existing record starting with v=DMARC1 is still valid: there’s no “DMARC2” to migrate to because the definitions of the remaining tags have not changed.

v=DMARC1; p=reject; rua=rua@dmarcwise.email

What has changed is that some tags were removed and some were added, as we’ll see in the following sections.

Removed tags

Some DMARC record tags are no longer part of the DMARC record in the new official specification. They’re now classified as historic and should therefore be treated as deprecated.

You can still keep using these tags, but as time progresses DMARC implementations will stop recognizing them. You should therefore avoid relying on them going forward.

The following three tags were removed:

• pct (percentage)
• rf (report format)
• ri (reporting interval)

Let’s go through them in detail.

Removed tag: pct (percentage)

In the obsolete RFC 7489, the pct tag lets domain owners gradually roll out their DMARC policy with message sampling. For example, having pct=50 in a DMARC record asks receivers to apply the policy only 50% of the time.

Unfortunately, this percentage is applied inconsistently by mail servers, with different practical effects depending on the receiving mail server. For this reason, in RFC 9989 the pct tag was removed in favor of the t tag (testing mode, see below).

Although most receivers will continue to support pct for some time, you should not rely only on this tag anymore for policy rollouts. If you currently have pct in your DMARC record, be aware that it will be increasingly ignored by mail receivers. Consider using the new t tag, or both t and pct together.

Removed tag: rf (report format)

In RFC 7489, the rf tag is used to specify the format of failure reports. The only supported format has always been afrf, so this tag was essentially useless and was removed in RFC 9989.

If you’re using the rf tag in your DMARC record, you can safely remove it.

This tag does not affect aggregate reports.

Removed tag: ri (reporting interval)

The ri tag stands for reporting interval and defines the interval in seconds that mail servers should consider when generating aggregate reports.

Most mail servers never respected this tag and used the default of 86400 seconds (1 day). With this tag removed, RFC 9989 now says that mail receivers should send aggregate reports «on at least a daily basis».

While keeping the ri tag in your DMARC record is harmless, it’s likely going to become irrelevant and you should not rely on it.

New tags

The following three tags are new in RFC 9989:

• np (non-existent subdomain policy)
• t (testing mode)
• psd (public suffix domain)

Let’s go through them in detail.

New tag: np (non-existent subdomain policy)

The np tag allows domain owners to define the DMARC policy that should be applied when an email sent from a subdomain fails DMARC and the subdomain does not exist.

Previously, you could specify a policy for the domain where the DMARC record was published (p) and a separate policy for its subdomains (sp). The sp policy applied to both existing and non-existent subdomains.

The new np tag lets you treat the two cases differently. So, to recap:

• p applies to the domain at which the DMARC record was found.
• sp applies to existing subdomains of the Organizational Domain. If sp is omitted, the p policy is used instead.
• np applies to non-existent subdomains of the Organizational Domain. If np is omitted, the sp policy is used instead.

For example, you could have the following DMARC record on example.com:

v=DMARC1; p=none; np=reject;

An email sent from example.com would be subject to the none policy, while an email sent from non-existent-subdomain.example.com would be subject to the reject policy. Existing subdomains would be subject to the p policy.

For DMARC purposes, a domain is non-existent when a DNS query for that domain returns NXDOMAIN.

Practically speaking, this lets your DMARC policy be permissive on real subdomains (e.g. sp=none), while restricting usage of non-existent subdomains (np=reject).

If you’re in this situation, consider adding np=reject to your DMARC record. If you’re already at p=reject / sp=reject, the non-existent subdomain policy is automatically inherited from p/sp.

New tag: t (testing mode)

With the removal of the pct tag, a new tag was introduced to replace it, in RFC 9989.

The new tag is t, which stands for testing mode. It takes two possible values:

• y for testing mode, asking receivers to apply the policy one level below the one specified:
  • a reject policy is treated as quarantine;
  • a quarantine policy is treated as none;
  • a none policy is unaffected.
• n disables testing mode and applies the policy as specified. This is the default.

The RFC describes t=y and t=n as analogous to the old pct=0 and pct=100, but it’s worth being precise: t=y does not disable the policy entirely, it requests the next less strict policy for messages that fail DMARC.

You can use this tag while deploying DMARC to gradually enforce the policy, but be careful: not all mail receivers support RFC 9989 yet, so this tag may not be recognized and the policies specified in the record will apply.

If your aim is to roll out a DMARC policy gradually, consider using both pct and t for a while, to ensure that all receivers understand that you’re testing a new policy.

For example:

v=DMARC1; p=reject; pct=50; t=y;

New tag: psd (public suffix domain)

The psd tag helps mail receivers determine the Organizational Domain during the new DNS Tree Walk. The Organizational Domain is then used to discover DMARC policies and to evaluate relaxed SPF and DKIM alignment.

The tag can have three values:

• y declares that the domain is a Public Suffix Domain, such as a TLD under which independent organizations can register domains. The domain immediately below it is treated as the Organizational Domain.
• n declares that the domain is not a Public Suffix Domain, but is the Organizational Domain for itself and its subdomains.
• u leaves the Organizational Domain unspecified. Unless the DNS Tree Walk finds a record with psd=n or psd=y, the shortest domain where a DMARC record was found is selected as the Organizational Domain. This is the default when the tag is omitted.

For example, publishing psd=n at department.example.com makes it a separate Organizational Domain from example.com. This can be useful for large organizations that delegate the management of parts of their domain.

Most domain owners should leave this tag out. Use psd=n only if you intentionally want to create a separate Organizational Domain, and use psd=y only if you operate a Public Suffix Domain.

Do not assume every receiver supports psd immediately. Receivers implementing the older RFC 7489 will still determine Organizational Domains using a Public Suffix List and will ignore the psd tag.

Behavior change: DMARC record discovery and relaxed alignment

RFC 9989 replaces the Public Suffix List-based mechanism for determining the Organizational Domain with a new DNS Tree Walk algorithm.

Mail receivers now query DMARC records on parent domains, up to a limit of 8 queries, and use the records they find together with the psd tag to determine the Organizational Domain. This Organizational Domain is used to discover the applicable DMARC policy and evaluate relaxed SPF and DKIM alignment.

Here’s an example, taken from the RFC, with the list of queries that the DNS Tree Walk may execute when given the domain name a.b.c.d.e.f.g.h.i.j.mail.example.com:

_dmarc.a.b.c.d.e.f.g.h.i.j.mail.example.com
_dmarc.g.h.i.j.mail.example.com
_dmarc.h.i.j.mail.example.com
_dmarc.i.j.mail.example.com
_dmarc.j.mail.example.com
_dmarc.mail.example.com
_dmarc.example.com
_dmarc.com

(Notice how domains beginning with a through f are skipped.)

The old PSL-based mechanism may execute the following list of queries:

_dmarc.a.b.c.d.e.f.g.h.i.j.mail.example.com
_dmarc.example.com

This means that, in some cases, receivers implementing RFC 9989 may discover a different Organizational Domain or policy than receivers still using RFC 7489.

If you have a complex DNS setup, consider publishing explicit DMARC records for every domain used to send email to avoid this ambiguity.

Other changes

RFC 7489 allowed specifying a maximum report size by appending it to a reporting URI, for example:

v=DMARC1; rua=mailto:rua@dmarcwise.email!10m

RFC 9989 removed this feature, and mail receivers should ignore the size limit if one is present. If your record uses this syntax, you can remove the size limit, like so:

v=DMARC1; rua=mailto:rua@dmarcwise.email

What should you change?

Existing DMARC records remain valid and the defaults for the new tags are sensible, so most domains do not need changes.

However, reviewing your records now will ensure they behave as expected as mail receivers adopt RFC 9989. To summarize, you should consider the following changes:

• Remove the deprecated rf, ri and reporting URI size-limit syntax.
• Do not rely only on pct when testing a stricter policy. Consider using t=y while receivers transition to RFC 9989.
• Consider adding np=reject if you want to protect non-existent subdomains while keeping a less strict policy elsewhere.
• Leave psd out unless you intentionally need to define an Organizational Domain boundary or operate a Public Suffix Domain.
• Publish explicit DMARC records for every domain used to send email to avoid record discovery ambiguities.