The New DMARC Standard: RFC 9989/9990/9991 Are Here

The New DMARC Standard: RFC 9989/9990/9991 Are Here

In May 2026, the IETF published a new DMARC RFC set that replaces RFC 7489: RFC 9989 (core DMARC), RFC 9990 (aggregate reporting), and RFC 9991 (failure reporting). DMARCbis, the long-running "next version of DMARC" draft, is now the published DMARC standard.

First, the nature of this article: it is an interpretation of an external source — the official Mailgun blog — not a 16IDC lab finding, and not a full reproduction of the specification. Wherever specific tags, record syntax, or dates appear below, the authoritative reference is the officially published RFC 9989/9990/9991 text.

The reason an engineering-oriented reading is still worth writing is that the distance between "the standard changed" and "here is what I should change" is large. Specification text is written for implementers, and most senders are neither receiver implementers nor standards participants. What they need is a list they can act on. That is what this article provides: each change translated into operational meaning, plus the parts that did not change, explained so they cannot be misread. For the full configuration of the authentication trio, see SPF/DKIM/DMARC Configuration.

1. An Interpretation of an External Source

1.1 Why It Matters

Mailbox providers increasingly expect authenticated, aligned mail as baseline sender behavior. That expectation was not created by any single RFC; it emerged from years of operations, and it means mail that fails authentication, or passes but is not aligned, is handled conservatively by most major receivers.

The updated RFCs do not radically change those expectations. They clarify and formalize practices that many senders and email service providers are already operating under today. That distinction matters: the new standard ratifies a large body of existing practice rather than inventing a new rule set. Almost everything you did to satisfy receiver judgment in the past is still correct.

Three things make it worth attention anyway. First, the specification now has explicit boundaries across three documents, each of which can evolve independently, so you need to know which one covers your question. Second, the policy discovery mechanism changed — a change that lands on receivers but reshapes your intuition about where records must be published. Third, several tags you may be using are explicitly retired, not to force immediate edits but to stop your configuration carrying historical baggage.

1.2 It Is Not an Emergency Weekend Reconfiguration

For senders already using authenticated domains and aligned identifiers correctly, this refresh feels more evolutionary than disruptive. It is closer to documentation modernization than to "reconfigure DNS before Friday."

Working out which group you are in takes one question: in the DMARC aggregate reports you receive today, is the pass rate stable at a high level, and are the failing sources all known and already handled? If yes, nothing here is urgent — clean up your records against the new tags at the next routine review.

If no, the work in front of you has little to do with this update. It is alignment and cleanup you owed anyway, and the new standard simply provides a reason to look at it again.

Calling this "documentation modernization" rather than an emergency has one practical benefit: it lets you avoid tightening policy under business pressure. The classic result of rushed tightening is transactional mail bouncing across the board, and diagnosing that incident costs far more than doing the work in order.

2. One RFC Became Three: Core, Aggregate Reports, Failure Reports

2.1 What Each Document Covers

The most visible change is document structure: what used to be one document, RFC 7489, is now three.

RFC 9989 covers policy and alignment — the core logic of what a sender declares, how a receiver judges alignment, and what happens on failure. RFC 9990 covers aggregate reports — the summary data delivered to the rua address, answering who is sending on your behalf and how much is failing. RFC 9991 covers failure reports — the forensic detail delivered to ruf, including excerpts of the original message.

The immediate benefit is a clearer reading path. To find out which tags to publish, you used to page through long sections about report formats inside a single document; now you open 9989 and you are done. Conversely, to work out why one class of failure dominates an aggregate report, you need to know that the authoritative description of report format lives in 9990.

2.2 The Benefit of Separation and Its Cost

The benefit is independent evolution. Adjustments to report format no longer touch core policy semantics, and clarifications to core policy no longer require redefining report fields. For implementers this is real relief: the blast radius of any single revision is confined to one document.

The cost lands on the operating side: you now carry a map of three documents in your head. Faced with a concrete question, you first decide whether it belongs to core policy, aggregate reporting, or failure reporting before you can find the authoritative answer. There used to be one entrance; now there are three, and lookup costs more.

For ordinary senders that cost can be driven very low with a single rule of thumb: for "what policy should I publish," read 9989; for "what am I seeing in my reports," read 9990; for "why was this specific message judged a failure," read 9991. Day-to-day questions land in 9990 almost every time, because reports are the only continuously visible feedback you get.

3. DNS Tree Walk: The Changes Land Mostly on Receivers

3.1 Walking Up the DNS Hierarchy

The new standard introduces DNS Tree Walk as a policy discovery method: receivers can walk up the DNS hierarchy instead of relying on a static public-suffix list.

To see why this matters, look at what the old mechanism struggled with. To decide which "organizational domain" a message came from, receivers used a public-suffix list to cut the name apart — knowing that example.co.uk is an entire public suffix, they treated a.example.co.uk as belonging to example.co.uk. That list needs continuous maintenance, and its updates always lag the real world: newly created public suffixes, temporary second-level structures, and legacy multi-level naming all make the list's judgment stale.

DNS Tree Walk replaces the source of truth with DNS itself: starting from the message's domain, the receiver walks upward and takes the first level that publishes a DMARC record as the organizational domain. The basis is no longer an externally maintained static list but records published by the domain owners themselves.

This mostly affects very large or complex domain structures, such as the multi-level domain hierarchies found in some .edu and .gov environments — receivers previously relied on the public-suffix list to identify the organizational domain and misjudged whenever the list was out of date; the new mechanism lets them walk up DNS to the first level publishing a DMARC record. It requires implementation changes on the receiver side.

3.2 What Senders Should Do

Most senders should still publish explicit DMARC records on the domains they actively use for mail.

That sentence needs emphasis because Tree Walk is easy to misread as "records are no longer needed since receivers will look upward themselves." The opposite is true: what Tree Walk finds is precisely the first level that publishes a record. If nothing is published anywhere up the chain, the walk finds nothing at all. Publish nothing and there is nothing to discover.

So what the mechanism really means for senders is that the location of your records matters more. Which level you publish at, which subdomains carry their own records, and which rely on inheriting from a parent all directly affect how receivers determine your organizational domain. This matters most in scenarios involving non-existent subdomains — a subdomain invented by an attacker is covered by whatever record sits above it.

Which also explains why the new standard adds a tag specifically for non-existent subdomains (covered in the next chapter): once Tree Walk makes "walk upward" a routine path, what the level above says carries more weight.

4. Tags Added and Retired, and What They Mean in Practice

4.1 The New np and psd Tags

Two tags are new.

np describes a policy for non-existent subdomains. In past practice, attackers commonly sent from an invented subdomain — a name such as billing-secure.example.com that never existed — and receivers had no explicit basis for handling such names. With np, a sender can declare what policy applies to non-existent subdomains instead of hoping the subdomain policy sp covers a name that does not exist at all.

psd marks a public suffix domain. It targets domains that are themselves public suffixes with many unrelated organizations beneath them. Its purpose is to give such domains an explicit semantic for their policy declaration rather than mixing them into the interpretation applied to ordinary organizational domains.

For the overwhelming majority of ordinary senders, np is genuinely useful (it closes a real impersonation surface) while psd is effectively irrelevant unless you operate a public-suffix structure yourself. "Evaluate as needed" is the accurate wording: adding everything is not automatically safer.

4.2 What Retiring pct, rf, and ri Means

The retired tags are pct, rf, and ri; testing behavior is described by a new t tag.

The important one is pct, because it changes a habit many teams rely on. The standard way to tighten policy used to be throttling: p=quarantine; pct=25, applying the policy to only a share of mail, watching for a while, raising the percentage, and finally reaching 100. Under the old specification that was the mainstream gradual path.

Once pct is retired, that path needs a different approach: the way policy state is expressed has changed, and the t tag describes the state of testing behavior more accurately. In other words, where you used to express "I am not fully ready" with a percentage, you now express the same thing with an explicit testing state — from "partially in effect" to "declared as under test." The semantics are clearer, and no one can misread it as "the published policy only applies to a quarter of my mail."

Retiring rf and ri is housekeeping as well: both are obsolete tags that receivers widely ignore in practice, and keeping them only made records dirty — which is why the old-to-new comparison below simply drops them.

One key distinction must be stated to prevent misreading: a retired tag does not mean a broken feature. Receivers are expected to ignore unknown or obsolete tags, which means you can leave your records alone and everything keeps working — existing configurations do not suddenly fail because the spec moved. Senders may remove pct, rf, and ri for cleanliness, but that is a tidy-up, not an emergency repair.

4.3 Old Record to New Record, Line by Line

The difference between old and new records is clearest with an example. Suppose example.com used to publish:

v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected]; ruf=mailto:[email protected]; rf=afrf; ri=86400

Cleaned up against the new spec:

v=DMARC1; p=quarantine; sp=reject; np=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; t=r

Go through it change by change. pct, rf, and ri are dropped — receivers ignored them anyway, so leaving them in was just noise. sp=reject makes the subdomain policy explicit instead of relying on the implicit "inherit from p when absent." np=quarantine is added to cover non-existent subdomains, closing the invented-subdomain surface. t=r states that results are currently being recorded in test mode, replacing the old use of pct to signal "not fully tightened yet."

The two report addresses, rua and ruf, are unchanged — which shows something worth noticing: this cleanup changes how the configuration is expressed, not what you can observe. How reports are collected and where they go works exactly as before.

You can verify the current record at any time with nslookup -type=TXT _dmarc.example.com. The point of checking is not only confirming that a change took effect, but being able to answer, six months later, why the record was written that way.

The overall comparison looks like this:

5. What Did Not Change

5.1 Alignment Is Still the Only Pass Condition

This section matters more than any change above, because it is the concrete content of "the core logic is unchanged."

DMARC still passes when the visible From domain aligns with either the SPF or the DKIM identifier — it does not require both. Alignment is still either strict (exact match) or relaxed (same organizational domain, such as mg.example.com and example.com).

The judgment is therefore still "SPF or DKIM is aligned," never "SPF, DKIM, and DMARC each pass independently." That distinction is extremely useful in troubleshooting: a report row where all three appear to pass and DMARC still fails is telling you about alignment, not authentication. With the direction right, the fix is often one sending domain's configuration rather than a rebuild of the whole authentication setup.

5.2 Domain Alignment Is Not IP Reputation, and a Pass Is Not the Inbox

Domain alignment must also be kept apart from IP reputation: shared versus dedicated IPs affect reputation management and troubleshooting visibility, but they do not change how DMARC alignment is judged.

Passing DMARC only proves the domain is authorized for use; it does not guarantee the inbox — reputation, engagement, and content still decide where the message lands. That boundary will not disappear in any future revision, because DMARC answers "is this message entitled to speak for this domain," not "does the recipient want to read it."

Conflating the two produces a very common misdiagnosis: authentication is complete, DMARC passes, mail still lands in spam, so the standard or the configuration must be at fault. The problem actually sits on the reputation and engagement side and has nothing to do with DMARC. For how the two layers divide their work, see Email Deliverability Optimization.

6. Four Things to Do Now

6.1 Check Whether You Still Depend on pct Throttling

First: check whether your DMARC records still depend on pct throttling.

Concretely, pull the current record for every sending domain and look for pct, rf, and ri. If pct is present, answer one question: is this percentage part of an ongoing tightening process, or is it historical residue set years ago and forgotten?

If the former, replace "partially in effect" with a testing state (t) plus an explicit policy, then tighten only after validating against your own sending traffic — your basis for tightening is your reports, not the publication date of a specification. If the latter, remove it: it is not doing anything.

Second: check whether large numbers of non-existent subdomains are being used.

Look through aggregate reports for sends from subdomains you have never used. If any exist, someone is impersonating your organizational domain through invented subdomains, which is exactly what np addresses. Evaluate adding np, and point it in the same direction as your main policy.

6.2 Confirm the Reports Arrive and Make Alignment the Goal

Third: confirm aggregate reports still arrive and that someone actually reads them.

This step gets skipped most often, because technically "a rua is configured" equals "reports exist." Reports sent to an unread mailbox are no reports at all. The test is concrete: when did someone last make a decision based on a report? If you cannot answer, the loop is currently broken. For day-to-day report review, see Deliverability Monitoring Tools.

Fourth: make alignment, not passing, the real goal.

This is the purpose of the first three. Verify with a header analyzer that the DKIM signature's d= matches the sending domain, that SPF is published correctly on the sending subdomain, and that those domains share an organizational domain with the visible From domain. Three independent passes that do not align is the most common failure shape; treat alignment as the target and a surprising number of otherwise baffling problems dissolve.

One easily forgotten check: if you send through several platforms, inventory the sources themselves. List every verified sending domain and the streams it carries (transactional, marketing, application notifications), then clean up or tighten loose policies that are no longer in use. Pay particular attention to proactive outreach — it should run on a separate subdomain so that complaints cannot drag the main domain down. Details in Cold Email Sending Strategies.

7. What Not to Do, and the Conclusion

7.1 Do Not Push reject Immediately, and Do Not Read Retirement as Breakage

First thing not to do: do not move to p=reject immediately just because the spec was updated.

That remains a decision requiring validation against your own sending traffic. The consequence of p=reject is "reject anything that fails," and how well you understand which traffic fails depends entirely on how long reports have been running and how many business cycles they cover. Pushing to reject before the reports are legible means experimenting on production traffic, and the price of a failed experiment is lost business mail.

Second thing not to do: do not read tag retirement as a broken feature.

Receivers ignore unknown or obsolete tags, so old records keep working with no problem. The only thing a rushed edit can accomplish is introducing a new mistake before you have understood the new semantics. Let your routine review schedule decide when to tidy up, not the publication date of a specification.

While cleaning up, dispel a common confusion: do not conflate this update with DKIM2. DKIM2 is a separate protocol discussion about the signing model and replay protection, it is not currently a requirement, and DMARC judgment today still depends entirely on SPF and DKIM.

7.2 Conclusion

Compressed into three statements.

First, the core logic is unchanged: authenticate your mail, keep identifiers aligned, monitor your reports, and fix streams that do not line up. Those four things are the same four things under any version of the specification.

Second, the changes concentrate in how things are expressed and how policy is discovered: three documents instead of one let each part evolve independently at the cost of knowing which one to read; DNS Tree Walk moves the basis for identifying an organizational domain from a static list to DNS itself, mostly changing receivers, while senders should still publish explicit records on the domains they actively use for mail; np and psd fill semantic gaps, pct, rf, and ri leave the stage, and a t tag now describes testing state.

Third, the priority of actions is decided by your reports, not by the publication date. Confirm someone reads them, then tighten according to them; confirm which tags you actually use, then decide what to remove. To rebuild the authentication foundation first, start from SPF/DKIM/DMARC Configuration; for stronger brand recognition in the inbox once authentication is in place, see BIMI Inbox Logo Implementation Guide; to compare how platforms are tracking the new standard, see Email Service Provider Comparison; and for attributing specific failures and bounces, see Email Bounce Reason Analysis.

One last repetition of what this article is: an interpretation of an interpretation — a reading of a Mailgun official blog post, not a 16IDC lab finding. Every statement about specification text should be checked against the officially published RFC 9989/9990/9991 documents, and if you are making compliance or contractual decisions, read the formal RFCs directly.

Source: Mailgun official blog "mailgun-dmarcbis-is-dead". Specification text and tag changes follow the officially published RFC 9989/9990/9991 documents.