# How to update your DMARC record for RFC 9989 The **new DMARC specification**, [RFC 9989](https://datatracker.ietf.org/doc/html/rfc9989), 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**. For the full list of changes, read [DMARC is now an IETF Proposed Standard: what's new in RFCs 9989–9991](/blog/new-dmarc-2026). ## 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](https://datatracker.ietf.org/doc/html/rfc9989#name-removal-of-the-pct-tag) 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](https://datatracker.ietf.org/doc/html/rfc9989#name-removal-of-the-pct-tag) 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.