# DMARCbis and RFC 9989: what changed in DMARC, and what should you do?

URL: https://iblockspam.com/blog/dmarcbis-rfc-9989-what-changed
Last updated: 2026-10-10
Published: 2026-10-10
Topic: SPF, DKIM & DMARC
Author: iBlockSpam Team

> RFC 9989 replaced RFC 7489 in May 2026. What DMARCbis changed (pct, t, np, psd, tree walk, rf and ri) and the few things a domain owner should do now.

## Short answer

RFC 9989 (DMARCbis) replaced RFC 7489 in May 2026 and made DMARC a Standards Track protocol. It removed pct, rf and ri, added t (test mode), np and psd, and swapped the Public Suffix List for a DNS tree walk. Most records keep working unchanged. Replace any pct between 1 and 99, and make sure DKIM is aligned before p=reject.

DMARC has a new specification. In May 2026 the IETF published [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html), long known as "DMARCbis", and it obsoletes the 2015 RFC 7489 that every DMARC guide used to cite. Most domains don't have to touch anything, but a few changes matter, and one of them changes the advice about `p=reject`.

## What is DMARCbis?

DMARCbis is the IETF's revision of DMARC. "bis" is IETF shorthand for a second version of a document. The work produced three RFCs, all published in May 2026:

| Document | Covers | Replaces |
|---|---|---|
| [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) | The DMARC protocol: records, alignment, policy discovery | RFC 7489 and RFC 9091 |
| [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html) | Aggregate (`rua`) reports and their XML format | The reporting sections of RFC 7489 |
| [RFC 9991](https://www.rfc-editor.org/rfc/rfc9991.html) | Failure (`ruf`) reports | The failure-reporting sections of RFC 7489 |

The status change is a big part of the story. [Appendix C.1](https://www.rfc-editor.org/rfc/rfc9989.html#appendix-C) notes that RFC 7489 "was not the product of any IETF work stream" and was published by the Independent Submissions Editor as an Informational RFC. RFC 9989 is an Internet Standards Track document, which means it has IETF consensus behind it.

If you're new to DMARC itself, start with [what DMARC is and how it works](https://iblockspam.com/blog/what-is-dmarc). This guide assumes you already have a record.

## What changed in the DMARC record?

The record format is the same: a TXT record at `_dmarc.yourdomain`, starting with `v=DMARC1`. [Section 4.7](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.7) says receivers must ignore unknown tags, so new tags didn't need a new version number. Appendix C.5 lists the tag changes:

| Tag | Status in RFC 9989 | What it does or did |
|---|---|---|
| `pct` | Removed | Applied the policy to a percentage of failing mail |
| `rf` | Removed | Chose the failure report format |
| `ri` | Removed | Requested an aggregate report interval (default 86400 seconds) |
| `t` | Added | Test mode: `y` or `n` |
| `np` | Added (from RFC 9091) | Policy for subdomains that don't exist |
| `psd` | Added | Marks a public suffix domain, or declares an organizational domain |

The [DMARC record examples](https://iblockspam.com/blog/dmarc-record-examples) guide documents every current tag with copy-paste records. Here's why each change happened.

### pct is gone; t replaces it

RFC 7489 let you apply your policy to, say, 25% of failing mail. [Appendix A.6](https://www.rfc-editor.org/rfc/rfc9989.html#appendix-A.6) explains that in practice the tag "was usually not accurately applied, unless the value specified was either 0 or 100", and that the errors "varied widely from one implementation to another."

Meanwhile `pct=0` had picked up a second meaning. Mailing lists and some mailbox providers treated it as a signal to rewrite the From header, and domain owners used that to see how much of their mail passed through intermediaries. The authors kept that behavior and gave it a clearer name: `t=y` is meant to be analogous to `pct=0`, and `t=n` (the default) to `pct=100`.

Under `t=y`, a receiver applies one level below your policy: `p=quarantine` is treated as `none`, and `p=reject` as `quarantine`. It doesn't affect reporting, and it does nothing when the policy is already `none`.

### np becomes standard

`np` sets the policy for subdomains that return NXDOMAIN, meaning they don't exist at all. It was introduced in experimental RFC 9091; RFC 9989 makes it part of the standard. If `np` is absent, the `sp` policy applies, and if `sp` is absent too, `p` applies. Our [subdomain policy guide](https://iblockspam.com/blog/dmarc-subdomain-policy-sp) covers `sp` and `np` in detail.

### rf and ri are gone

`rf` only ever had one supported value (`afrf`). `ri` asked for a reporting interval, but RFC 7489 itself said anything other than a daily report was handled "on a best-effort basis." Neither tag has a replacement. RFC 9990 describes aggregate reports as "daily (or more frequent)," whatever you ask for.

## How does the DNS tree walk replace the Public Suffix List?

This is the biggest technical change, though most domain owners won't notice it.

DMARC needs your **organizational domain** for two jobs: finding a policy when the From domain has no record of its own, and deciding whether two domains align under relaxed alignment. RFC 7489 found it with a Public Suffix List (PSL), a published list of suffixes like `.com` and `.co.uk`. [Section 4.10](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.10) points out that RFC 7489 never said which list to use or how often to refresh it, so receivers could reach different answers.

RFC 9989 replaces the list with a **DNS tree walk**. The receiver queries `_dmarc` at the domain, then removes the left-most label and queries again, up the tree. Without a `psd` tag in play, the organizational domain is the name with the fewest labels that has a valid DMARC record. To stop abuse, names with more than eight labels are shortened first, so a walk never takes more than eight queries.

Two practical effects:

1. **Your organizational domain is now the highest name with a DMARC record**, not "whatever the registrar sold you". For almost every business those are the same thing.
2. **Records on deep subdomains may be skipped.** [Section 5.1.8](https://www.rfc-editor.org/rfc/rfc9989.html#section-5.1.8) warns that because of the eight-query shortcut, when a From domain has more than eight labels, a record published on one of its parent names that is eight or more labels long is never queried. If you need a specific policy on such a long name, publish the record at that exact name.

### What is the psd tag for?

`psd=y` is for public suffix operators, such as registries, that want to publish DMARC for names under their suffix. Section 5.2 says a public suffix operator that publishes a DMARC record MUST include `psd=y`. Ordinary businesses should leave it out.

`psd=n` says "this name is an organizational domain for itself and its subdomains". Section 5.1.8 describes it as a tool for large organizations whose departments manage their own DNS. It also changes alignment, so don't add it casually.

Appendix C.3 admits the change can cause disagreements between receivers that use the tree walk and receivers still using a PSL. It says the issue is "entirely avoided" by using strict alignment and publishing explicit DMARC records for every From domain you use. For a typical business with one domain and a record at `_dmarc.example.com`, both methods give the same answer.

## What changed for receivers and p=reject?

RFC 9989 is far more explicit about `p=reject` than RFC 7489 was. This is the change most likely to affect your plans.

### Advice to domain owners

[Section 7.4](https://www.rfc-editor.org/rfc/rfc9989.html#section-7.4) says that "domains that host users who might post messages to mailing lists SHOULD NOT publish Domain Owner Assessment Policies of 'p=reject'." Those that want to anyway SHOULD first publish `p=none` "for at least a month," then `p=quarantine` "for an equally long period of time," and compare the results.

It also says domains that publish `p=reject` "MUST NOT rely solely on SPF to secure a DMARC pass and MUST apply valid DKIM signatures to their messages." The reason is forwarding. Forwarded mail "will most likely fail SPF checks," while "DKIM signatures will generally remain valid." Our guide to [forwarding, SPF and ARC](https://iblockspam.com/blog/email-forwarding-breaks-spf-dmarc-arc) explains the mechanics.

### Advice to receivers

Section 7.4 also says receivers "MUST NOT reject incoming messages solely on the basis of a 'p=reject' policy." Without other evidence, they "MUST treat such failing mail as if the policy were 'p=quarantine'." The RFC is candid that this may not change much: it says that "in practice, despite this advice, few Mail Receivers apply any mitigation techniques" for indirect mail.

So `p=reject` remains a request. Some receivers will reject, some will junk, and some will deliver with a warning.

## What else changed?

- **Missing `p` tag.** Section 4.10.1 says a record without a valid `p` is treated as `p=none` only if it has at least one valid `rua` address. Otherwise the receiver applies no DMARC processing.
- **Duplicate records.** If a name returns more than one DMARC record, all of them are discarded. That was already the effect in practice; the tree walk spells it out.
- **Every report address gets reports.** RFC 7489 required receivers to support at least two report addresses. RFC 9989 says a report "SHOULD be sent to each listed URI."
- **No report size limit.** The `!10m` size suffix on report addresses is obsolete, and Appendix C.4 notes it was removed. Receivers should ignore it.
- **A Domain Owner checklist.** Section 5.1 now walks through the steps: aligned SPF, aligned DKIM, a report mailbox, monitoring, then a decision about enforcement. Section 8 says full participation means sending mail that aligns through both SPF and DKIM.
- **New terms.** "Monitoring Mode" means `p=none`; "Enforcement" means `quarantine` or `reject`. "Report Receiver" is now "Report Consumer".

## What do you actually need to do?

For most domains, very little. Work through this list once:

1. **Check your record.** Run the [DMARC Checker](https://iblockspam.com/tools/dmarc-checker). It flags duplicate records, `pct` below 100 and unauthorized outside report addresses.
2. **Replace partial `pct` values.** If you have `pct=25` or similar, updated receivers apply your full policy to everything. Use `t=y` while you test, then remove it. `pct=100` is harmless and can stay or go.
3. **Decide about `pct=0`.** Older receivers still read it, and Microsoft's [DMARC guide](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure) still showed `pct` examples when we checked in October 2026. Adding `pct=0` next to `t=y` keeps both kinds of receiver in test mode.
4. **Remove `rf` and `ri`.** They do nothing now. Leaving them is harmless, but removing them avoids confusion.
5. **Confirm aligned DKIM on every sender**, especially before `p=reject`. The [DKIM Checker](https://iblockspam.com/tools/dkim-checker) shows whether a selector's key is published, and [why DMARC fails](https://iblockspam.com/blog/why-dmarc-fails) covers alignment problems.
6. **Add `np=reject`** if your main policy isn't at reject yet. It blocks mail from invented subdomains without touching real ones.
7. **Think about mailing lists.** If your staff post to outside mailing lists, read section 7.4 before choosing `reject` over `quarantine` for your main domain.

You don't need to change `v=DMARC1`, your report addresses, `adkim`, `aspf` or `fo`.

## What didn't change?

DMARC still asks the same question: did SPF or DKIM pass for a domain that aligns with the visible From address? The policies are still `none`, `quarantine` and `reject`. Relaxed alignment is still the default, and the RFC still notes that "nearly all Domain Owners have found relaxed alignment sufficient." Our guide to [relaxed vs strict alignment](https://iblockspam.com/blog/dmarc-alignment-relaxed-vs-strict) covers when strict makes sense.

Reports still arrive as gzipped XML by email. If an address is on another domain, that domain still has to authorize it with a `_report._dmarc` record; [DMARC rua and ruf reporting addresses](https://iblockspam.com/blog/dmarc-rua-ruf-reporting-addresses) shows how.

Adoption also hasn't changed overnight. In our [scan of the Tranco top 1,000 domains](https://iblockspam.com/research/email-security-top-1000) in October 2026, 38.3% of these large sites still didn't enforce DMARC. The new RFC changes the fine print, not that gap.

## Next steps

- Check your record with the [DMARC Checker](https://iblockspam.com/tools/dmarc-checker), and rebuild it with the [DMARC Record Generator](https://iblockspam.com/tools/dmarc-generator) if it still uses `pct`, `rf` or `ri`.
- Upload a week of reports to the [DMARC Report Analyzer](https://iblockspam.com/tools/dmarc-report-analyzer) and confirm every legitimate sender passes with aligned DKIM.
- Plan your enforcement stages with [moving DMARC from p=none to p=reject](https://iblockspam.com/blog/dmarc-none-to-reject-small-business).
- Watch for unplanned changes. iBlockSpam's [domain monitoring](https://iblockspam.com/features/domain-monitoring) alerts you when your MX, SPF or DMARC record changes.

Browse our other [SPF, DKIM and DMARC guides](https://iblockspam.com/blog/topic/authentication).

## Frequently asked questions

### Is DMARCbis the same as RFC 9989?

Yes. DMARCbis was the working name for the revised DMARC specification while the IETF DMARC working group wrote it. It was published in May 2026 as RFC 9989, with aggregate reporting split out into RFC 9990 and failure reporting into RFC 9991. Together they obsolete RFC 7489, and RFC 9989 also obsoletes RFC 9091.

### Do I need to change my DMARC record because of RFC 9989?

Usually not. The record still starts with v=DMARC1, and p, sp, rua, ruf, fo, adkim and aspf work as before. Change it if you use pct with a value between 1 and 99, because updated receivers ignore pct. Use t=y for testing instead, and consider adding np=reject to block invented subdomains.

### Is the version still v=DMARC1?

Yes. RFC 9989 keeps v=DMARC1 as the only valid value, and it must still be the first tag. New tags didn't need a new version, because receivers must ignore tags they don't know. That's also why old tags like pct, rf and ri don't break a record: updated receivers simply skip them.

### Does RFC 9989 say not to use p=reject?

Not for every domain. It says domains whose users might post to mailing lists SHOULD NOT publish p=reject, because list traffic can be rejected. Domains that do publish p=reject must sign with aligned DKIM and not rely on SPF alone. Non-sending and purely transactional domains are a different case.

### Have Gmail, Outlook and Yahoo adopted RFC 9989?

Large mailbox providers update on their own schedules and don't always announce it. Microsoft's DMARC setup guide, for example, still showed pct examples when we checked in October 2026. Write records that behave sensibly under both versions: avoid pct values between 1 and 99, and treat a t=y stage as real enforcement at some receivers.

## Sources

- [RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)](https://www.rfc-editor.org/rfc/rfc9989.html)
- [RFC 9989, Appendix C: Changes from RFC 7489](https://www.rfc-editor.org/rfc/rfc9989.html#appendix-C)
- [RFC 9990: DMARC Aggregate Reporting](https://www.rfc-editor.org/rfc/rfc9990.html)
- [RFC 9991: DMARC Failure Reporting](https://www.rfc-editor.org/rfc/rfc9991.html)
- [RFC 7489: DMARC (obsoleted by RFC 9989)](https://www.rfc-editor.org/rfc/rfc7489.html)
- [Microsoft Learn: Set up DMARC to validate email in Microsoft 365](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure)

## Free tools for this guide

- [DMARC Checker](https://iblockspam.com/tools/dmarc-checker): Check your policy, reporting and the safe path from p=none to reject.
- [DMARC Record Generator](https://iblockspam.com/tools/dmarc-generator): Build a DMARC record with the right policy, reporting and alignment settings.
- [DMARC Report Analyzer](https://iblockspam.com/tools/dmarc-report-analyzer): Read DMARC aggregate reports (XML, gzip or zip): see who sends as your domain and what fails — runs in your browser.
- [DKIM Checker](https://iblockspam.com/tools/dkim-checker): Validate DKIM keys by selector, including key type and strength.

---

Source: iBlockSpam, https://iblockspam.com/blog/dmarcbis-rfc-9989-what-changed (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt