--- title: "DMARCbis Is Published: RFC 9989, 9990, 9991 Replace 7489" description: "DMARCbis is now Standards Track. RFC 7489 is replaced by RFC 9989, 9990, and 9991 (May 2026). What changed in policy records, tree walk, and reporting." publishedAt: 2026-05-20 tags: ["dmarc", "dmarcbis", "rfc-9989", "rfc-9990", "rfc-9991", "standards", "ietf"] faq: - question: "What is DMARCbis?" answer: "DMARCbis is the IETF revision of DMARC, published in May 2026 as three Standards-Track RFCs: RFC 9989 (core protocol), RFC 9990 (aggregate reporting), and RFC 9991 (failure reporting). Together they obsolete RFC 7489 and promote DMARC from Informational to Proposed Standard for the first time." - question: "What replaced RFC 7489?" answer: "RFC 7489 is obsoleted by three new RFCs published in May 2026: RFC 9989 (Domain-based Message Authentication, Reporting, and Conformance), RFC 9990 (Aggregate Reporting), and RFC 9991 (Failure Reporting). Existing v=DMARC1 records remain valid; the deprecated pct, rf, and ri tags should be removed during your next DNS update." - question: "Is DMARC required now?" answer: "DMARC has always been required by specific mandates (Google and Yahoo for bulk senders, PCI DSS 4.0, NIS2 in the EU). RFC 9989's Standards-Track promotion does not create new requirements but gives auditors a formal standard to cite. Practical adoption pressure comes from receivers, not from the RFC itself." - question: "How do I update my DMARC record for DMARCbis?" answer: "For most domains: remove pct, rf, and ri if present; leave np, psd, and t unset unless you specifically need them; confirm your reporting endpoint has the external-destination verification TXT record. Existing v=DMARC1 records are backward-compatible with the new RFCs." - question: "When were RFC 9989, 9990, and 9991 published?" answer: "All three were published in May 2026 by the IETF DMARC Working Group. RFC 9989 obsoletes RFC 7489 (the 2015 Informational DMARC spec) and RFC 9091 (the PSD tag draft). RFC 9990 and 9991 carve out aggregate and failure reporting into their own Standards-Track documents." - question: "Are existing DMARC records still valid?" answer: "Yes. v=DMARC1 records remain valid under RFC 9989 — the version tag is unchanged. The p, sp, rua, ruf, adkim, aspf, and fo tags all carry the same meaning. Only pct, rf, and ri are deprecated; receivers ignore them rather than reject the record." --- # DMARCbis Is Published: RFC 9989, 9990, and 9991 Replace RFC 7489 DMARC is now a Standards-Track Internet protocol. **DMARCbis** is the IETF revision of DMARC, published in May 2026 as three separate documents: **RFC 9989** (the new core protocol), **RFC 9990** (aggregate reporting), and **RFC 9991** (failure reporting). Together they obsolete **RFC 7489** and promote DMARC from Informational to Proposed Standard (Standards Track) for the first time. This is the **new DMARC RFC** set for 2026 — the canonical DMARC specification going forward. RFC 7489 was originally published in 2015 as an Informational document. After eleven years of operational deployment and one revision attempt (RFC 9091, which added the `psd=` tag), the IETF DMARC Working Group split the protocol into three Standards-Track documents. The core authentication-and-policy work is now in RFC 9989; aggregate reporting moved to RFC 9990; failure reporting moved to RFC 9991. This post is the day-one breakdown of what changed, why it matters, and what to do this week. Read our [DMARC fundamentals guide](/learn/dmarc/) first, then come back here. ## What Changed — at a Glance One sentence — this is the **DMARC RFC 2026 update** at a glance: [**RFC 7489**](https://www.rfc-editor.org/rfc/rfc7489.html) (Informational, 2015) is replaced by three Standards-Track RFCs published — **RFC 9989** (core protocol), **RFC 9990** (aggregate reporting), and **RFC 9991** (failure reporting). DMARCbis is also marketed by some vendors as **DMARC 2.0**, but the RFC numbers are the canonical reference going forward. The mapping:
RFC 7489 (Informational, 2015) Replacement (Standards Track, 2026)
RFC 7489 §1–§6 (core protocol) RFC 9989 Domain-based Message Authentication, Reporting, and Conformance
RFC 7489 §7 (aggregate reports) RFC 9990 DMARC Aggregate Reporting
RFC 7489 §8 (failure reports) RFC 9991 DMARC Failure Reporting
RFC 9091 (psd= tag and tree walk) Merged into RFC 9989
Public Suffix List (PSL) lookup DNS Tree Walk (8-level limit)
pct=, rf=, ri= tags Removed
(no equivalent) New tags: np=, psd=,{" "} t=
forwarded, sampled_out override reasons Removed; policy_test_mode added
**If you operate a DMARC record**: most of your record stays valid. The `v=`, `p=`, `sp=`, `rua=`, `ruf=`, `adkim=`, `aspf=`, and `fo=` tags all keep their RFC 7489 meaning. `pct=`, `rf=`, and `ri=` are deprecated — remove them at your next DNS edit. Optionally adopt the three new tags described below. **If you process DMARC reports**: the XML schema for aggregate reports (RFC 9990) gains optional fields including `discovery_method`, `policy_test_mode`, `generator`, and an optional `envelope_from`. Existing parsers keep working — unknown fields are ignored per XML rules — but updated parsers can use the new data to reduce source-identification ambiguity. **If you build DMARC tooling**: Standards-Track status changes the IETF errata process and the cadence for future revisions. Any future change goes through formal IETF review, not the Informational-RFC working-group consensus that governed RFC 7489. ## Why This Matters: DMARC Is Now Standards Track RFC 7489 was published in 2015 as an _Informational_ RFC. The Informational status meant DMARC was a public reference document but not a formally standardized protocol — implementations couldn't claim "Standards Track" compliance, and the IETF errata process treated it as a community spec rather than a real standard. **RFC 9989 promotes DMARC to Proposed Standard** (Standards Track) for the first time. The promotion is the work of the [IETF DMARC Working Group](https://datatracker.ietf.org/wg/dmarc/about/), with document editors Todd Herr (Valimail) and John Levine (Standcore LLC) shepherding the draft through more than five years of revisions; further contributors are listed in RFC 9989 Appendix D. It took eleven years because Standards-Track promotion requires operational deployment data and demonstrated interoperability across independent implementations. DMARC had to be deployed at scale before the IETF would ratify the spec as a real Internet Standard. **What changes for vendors and auditors**: implementations can now declare compliance with a Standards-Track RFC rather than an Informational one. PCI DSS, NIS2, BOD 18-01, and other compliance frameworks can reference RFC 9989 directly as the canonical DMARC specification. The DMARC specification is now a _standard_, not a community document. That distinction is operational, not aesthetic. It changes how disputes get resolved, how revisions get cut, and how tooling claims correctness. ## RFC 9989 — The New Core DMARC Protocol RFC 9989 is the new core DMARC document. It carries the same scope as RFC 7489 §1–§6 (authentication, alignment, policy, record format, organizational domain discovery) and absorbs RFC 9091 (the `psd=` tag draft). Read the full spec at [rfc-editor.org/rfc/rfc9989.html](https://www.rfc-editor.org/rfc/rfc9989.html). The four substantive changes — terminology, tree walk, removed tags, and new tags — are as follows. ### New Terminology You'll See in Tooling RFC 9989 §3.2 formalizes four terms that competing articles still write informally. Tooling, auditors, and future IETF errata will use these:
Domain Owner Assessment Policy
The formal new name for "DMARC policy" — the p= tag value ( none, quarantine, reject). RFC 9989 §3.2.
Report Consumer
Replaces "report receiver" — the entity that receives aggregate or failure reports at the address in the rua= or ruf= tag. RFC 9989 §3.2.
Monitoring Mode
The formal name for p=none. Signals: collect data, take no enforcement action. RFC 9989 §3.2.
Enforcement
The formal name for p=quarantine and p=reject{" "} collectively. Signals: act on failing mail. RFC 9989 §3.2.
The vocabulary change isn't cosmetic. Auditors, RFC errata, and the next generation of DMARC documentation will use these terms going forward — worth adopting in internal runbooks and ticket titles so your team and your auditors are speaking the same language. ### How DNS Tree Walk Replaces the Public Suffix List RFC 7489 relied on the Public Suffix List (PSL) — a community-maintained list of public suffixes (`.com`, `.co.uk`, `.github.io`) — to determine the **Organizational Domain** for a given mail-sending domain. The PSL had two known problems: it lived outside the protocol (a Mozilla-hosted file with no formal update cadence), and changes propagated asynchronously across implementations. RFC 9989 §4.10 (with the worked example in Appendix B.4) replaces the PSL with a **DNS Tree Walk**: a deterministic algorithm that walks parent domains via DNS lookups until it finds a DMARC record or hits a defined limit. The discovery is in-protocol and works without an external dependency. **The walk terminates at 8 DNS queries.** That number is explicit in the spec. Operationally, no real-world domain hierarchy needs more than five levels, so the eight-query cap bounds lookup cost without breaking valid deployments. For example, the tree walk for `mail.product.example.co.uk` queries: 1. `_dmarc.mail.product.example.co.uk` 2. then `_dmarc.product.example.co.uk` 3. then `_dmarc.example.co.uk` 4. then `_dmarc.co.uk`. The first label with a DMARC record is the **Organizational Domain** for policy purposes.
The new `psd=` tag (`y` / `n` / `u`, default `u` for unknown) lets Public Suffix Operators declare their domain is itself a public suffix — important during the transition while some receivers still consult the PSL. If your domain hierarchy spans more than a single label (most do), the tree walk discovers a parent-domain DMARC record when the leaf has none — so publish at your Organizational Domain to cover all subdomains in one record. ### Removed Tags — `pct`, `rf`, `ri` (and the Testing-Mode Replacement) RFC 9989 removes three tags from RFC 7489. Each had operational problems that showed up across eleven years of deployment: - **`pct=`** (gradual enforcement percentage) — receivers implemented this inconsistently, producing unpredictable results across mailbox providers. RFC 9989 Appendix A.6 and Appendix C.5.2 document the removal and direct operators to the new `t=y` testing-mode tag. - **`rf=`** (report format) — only one value (`afrf`) was ever defined or used. The tag was redundant. - **`ri=`** (report interval) — receivers ignored it in practice. Aggregate reports landed at the receiver's preferred cadence regardless of what operators requested. In the 5.5M domains we scanned for our [2026 State of Email Authentication research](/research/email-authentication/), **2.3% of DMARC records (38,749 of 1,670,975) carry an explicit non-default `pct=` value** — the long tail of partial rollouts that never finished. The top values are `pct=10` (7,513 records), `pct=50` (7,346), `pct=25` (4,594), and `pct=5` (4,108). If your record is one of them, you have two options under RFC 9989: switch to `t=y` (testing mode — all-or-nothing signal that the policy is provisional), or commit to enforcement and drop the percentage entirely. The percentage-based rollout model is gone. [Regenerate your DMARC record without the deprecated tags](/tools/dmarc-generator/) once you've decided. ### New Tags — `np`, `psd`, `t` (With Value Tables) RFC 9989 adds three tags. Most domains can leave all three unset (defaults are safe), but each solves a specific operational problem. **`np=`** (Non-existent subdomain Policy). RFC 9989 §4.7. Values: | Value | Meaning | | ------------ | -------------------------------------------------------- | | `none` | No enforcement on mail claiming a non-existent subdomain | | `quarantine` | Quarantine mail claiming a non-existent subdomain | | `reject` | Reject mail claiming a non-existent subdomain | If unset, `np=` defaults to whatever `sp=` is set to. Use it when you want stricter handling for non-existent subdomains than for legitimate ones (e.g., `p=quarantine`, `sp=quarantine`, `np=reject`). **`psd=`** (Public Suffix Domain). RFC 9989 §4.7. Values: | Value | Meaning | | ----- | ------------------------------------------------------------------------ | | `y` | This domain is a public suffix (mostly ccTLDs and managed-DNS providers) | | `n` | This domain is not a public suffix | | `u` | Unknown (default — receivers fall back to other discovery mechanisms) | Almost no operator needs to set `psd=`. It exists for Public Suffix Operators (PSOs) who want to declare their domain is itself a public suffix during the transition away from PSL dependency. **`t=`** (testing mode). RFC 9989 §4.7. Values: | Value | Meaning | | ----- | -------------------------------------------------------------------- | | `y` | Policy is provisional; receivers should treat enforcement as testing | | `n` | Policy is operational (default) | Use `t=y` during enforcement rollout to signal to receivers that you are testing the policy. Drop it once you commit to enforcement. ## RFC 9990 — Aggregate Reports Get Their Own RFC Aggregate reporting was §7 of RFC 7489. It is now an independent Standards-Track RFC at [rfc-editor.org/rfc/rfc9990.html](https://www.rfc-editor.org/rfc/rfc9990.html). The separation lets aggregate reporting evolve on its own schedule without re-publishing the core authentication protocol every time the XML schema changes. ### XML Schema Changes — `discovery_method`, `policy_test_mode`, `generator` RFC 9990 §3.1.1 (specifically §3.1.1.3 "Report Generator Metadata" and §3.1.1.5 "policy_published") expands the aggregate report XML schema. Existing parsers keep working — unknown fields are ignored per standard XML rules — but updated parsers can use the new data to disambiguate source identification. If your DMARC vendor handles raw report XML for you, skim the field list below and skip to the next section; this depth matters when you build your own parser or audit a third-party one. - **``** (values `psl` or `treewalk`) — signals whether the report-generator used the legacy Public Suffix List or the new DNS Tree Walk to determine the Organizational Domain. - **`policy_test_mode`** — a new enum value of `/` (per RFC 9990 §3.1.6) that replaces the removed `forwarded` and `sampled_out` override reasons. Signals that the receiver applied a policy in testing mode (paired with the new `t=y` tag). - **``** — identifies the reporting software (for example, "Google DMARC 2.0" or "Microsoft 2026"). Lets report consumers attribute schema differences to specific generators. - **``** (optional) — schema version. - **``** (optional) — adds the SMTP envelope sender alongside the existing header-from field for forensic correlation. - **``** attribute — formalizes the MAIL FROM identifier scope for SPF results. RFC 9990 §3.1.1.13 fixes this to a single valid value (`mfrom`); the legacy unscoped `` element is gone. - **`lang` attribute on ``** — internationalization for human-readable strings. DMARCguard's aggregate-report parser already reads the RFC 9990 fields that generators emit today — ``, ``, ``, ``, and the policy-record additions ``, ``, ``. The two newer fields, `` and the `policy_test_mode` reason value, will land once receivers begin populating them — most reports in flight today still rely on implicit PSL discovery, so the operational signal arrives gradually as generators upgrade. If you've never parsed an aggregate report by hand, our walkthrough of [how to read a DMARC aggregate report](/blog/how-to-read-dmarc-report/) covers the legacy XML and is being updated for the new RFC 9990 fields as receivers emit them. ### External-Destination Verification Is Now Mandatory RFC 7489 §7.1 said external-destination verification _SHOULD_ be performed. RFC 9990 §4 ("Verifying External Destinations") promotes this to _MUST_. The mechanic: if your `rua=` or `ruf=` mailbox is at a different domain than the DMARC policy record (for example, `rua=mailto:dmarc@reports.example.net` on a policy record at `_dmarc.example.com`), the report-generator must verify a `_report._dmarc.example.com` TXT record at the destination domain before sending. The verification proves the destination domain consents to receive reports for the policy domain. What this means operationally: confirm your reporting endpoint hosts the external-destination verification TXT record. Without it, RFC 9990–compliant receivers will stop sending you reports. Existing setups that worked under the old SHOULD may quietly stop working as receivers upgrade. ## RFC 9991 — Failure Reports Get Their Own RFC Failure reports (also called forensic reports or ARF reports) were §8 of RFC 7489. They are now an independent Standards-Track RFC at [rfc-editor.org/rfc/rfc9991.html](https://www.rfc-editor.org/rfc/rfc9991.html). Failure reports carry message content, so they are privacy-sensitive — a separate spec lets the privacy and rate-limiting requirements evolve independently. ### The New Rate-Limit MUST for Report Generators RFC 9991 §2 ("DMARC Failure Reports") promotes rate-limiting from SHOULD (in RFC 7489) to _MUST_. The exact text: failure-report generators _MUST_ implement a rate-limiting mechanism to bound the volume of reports they emit. The reasoning is in §2 and §7 (Privacy Considerations): failure reports carry message content, which means unbounded generation creates both privacy exposure (the more reports, the more PII leaked) and DoS-amplification risk (an attacker who can trigger DMARC failures can fan them out to your `ruf=` endpoint). What operators should expect: receivers may generate fewer failure reports than they used to during unusual load patterns. If you depended on every failure producing a report, your monitoring assumptions need updating. [Analyze ARF failure reports including the new RFC 9991 fields](/tools/arf-checker/) with our ARF checker. ### Privacy Considerations (PII in Failure Reports) RFC 9991 §7 adds expanded privacy guidance for what failure reports _SHOULD_ and _SHOULD NOT_ include. The guidance is non-binding (SHOULD, not MUST) but formalizes practices the operational community has converged on. For senders who receive failure reports for someone else's domain — usually the result of a forwarding misconfiguration — RFC 9991 gives you a clearer basis to discard rather than archive the content. The data was never yours to retain. For a deeper treatment of how failure reports work end-to-end, see our [Authentication Failure Reporting Format (ARF) guide](/learn/arf/). ## Mailing Lists and `p=reject` — What RFC 9989 §7.4 Says The longstanding tension between DMARC `p=reject` and mailing lists is now Standards-Track text. RFC 7489 §10.5 sketched the problem in two paragraphs of Informational language. RFC 9989 §7.4 expands that into a normative interoperability statement with six MUST/SHOULD requirements. The problem: mailing lists rewrite or wrap the `From:` header to keep their own DMARC alignment, which breaks alignment for the original author. When the author's domain publishes `p=reject`, receivers following DMARC strictly will drop legitimate list mail. What §7.4 now requires of **senders**: - Domains publishing `p=reject` **MUST NOT** rely solely on SPF and **MUST** apply valid DKIM signatures — DKIM is the only authentication that survives forwarding. - Domains whose users post to mailing lists **SHOULD NOT** publish `p=reject`. - Staged rollout is **SHOULD**: `p=none` for at least one month, then `p=quarantine` for at least one month, comparing aggregate report disposition results before considering reject. - Domains that do publish `p=reject` **SHOULD** tell their users that participation in mailing lists may be hindered. What §7.4 now requires of **receivers** — the genuinely new normative force: - Receivers **MUST NOT** reject messages solely on the basis of a `p=reject` policy. - In the absence of other knowledge and analysis, receivers **MUST** treat such failing mail as if the policy were `p=quarantine`. That second MUST formalises what Gmail, Microsoft 365, and Yahoo already do operationally — receivers downgrade `p=reject` to `p=quarantine` for indirect flows when nothing else corroborates a spoofing signal. RFC 9989 turns that ad-hoc practice into a spec. On **ARC** specifically: RFC 9989 §7.4 names the Authenticated Received Chain ([RFC 8617](https://www.rfc-editor.org/rfc/rfc8617.html)) as "a prominent example" of technical attempts to preserve authentication across forwarders, but the RFC explicitly observes that "none of the methods have become widely used" as of publication. Operationally, ARC is still the best chain-of-custody tool available for forwarders that modify mail, and our deep-dive on [why DMARC fails on forwarded emails and how ARC fixes it](/blog/dmarc-forwarding-arc-fix/) walks through the deployment. But it would misread the RFC to call ARC the "recommended" fix — RFC 9989 reserves that framing for the MUST/SHOULD list above. For where ARC sits in the broader IETF roadmap — and why DKIM2 is being drafted as its eventual successor — see our [ARC → DKIM2 transition guide](/blog/arc-to-dkim2-future/). ## 15 RFC 7489 Errata Addressed in RFC 9989 RFC 9989 Appendix C.9 resolves **15 known errata** from RFC 7489 — see the [full erratum list at rfc-editor.org](https://www.rfc-editor.org/errata_search.php?rfc=7489) for IDs. The three with operational impact for most teams: - **Errata 5365 and 5495**: clarified ambiguity in how the SPF and DKIM identifiers map to DMARC alignment, particularly when multiple DKIM signatures are present on a message. - **Errata 6485**: corrected the formal grammar for the `pct=` tag value range. (`pct=` is now removed entirely in RFC 9989 — the errata is resolved by removal rather than correction.) - **Errata 7099 and 7100**: documented edge cases in the policy override reporting fields that RFC 9990 then formalized via `policy_test_mode`. The remaining twelve cover smaller clarifications and editorial corrections — useful for implementers, mostly invisible to operators. ## What To Do This Week Most operators can finish the audit in under an hour. The four steps below are the most important ones. ### 1. Audit Your DMARC Record Look up your current DMARC record with `dig +short TXT _dmarc.example.com` (replace `example.com` with your domain). Identify whether `pct=`, `rf=`, or `ri=` are present in the response. Note your `rua=` and `ruf=` destinations. If your record fails the audit, our [DMARC fail troubleshooting guide](/blog/dmarc-failed-how-to-fix/) walks the seven most common causes — start there before touching DNS. ### 2. Remove `pct`, `rf`, `ri` If Present Edit your DNS TXT record to drop any deprecated tags. If your record was, for example: `v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc@example.com; rf=afrf; ri=3600` The RFC 9989–clean equivalent is: `v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com` If you used `pct=` for gradual rollout, switch to the new `t=y` testing-mode tag or commit to enforcement and drop the percentage entirely. The percentage-based rollout model is gone. ### 3. Decide on `np`, `psd`, `t` (Most Domains: Leave Defaults) Most operators do not need to set any of the new tags. The defaults are safe and backward-compatible: - Set **`np=`** if you currently use `p=none` or `p=quarantine` and want stricter handling for non-existent subdomains. Common configuration: `np=reject`. If you're still working through enforcement, see [how to fix "DMARC quarantine/reject policy not enabled"](/blog/dmarc-policy-not-enabled-fix/). - Set **`psd=y`** only if you operate a Public Suffix Domain (ccTLDs, managed-DNS providers like `github.io`, hosting providers offering customer subdomains). If you're not sure, you're not one. - Set **`t=y`** during enforcement rollout to signal to receivers that the policy is provisional. Drop it once you commit to enforcement. ### 4. Confirm Your Reporting Endpoint Two checks: 1. **Your `rua=` mailbox accepts mail.** Test with a `dig MX` on the destination domain, then send a test message and confirm delivery. 2. **Your reporting endpoint hosts the external-destination verification TXT record.** Now MUST per RFC 9990 §4 — if missing, compliant receivers stop sending reports. [Parse your most recent aggregate report](/tools/dmarc-report-analyzer/) to confirm reports are flowing through your endpoint. ## Frequently Asked Questions ### What is DMARCbis? DMARCbis is the IETF revision of DMARC, published in May 2026 as three Standards-Track RFCs: RFC 9989 (core protocol), RFC 9990 (aggregate reporting), and RFC 9991 (failure reporting). Together they obsolete RFC 7489 and promote DMARC from Informational to Proposed Standard for the first time. ### What replaced RFC 7489? RFC 7489 is obsoleted by three new RFCs published in May 2026: RFC 9989 (Domain-based Message Authentication, Reporting, and Conformance), RFC 9990 (Aggregate Reporting), and RFC 9991 (Failure Reporting). Existing `v=DMARC1` records remain valid; the deprecated `pct`, `rf`, and `ri` tags should be removed during your next DNS update. ### Is DMARC Required Now? DMARC has always been required by specific mandates ([Google and Yahoo for bulk senders](/blog/google-yahoo-dmarc-requirements/) at 5,000 messages per day, PCI DSS 4.0, NIS2 in the EU). RFC 9989's Standards-Track promotion does not create new requirements, but it gives auditors a formal Internet Standard to cite instead of an Informational document. Practical adoption pressure still comes from receivers, not from the RFC itself. ### How Do I Update My DMARC Record for DMARCbis? For most domains: remove `pct`, `rf`, and `ri` if present; leave `np`, `psd`, and `t` unset unless you specifically need them; confirm your reporting endpoint has the external-destination verification TXT record. Existing `v=DMARC1` records are backward-compatible with the new RFCs. ### When Were RFC 9989, 9990, and 9991 Published? All three were published in May 2026 by the IETF DMARC Working Group after more than five years of drafting and review. RFC 9989 obsoletes RFC 7489 (the 2015 Informational DMARC spec) and RFC 9091 (the PSD tag draft). RFC 9990 and 9991 carve out aggregate and failure reporting into their own Standards-Track documents so each can revise independently. ### Are Existing DMARC Records Still Valid? Yes. `v=DMARC1` records remain valid under RFC 9989 — the version tag is unchanged. The `p`, `sp`, `rua`, `ruf`, `adkim`, `aspf`, and `fo` tags all carry the same meaning. Only `pct`, `rf`, and `ri` are deprecated; receivers ignore them rather than reject the record, so your published record keeps working through the transition. ## Conclusion DMARC is now a Standards-Track Internet protocol. The eleven-year Informational era is over. Three RFCs replace one: **RFC 9989** for the core protocol, **RFC 9990** for aggregate reporting, and **RFC 9991** for failure reporting. Most operators only need to remove `pct`, `rf`, and `ri` from their DNS record — the rest is backward-compatible. The **DMARCbis** publication is the rare news event in this space that changes how every DMARC vendor, auditor, and tooling author cites the specification. Verify your record against the new spec with our [DMARC checker](/tools/dmarc-checker/), then move on with your week.