# What is DMARCbis? RFC 9989, the new DMARC standard

> DMARCbis, RFC 9989, is the current DMARC standard. Learn what changed, when it took effect, how to validate your record, and what domain owners need to change.

[DMARCbis](https://datatracker.ietf.org/doc/html/rfc9989) is the IETF Standards Track revision of DMARC, published as RFC 9989 in May 2026. It keeps the familiar `v=DMARC1` record and SPF or DKIM alignment model, while defining updated policy discovery, a policy for non-existent subdomains, and revised tag handling. Existing DMARC records remain usable, but domain owners should review records when they next make a policy change.

## Quick takeaways

- RFC 9989 is the core DMARCbis specification and a Proposed Standard.
- RFC 9989, RFC 9990, and RFC 9991 replace RFC 7489 and RFC 9091, the earlier DMARC specification and its reporting documents.
- DMARCbis records still use `v=DMARC1`, not `DMARC2`.
- The `np` tag can publish a policy for non-existent subdomains.
- DMARCbis retires `pct`, `rf`, and `ri` from the core record model.
- A public DNS check confirms the published record, but it does not prove that production mail passes DMARC.

## Who is affected?

DMARCbis affects domain owners that publish DMARC policy, mailbox providers that evaluate DMARC, and services that generate or process DMARC reports. It is most relevant when an organization maintains an enforced DMARC policy, operates several sending subdomains, or manages many client domains.

The controlling standard is [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989), published as a Proposed Standard in May 2026. It obsoletes RFC 7489, the Informational document that defined DMARC since 2015, along with RFC 9091's experimental PSD extension. Aggregate-report processing is defined separately in [RFC 9990](https://datatracker.ietf.org/doc/html/rfc9990), and failure reporting is defined in [RFC 9991](https://datatracker.ietf.org/doc/html/rfc9991).

DMARCbis does not require every domain to publish a new record immediately. A domain with a valid existing DMARC record can continue to use it. The practical work is reviewing retired tags and deciding whether the new non-existent-subdomain policy fits the domain's DNS and sending design.

For the broader protocol model, see Palisade's [DMARC learning center](/learning/dmarc).

## What are the requirements?

### A DMARC record still identifies itself as DMARC1

RFC 9989 retains `DMARC1` as the record version identifier. A domain owner publishes the record at `_dmarc` under the domain being evaluated. DMARC still evaluates whether SPF or DKIM passes and aligns with the visible From domain under the rules in the core specification.

```text
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com
```

The example is illustrative only. Publish the reporting address and policy that your organization has approved, and verify that the address can receive reports before relying on it.

![DMARCbis record fields showing the familiar DMARC1 version, policy, reporting address, and optional non-existent subdomain policy](/images/editorial/what-is-dmarcbis-rfc-9989-dmarc-standard/what-is-dmarcbis-rfc-9989-dmarc-standard-record.webp "1200x600")

*Source: Palisade.*

The record format is backward compatible in the useful sense: an existing `v=DMARC1` record does not need a version-label change to be understood by a DMARCbis implementation. Do not invent a `v=DMARC2` value. That value is not part of RFC 9989.

### The np tag can set policy for non-existent subdomains

RFC 9989 defines `np` as a requested policy for mail that claims to use a subdomain that does not exist in DNS. It gives domain owners a way to publish an explicit policy for invented subdomain names without changing the policy for subdomains that actually exist.

```text
v=DMARC1; p=reject; sp=quarantine; np=reject; rua=mailto:dmarc-reports@yourdomain.com
```

`np=reject` is appropriate only after checking the domains and subdomains used by real mail streams. If a legitimate sender uses a subdomain that has no DNS presence, the operational result can differ from what the sending team expects.

> Before publishing `np=reject`, inventory legitimate sending subdomains and confirm that each has the DNS presence and authentication configuration its mail path requires.

RFC 9989 defines fallback behavior when `np` is absent. Receivers use the applicable [subdomain policy](/learning/glossary/dmarc-sp) when available, then the organizational-domain policy. The new tag gives a domain owner a more specific option for a name that DNS indicates does not exist.

### DMARCbis changes tag handling and policy discovery

RFC 9989 retires the `pct`, `rf`, and `ri` tags from the core DMARC specification: [the retired `pct` tag](/learning/glossary/dmarc-pct) requested that policy apply to only a percentage of failing mail, `rf` chose a failure-report format, and `ri` requested an aggregate-report interval. Domain owners should not treat a retired tag as a current DMARCbis control. Review older records during normal maintenance, especially where `pct` was used to express a rollout stage.

RFC 9989 also defines a `t` tag for test policy handling. Its purpose is distinct from a percentage-based enforcement instruction. Preserve the exact behavior and receiver discretion described in the standard when documenting or deploying it. A test indicator is not evidence that every receiver will treat mail the same way.

A third added tag, `psd`, identifies whether the record belongs to a Public Suffix Domain. It helps distinguish a Public Suffix Domain from an Organizational Domain during policy discovery, and it matters mainly for public suffix operators and organizations with deeper or less conventional DNS structures. Do not add it without understanding how receiving systems implement RFC 9989.

DMARCbis uses DNS-based policy discovery, commonly described as a DNS Tree Walk, instead of relying on the Public Suffix List for organizational-domain discovery. The receiver walks upward through the DNS labels of the evaluated domain looking for the applicable record, and the algorithm is limited to eight queries. This change is primarily a receiver implementation matter. Domain owners should still publish DMARC records at the correct `_dmarc` locations and test the names they actually use.

## When does the requirement take effect?

RFC 9989 was published in May 2026 as a Proposed Standard. It is the current core DMARC standard, while RFC 9990 covers aggregate reporting and RFC 9991 covers failure reporting.

There is no single sender deadline in RFC 9989 that requires every domain owner to add `np`, remove retired tags, or replace a working DMARC record on a particular day. A mailbox provider can separately set its own sender requirements, enforcement dates, and exceptions. Those provider rules are not created by RFC 9989 itself.

The practical timing is therefore tied to change control. Review the record before a planned policy change, an ESP migration, a new subdomain launch, or a wider domain portfolio audit. If a mailbox provider announces a requirement, use that provider's current documentation for its scope and date.

## How do I implement the requirement?

### 1. Retrieve the current DMARC record

Query `_dmarc.yourdomain.com` through authoritative DNS and at least one public resolver. Record the exact TXT value, including every tag. Do not edit a copied value from an old ticket or dashboard without confirming it is still published.

Use the [DMARC checker](/tools/dmarc) to inspect the public record syntax and discovered policy. A DNS check is a useful starting point because RFC 9989 begins with the published record.

### 2. Identify real sending domains and subdomains

List the domains in visible From addresses, envelope senders, and DKIM signing domains used in production. Include transactional mail, marketing platforms, support systems, and any delegated sending service.

This inventory determines whether an `np` policy is safe. A subdomain used for sending should have an intentional DNS and authentication design. Do not assume a name is unused because it is absent from one application screen.

### 3. Remove retired controls only with an approved replacement plan

If the record uses `pct`, `rf`, or `ri`, review why each tag was added. Retiring a legacy tag can be a clean-up step, but it should not be used to hide an unresolved authentication failure or an incomplete sender inventory.

Where a test-policy signal is appropriate, follow RFC 9989's definition of `t`. Treat it as guidance for DMARC evaluation, not as proof that mail is safe to enforce globally.

### 4. Add an np policy after checking DNS behavior

Choose the `np` value that matches the domain's approved policy. For an already enforced domain with no legitimate mail from undefined subdomains, `np=reject` may align with the intended protection. Test representative real subdomains before publishing the change.

Keep the change narrow. A DMARC record update cannot repair SPF authorization, DKIM signing, or From-domain alignment for a sender that already fails them.

### 5. Publish and allow DNS propagation

Publish the approved TXT record at the correct `_dmarc` label. Query the authoritative nameserver and public resolvers again after the change. Retain the prior value and the planned rollback decision in the change record.

## How do I validate compliance?

Validate at four layers.

First, check DNS. Confirm that authoritative DNS and a public resolver return the intended TXT record. Check relevant subdomain names so that the DNS state matches the `np` decision.

Second, check the sending service. Each service that sends mail for the domain should show its current SPF and DKIM configuration or verification state. A green vendor status is useful evidence, but it does not prove a delivered message used the configured path.

Third, inspect a delivered message from each production path. Read the `Authentication-Results` header to confirm the observed SPF, DKIM, and DMARC outcomes for that message. DMARC result fields and their trust boundary are specified in [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html), so use results added by a trusted receiver or trusted internal system.

Fourth, review DMARC aggregate reports once data accumulates. RFC 9990 defines aggregate reporting, which helps reveal sources and disposition outcomes over time. Reports can identify an unexpected sending source, but they do not guarantee that every future message will authenticate.

![DMARCbis validation flow from public DNS record to sender status, delivered-message headers, and aggregate-report review](/images/editorial/what-is-dmarcbis-rfc-9989-dmarc-standard/what-is-dmarcbis-rfc-9989-dmarc-standard-validation-flow.webp "1200x676")

*Source: Palisade.*

## Keep DMARCbis changes visible after the DNS check

A record check can confirm whether `np`, `t`, and other tags are publicly published. It cannot show which production senders still fail alignment, whether a receiver applies a private policy decision, or whether a new sender appears after the check.

Palisade is AI-first, agent-first DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy step when the evidence supports it, while a human reviews the evidence and applies the change.

[Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=what-is-dmarcbis-rfc-9989-dmarc-standard)

Palisade does not autonomously change your DMARC policy, prove every future message will authenticate, or control a mailbox provider's delivery decision.

For an example of how aggregate data can expose sender requirement failures, read [what Google's DMARC reports say about sender failures](/learning/what-new-insights-do-google-dmarc-reports-provide-about-sender-requirement-failures).

## Sources and further reading

- [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989)
- [RFC 9990: DMARC Aggregate Reporting](https://datatracker.ietf.org/doc/html/rfc9990)
- [RFC 9991: DMARC Failure Reporting](https://datatracker.ietf.org/doc/html/rfc9991)
- [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html)

## Frequently asked questions

### Is DMARCbis the same as DMARC 2.0?

No. DMARCbis is the revision defined by RFC 9989, and a DMARC record still begins with `v=DMARC1`. "DMARC 2.0" is not a record version defined by the standard.

### Do I need to replace my current DMARC record?

No. A valid existing `v=DMARC1` record remains usable under DMARCbis. Review it when you next change policy, especially if it contains retired tags or if you want an explicit policy for non-existent subdomains.

### Does np=reject affect every subdomain?

No. The `np` tag applies to a subdomain that does not exist in DNS. Existing subdomains follow the applicable DMARC policy and their own DNS and authentication configuration.

### Does DMARCbis change SPF or DKIM alignment?

No. DMARCbis keeps the DMARC model in which SPF or DKIM must pass and align with the visible From domain. The revision updates the DMARC standard and related policy behavior, not the underlying SPF or DKIM protocols.

### Can a DMARC checker prove that my mail complies with RFC 9989?

No. A checker can inspect the published DNS record. Compliance also needs evidence from the sending service, delivered-message authentication results, and aggregate reports from real production traffic.