# DMARCbis Is Here: What the New DMARC Standard Actually Changes for Your Domain

DMARC was re-published in May 2026 as RFCs 9989, 9990, and 9991. Your existing records still work. Here is what actually changed, and what to do about it.

Author: J.A. Watte
Published: July 23, 2026
Source: https://jwatte.com/blog/dmarcbis-the-new-dmarc-standard/

---

If you run a domain that sends email, you may have seen a headline this summer that "DMARC changed." It did. In May 2026 the IETF published DMARCbis, the long-promised revision of DMARC, as three new RFCs. Before anything else, here is the part that matters: your existing DMARC record still works. Nothing you published last year breaks today. Most of the change is in how receiving mail servers evaluate your domain, plus a cleanup of a few tags that were confusing or that almost nobody honored.

That said, the new spec closes a real spoofing hole and gives you cleaner tools for rolling out enforcement. It is worth twenty minutes to understand what moved, because a couple of the additions are worth adopting on purpose.

## What actually shipped

For a decade, DMARC lived in a single document, [RFC 7489](https://www.rfc-editor.org/info/rfc7489), published in 2015. That document was classified Informational, which in IETF terms means it wrote down something the industry had already agreed to do rather than a formal standard. DMARCbis replaces it with three documents, and all of them are on the Standards Track:

1. [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html), the core DMARC protocol
2. [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html), aggregate reporting
3. [RFC 9991](https://www.rfc-editor.org/rfc/rfc9991.html), failure reporting

RFC 9989 formally obsoletes RFC 7489, and it also folds in the older public-suffix experiment, [RFC 9091](https://www.rfc-editor.org/info/rfc9091). The move from Informational to Standards Track is not cosmetic. It is the first time DMARC has been a real internet standard, and it reflects how central the protocol became to inbox security over the last ten years. This was not rushed, either. The working group started the revision in late 2020 and went through 41 drafts before the RFCs came out, so the version you are reading about is heavily reviewed.

## The biggest change: how receivers find your organizational domain

The single most significant update is invisible in your DNS record but changes how every receiver treats you. It is about finding your organizational domain, the boundary between "the part you own" and "the public registry above you."

Old DMARC solved this with the Public Suffix List, a community-maintained file that every validator had to download and trust to know where a domain truly begins. That worked, but different implementations shipped different copies of the list, refreshed on different schedules, so two receivers could disagree about your boundary.

DMARCbis replaces the list with an algorithm it calls the DNS tree walk (RFC 9989, section 4.10). A receiver starts at the domain in your `From` address, queries `_dmarc` there, then removes the leftmost label and asks again, climbing the tree until it finds the record that marks your boundary. To stop a hostile domain with hundreds of labels from turning one message into hundreds of lookups, the walk is capped at eight DNS queries. The practical upshot is that your boundary is now decided by DNS itself, which is more predictable, and a domain owner or registry can declare it directly with the new `psd` tag instead of waiting to be listed in an external file. For almost everyone reading this, the tree walk needs no action on your part.

## The tag changes, in plain terms

Here is the quick reference, then the ones worth explaining.

| Tag | Status in DMARCbis | What it means |
|---|---|---|
| `pct` | Removed | The percentage rollout knob is gone |
| `t` | New | Test mode, the sanctioned way to stage enforcement |
| `np` | New | Policy for subdomains that do not exist |
| `psd` | New | Declares whether a name is a public-suffix domain |
| `sp` | Clarified | Meaningful only on the organizational-domain record |
| `rf`, `ri` | No longer exist | Report format and interval are no longer configurable |
| `p`, `rua`, `ruf`, `adkim`, `aspf`, `fo` | Unchanged | Same syntax and defaults as before |

### `pct` is gone, and `t` takes its job

In theory, `pct` let you apply your policy to a fraction of your mail, so `pct=50` meant "quarantine half of the failures." In practice the tag was widely ignored, and `pct=100` was already the default, so its removal changes nothing for most senders. DMARCbis drops it and adds a cleaner boolean, `t` (test mode), whose default is `n`.

Set `t=y` and you are telling receivers not to enforce your stated policy as written, but to treat failing mail about one level below what your `p` value says. A record at `p=quarantine; t=y` behaves like `none`, and `p=reject; t=y` behaves like `quarantine`. That is exactly what you want while you are validating your sending sources, and it is the officially blessed way to stage the classic `none` to `quarantine` to `reject` progression without the guesswork of a percentage.

### `np` closes a spoofing hole you probably have right now

This is the addition most worth adopting. The `np` tag sets a policy specifically for subdomains that do not exist in DNS at all. Attackers love this gap. They forge mail from a plausible name like `billing.yourdomain.com` that you never created, precisely because a name with no records of its own inherits no policy of its own.

With `np=reject`, you tell receivers to reject mail from any non-existent subdomain, and you do it without changing how your real subdomains are handled. The spec defines a clean fallback: `np` covers non-existent subdomains, `sp` covers subdomains that do exist, and if neither is present the receiver falls back to your top-level `p`. A minimal record that shuts the door looks like this:

```
yourdomain.com   TXT   "v=DMARC1; p=quarantine; np=reject; rua=mailto:dmarc@yourdomain.com"
```

### `psd` is for registries, not for you

The `psd` tag is the counterpart to the tree walk. It lets a name declare its role: `psd=y` means the name is a public suffix (registries and TLD operators), `psd=n` means it is an organizational domain and the walk should stop there, and `psd=u`, the default, means unknown, so use the tree walk. Most senders will never touch it. It exists so the parties who operate suffixes can participate in DMARC directly instead of relying on an entry in an external list.

### `sp` got a clarification

The subdomain policy tag, `sp`, is now explicitly meaningful only on your organizational-domain record, where it governs your existing subdomains. Publishing it on a subdomain's own record does nothing, which is the behavior most implementations already assumed but the old spec never nailed down.

### Reporting moved out, and two knobs vanished

Aggregate and failure reporting were split into their own documents, RFC 9990 and RFC 9991. As part of that cleanup, two tags no longer exist. `rf`, the report-format selector, is gone because aggregate reports are now fixed as gzip-compressed XML (RFC 9990). `ri`, the report-interval request, is gone because receivers send on their own schedule. Your `rua` and `ruf` addresses work exactly as before, so if you already collect reports, nothing about that pipeline changes.

### One security note worth flagging: do not lean on SPF alone

Buried in the security guidance of RFC 9989 is a line that deserves a callout. A domain that publishes `p=reject` must not rely on SPF alone to earn a DMARC pass, and must sign its mail with DKIM. The reasoning is practical: SPF breaks the moment a message is forwarded, while a DKIM signature survives forwarding. Worth noting, an early proposal to drop SPF from DMARC entirely did not make it into the standard, so SPF alignment is still here. The takeaway is to make sure DKIM is signing and aligned before you move to reject, not to treat SPF as your safety net.

## What you should actually do

Short version, in order:

1. **Nothing is on fire.** Your current record is still valid. There is no forced migration and no deadline.
2. **You can drop `pct` if you have it.** If it was `pct=100`, behavior is unchanged. If it was a fractional value you used to phase in enforcement, stop doing that with `pct` and use `t=y` to test instead, then raise `p`.
3. **Add `np=reject` if you send mail.** It kills spoofing from subdomains you never provisioned and does not touch your real ones. This is the highest-value change on the list.
4. **Confirm DKIM is signing and aligned,** especially before you go to `p=reject`. Do not depend on SPF by itself.
5. **Keep reading your `rua` reports.** The standard does not require them, but operationally they are still the single best way to see who is sending as you before you tighten enforcement.
6. **Do not rush to reject.** Monitor, confirm every legitimate source is authenticated and aligned, then enforce. The spec itself warns that `p=reject` can break indirect flows like mailing lists, and that domains whose users post to lists should not publish reject.

One thing to keep separate in your head: the Google and Yahoo bulk-sender requirements from February 2024, the ones that pushed everyone sending more than roughly 5,000 messages a day to publish a DMARC record, referenced the old DMARC and predate these RFCs by two years. They are provider policy, not the IETF standard, and DMARCbis did not change them. They are why so many domains scrambled to publish `p=none` in the first place, but they are a different lever than the spec.

## Check your own domain in about thirty seconds

The [DNS + Email Auth Audit](/tools/dns-email-audit/) on this site now reads the DMARCbis record shape. It parses the new `np`, `psd`, `t`, and `sp` tags, flags a leftover `pct` so you can clean it up, warns when a `t=y` record is quietly not enforcing, and recommends `np=reject` on domains that send. Run your apex domain through it, and if you need to build a fresh record from scratch, the [DNS Records Generator](/tools/dns-records-generator/) will assemble the syntax for you.

If email is part of how you launch or sell, and you want the wider picture of the infrastructure that keeps your mail out of the spam folder, my book [The $97 Launch](https://www.amazon.com/author/jawatte) walks through the deliverability stack in the same plain terms as this post.

## Related reading

- [DNS + Email Auth, Why Broken DMARC Quietly Kills Newsletter Deliverability](/blog/blog-tool-dns-email-audit/), the companion piece to the audit tool.
- [Locking Down a Parked Domain So Nobody Can Spoof It](/blog/blog-parked-domain-email-lockdown/), where `np=reject` and `sp=reject` earn their keep.
- [Email Infrastructure for a Small Business, Without the Enterprise Bill](/blog/blog-email-infrastructure-small-business/), the SPF, DKIM, and DMARC baseline in full.
- [BIMI and MTA-STS Across Two Hosts](/blog/blog-bimi-mta-sts-cross-host/), the next two records to add once DMARC is at enforcement.

## Fact-check notes and sources

- IETF, [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC)](https://www.rfc-editor.org/rfc/rfc9989.html), Proposed Standard, May 2026. The core protocol: tree walk (section 4.10), the `t`, `np`, `psd`, and `sp` tag definitions (section 4.7), and the removal of `pct`.
- IETF, [RFC 9990: DMARC Aggregate Reporting](https://www.rfc-editor.org/rfc/rfc9990.html), May 2026. Aggregate reports fixed as gzip-compressed XML.
- IETF, [RFC 9991: DMARC Failure Reporting](https://www.rfc-editor.org/rfc/rfc9991.html), May 2026.
- IETF, [RFC 7489: DMARC](https://www.rfc-editor.org/info/rfc7489), Informational, March 2015, now obsoleted by RFCs 9989, 9990, and 9991.
- IETF, [RFC 9091: Experimental DMARC Extension for PSDs](https://www.rfc-editor.org/info/rfc9091), obsoleted by RFC 9989.
- IETF, [DMARCbis draft history and milestones](https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/), showing the 2020 start, 41 revisions, and 2025 approval.
- Google, [Email sender guidelines](https://support.google.com/a/answer/81126), the February 2024 bulk-sender requirements, provider policy separate from the IETF standard.

*This post is informational, not legal or security-consulting advice. Mentions of third-party products and services are nominative fair use. No affiliation is implied.*


---

Canonical HTML: https://jwatte.com/blog/dmarcbis-the-new-dmarc-standard/
RSS: https://jwatte.com/feed.xml
JSON Feed: https://jwatte.com/feed.json
Hero image: https://jwatte.com/images/dmarcbis-the-new-dmarc-standard.webp