DMARCbis, RFC 9989 and the DNS Tree Walk
DNSai.com
DNSai Email
Share

DMARCbis and DKIM2: What RFC 9989 Actually Changes

For eleven years, the most consequential question in email authentication was answered by a file.

Not a DNS record. A file.

Picture a receiver holding a message whose From: domain is a.mail.example.com. It asks DNS for _dmarc.a.mail.example.com and gets nothing back. Now it has to settle a question the message cannot answer for itself: where does this domain's authority actually end? Is the responsible domain mail.example.com? example.com? com? Under the original DMARC specification, the receiver resolved that boundary by consulting the Public Suffix List, a list of registry suffixes that lives outside the DNS entirely. Two receivers holding two different snapshots of that list could reasonably reach two different conclusions about the same message.

On 20 May 2026, the RFC Editor published three documents that ended the arrangement. Most of the coverage went to the policy tags. Far less of it went to the part that shows up on your resolver.

DMARC is now a tree-walking protocol. That is the change worth your afternoon.

What Is DMARCbis?

DMARCbis was the IETF DMARC working group's effort to take an eleven-year-old specification and finish it properly. The output is three RFCs, all Standards Track, all dated May 2026: RFC 9989 for the core protocol, RFC 9990 for aggregate reporting, and RFC 9991 for failure reporting. RFC 9989 states its own scope in one line: This document obsoletes RFCs 7489 and 9091.

That first number matters more than it looks. RFC 7489, the DMARC everybody has been deploying since March 2015, opens by telling you what it is not: This document is not an Internet Standards Track specification; it is published for informational purposes. An Informational document on the Independent Submission stream. For eleven years, one of the load-bearing pillars of email security was, formally speaking, a suggestion.

[RFC7489] was published as an Informational document. This document is published as a Standards Track document. The effect of this change is that DMARC is now on the Internet standards track.

Before that gets oversold: the Datatracker entry for RFC 9989 reads RFC - Proposed Standard (May 2026), and Proposed Standard is the entry-level rung. RFC 2026 is blunt about what that designation requires: Usually, neither implementation nor operational experience is required for the designation of a specification as a Proposed Standard. RFC 6410 later cut the ladder down, replacing the three-tier maturity ladder defined in RFC 2026 with a two-tier maturity ladder. So: rung one of two. That is a real promotion, but any post telling you DMARC is now an Internet Standard has skipped a step.

First, the Correction: DKIM2 Is Not a Standard Yet

If you arrived here because you saw DMARCbis and DKIM2 named in the same breath, this is the paragraph you need.

DKIM2 is not an RFC. It did not ship alongside RFC 9989. It is draft-ietf-dkim-dkim2-spec, an Active Internet-Draft in the dkim working group, currently at revision -04, posted 5 July 2026 and set to expire on 6 January 2027, with a Datatracker state of I-D Exists. The draft says so about itself, in the boilerplate every Internet-Draft carries:

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

Any article that lists RFC 9989, 9990, 9991 and DKIM2 as one set of deliverables is describing something that did not happen. There is real work in that draft, and we will get to it. But it is a proposal, and it changes nothing about the mail you are sending this afternoon.

The DMARC DNS Tree Walk, Traced Query by Query

Here is the centerpiece. Section 4.10 of RFC 9989 defines a procedure it calls the DNS Tree Walk, and it exists because the Organizational Domain does two jobs at once. The RFC lays them out in its opening paragraph: the Organizational Domain of the Author Domain establishes the DMARC Policy Record for that domain when no DMARC Policy Record is published specifically for the Author Domain, and the Organizational Domains of the Author Domain and an Authenticated Identifier are used in determining Identifier Alignment between the two. Policy discovery and alignment. Both used to depend on that external list; both now depend on queries you can run yourself.

The walk numbers labels right to left. The RFC's own worked example uses the same name we started with:

Break the subject DNS domain name into a set of ordered labels. Assign the count of labels to "x", and number the labels from right to left, e.g., for "a.mail.example.com", "x" would be assigned the value 4, "com" would be label 1, "example" would be label 2, "mail" would be label 3, and so forth.

So a receiver evaluating our message issues this sequence. Query the Author Domain first; if there is no valid record there, strip the left-most label and ask again:

; Author Domain: a.mail.example.com (x = 4 labels) 1. _dmarc.a.mail.example.com TXT -> no valid DMARC record 2. _dmarc.mail.example.com TXT -> no valid DMARC record 3. _dmarc.example.com TXT -> "v=DMARC1; p=reject; sp=quarantine; psd=n" single valid record, psd=n -> STOP

Three queries, and the receiver has both answers it needs. Step 6 governs what counts as an answer, and it is stricter than people expect: Records that do not start with a "v" tag that identifies the current version of DMARC are discarded. If multiple DMARC Policy Records are returned for a single target, they are all discarded. If a single record remains and it contains a "psd=n" or "psd=y" tag, stop. Publish two DMARC records at one name and the tree walk does not warn you about it; it throws both away.

DMARC policy record discovery in DNS

Under RFC 9989, a policy record found at the Author Domain itself applies through the p tag. A record found further up the tree, at the Organizational Domain or a Public Suffix Domain, reaches your subdomain through sp for subdomains that exist and np for ones that do not, falling back to p when neither is present.

Where the walk stops is therefore not a trivia question. It decides which tag in somebody's record governs your message.

If the walk finds nothing that stops it, it keeps climbing. Step 7: Determine the target for the next query by removing the left-most label from the target of the previous query. Repeat steps 5, 6, and 7 until the process stops or there are no more labels remaining.

Why Eight Queries, and Not Nine

Which raises the obvious attack. If every additional label is another query a receiver must issue, an attacker publishes a name with sixty labels and makes every receiver on the internet do sixty lookups per message. The RFC saw it coming:

To guard against such abuse of the DNS, a shortcut is built into the process so that Author Domains with more than eight labels do not result in more than eight DNS queries.

Read that carefully, because the mechanism is not a counter. Nothing in the walk increments a variable and gives up at eight. The cap falls out of a rule about labels, stated in step 4: If x < 8, remove the left-most (highest-numbered) label from the subject domain. If x >= 8, remove the left-most (highest-numbered) labels from the subject domain until 7 labels remain. The resulting DNS domain name is the new target for the next lookup.

One rule, two behaviors. Short names lose a label at a time. Long names get truncated to seven labels in a single move, and from there they can only lose one label at a time like everyone else. Watch a nine-label Author Domain go through it:

; Author Domain: a.b.c.d.e.f.g.example.com (x = 9 labels) 1. _dmarc.a.b.c.d.e.f.g.example.com TXT 2. _dmarc.c.d.e.f.g.example.com TXT <- 7 labels: a and b dropped in one move 3. _dmarc.d.e.f.g.example.com TXT 4. _dmarc.e.f.g.example.com TXT 5. _dmarc.f.g.example.com TXT 6. _dmarc.g.example.com TXT 7. _dmarc.example.com TXT 8. _dmarc.com TXT <- no labels remain, walk ends

Count them. Eight. The initial query at the Author Domain, then one query for each of the seven labels the shortcut left standing. Sixty labels produce the same eight, because the sixty-label name is cut to seven before the climb begins. The number eight is not a budget. It is arithmetic.

Trace a Tree Walk Yourself

Every step above is a plain TXT query. Run the same sequence against any domain and watch where the walk would stop.

Look Up TXT Records →

No, This Is Not SPF's Ten-Lookup Limit

The comparison is irresistible and it is wrong, so let's draw it and then break it. SPF's ten-lookup limit, which we cover in detail in our SPF record analysis post, is a sender-side budget. You can spend past it with too many include: mechanisms, and when you do, evaluation fails and the failure is yours.

The tree-walk cap is nothing like that. The receiver applies it, silently, by truncating the name, and the domain owner never sees an error come back. Nobody blows through it. Nobody gets a permerror from it.

And DMARC does not cost eight lookups per message either. Section 4.10.2 is full of shortcuts: if the Author Domain and the authenticated identifier are the same name, if no policy record applies at all, or if the domain owner asked for strict alignment with adkim=s or aspf=s, the comparison collapses to a string match and no walk happens. The flip side is that alignment evaluation can require more than one walk when it does run, potentially one from the Author Domain, one from the SPF-authenticated identifier, and one for each DKIM-authenticated identifier.

What Replaced the Public Suffix List in DMARC

The walk needs to know when to stop, and that is what the psd tag is for. It came originally from RFC 9091, the Experimental Public Suffix Domain extension from 2021, and RFC 9989 folds it into the core protocol and obsoletes the experiment. Proofpoint's engineering team put the change in one sentence:

The new 'psd' tag moves domain boundary signals into DNS, deprecating use of the Public Suffix List.

The tag takes three values, and RFC 9989 describes it as a flag indicating whether the domain is a PSD (plain-text; OPTIONAL; default is "u"). psd=y says this name is a Public Suffix Domain. psd=n says it is not, and that it is the Organizational Domain for itself and its subdomains. psd=u says nothing at all.

Here is the part worth pinning to the wall: the default is the value that does nothing. Only y and n stop the walk. A record with no psd tag is psd=u, and the receiver keeps climbing right past it. If you want a boundary you decided on, rather than one inferred from wherever the climb happens to end, you publish psd=n at your organizational domain. Nobody does this by accident.

And the outcome can move even though your record did not. Proofpoint's warning is the one to keep in mind: A different Organizational Domain can change SPF or DKIM alignment outcomes. Records do not break. Results can shift.

The Difference Between RFC 7489 and RFC 9989

Status is the headline difference; discovery is the deep one. The tags are where all of it finally touches your zone file. DMARC.org's summary of changes puts the DNS item first: Public Suffix List replaced by DNS Tree Walk and Public Suffix Domains (PSD). The tag ledger, per RFC 9989 Appendix C.5 and the IANA DMARC Tag Registry:

  • Added: np, psd, t.
  • Removed: pct (Appendix C.5.2).
  • Historic in IANA: pct, rf and ri, all still pointing at RFC 7489. The reporting pair fell out because reporting itself moved house: aggregate reporting into RFC 9990, failure reporting into RFC 9991.
  • Active and now referencing RFC 9989: v, p, sp, np, adkim, aspf, fo, rua, ruf, psd, t.

Losing pct takes percentage-based rollout with it. In its place, the record signals intent with t, defined as DMARC policy test mode (plain-text; OPTIONAL; default is "n"). For the Author Domain to which the DMARC Policy Record applies, the "t" tag serves as a signal to the actor performing DMARC validation checks as to whether or not the Domain Owner wishes the Domain Owner Assessment Policy declared in the "p", "sp", and/or "np" tags to actually be applied. A declaration of intent instead of a dice roll.

Then there is np, the policy for non-existent subdomains, and it deserves a DNS operator's attention more than a mail admin's. RFC 9989 defines non-existence by reference to RFC 8020: if the response code received for a query for a domain name is NXDOMAIN, then the domain name and any possible subdomains do not exist. Which means np is only as good as your NXDOMAIN. Publish a wildcard in the zone, or run a provider that hands back NOERROR for names you never created, and every subdomain on earth looks like it exists. Your np policy quietly never fires. That is a DNS configuration problem wearing an email costume.

One more item from the same summary, easy to miss and capable of changing pass/fail: DMARC SPF only uses MAIL FROM:, no fallback to HELO.

Does RFC 9989 Break Your Existing DMARC Record?

No. The why matters, though, because this is exactly where vendor posts get sloppy. RFC 9989 does not contain a sentence declaring itself backward compatible. The continuity is structural instead, and you can check each piece yourself: the version tag is still v=DMARC1, the record still lives in a TXT record at _dmarc.<domain>, and Section 4.7 says of the IANA registry that only tags defined in that registry are to be processed; unknown tags MUST be ignored.

That last clause is the whole mechanism. A 2015-era record carrying pct=50 still parses under RFC 9989; the pct tag is simply not processed. Nothing errors. Nothing is rejected.

; still valid under RFC 9989 - pct is ignored, not fatal _dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; pct=50; rua=mailto:[email protected]" ; the same policy expressed in RFC 9989 terms _dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; sp=quarantine; np=reject; psd=n; rua=mailto:[email protected]"

What does not survive the transition unchanged is the result. Your record is stable. The domain a receiver decides is your Organizational Domain is now derived by walking the tree rather than reading a list, and it can land somewhere else than it used to. If you have been living with the older tag set, our DMARC records explainer is the right place to see the shape of a policy record before you start adding psd and np to it.

And Standards Track status is not permission to escalate. Section 7.4 carries the old warning forward without softening it: the use of "p=reject" can be incompatible with and cause interoperability problems to indirect message flows such as "alumni forwarders", role-based email aliases, and mailing lists across the Internet. Eleven years of work, and the mailing-list problem is still the mailing-list problem.

What DKIM2 Actually Proposes

Now the draft. draft-ietf-dkim-dkim2-spec-04 is written by Richard Clayton of Yahoo, Wei Chuang of Google and Bron Gondwana of Fastmail, and it started life as a personal draft series before the dkim working group adopted it on 24 March 2026. Four revisions have landed since.

The problem it is aimed at is stated in the working group charter: DKIM replay exploits the absence of a protected recipient address, where an authorized user of a site sends a message that is signed by that site to a collaborating receiver, which then re-sends the message to other recipients not in the original set of recipients, but without any indication that the message has been re-posted. A valid signature, honestly obtained, then aimed somewhere it was never meant to go.

The draft's answer is to make the message carry its own history:

As a message is transferred from author to recipient systems that alter the body or header fields will provide details of their changes and calculate new hash values. Further signatures will be added to provide a validatable "chain". This permits validators to identify the nature of changes made by intermediaries and apply a reputation to the systems that made changed. DKIM2 also allows recipients to detect when messages have been unexpectedly "replayed" and will ensure that Delivery Status Notifications are only sent to entities that were involved in the transmission of a message.

Per-hop signatures instead of one signature that either survives the journey or does not. It is a serious idea, and it is a long way from your MTA. The DKIM you are running today is the DKIM described in our DKIM explainer, and nothing in an expiring Internet-Draft changes that.

Timing is where the guessing starts. EmailLabs, a vendor blog, forecasts that first deployments at major mailbox providers are forecast for the end of 2026. Full ecosystem rollout will take longer. Treat that as exactly what it is: a forecast published by EmailLabs on 14 May 2026, naming no provider and no individual. A separate individual draft proposing a milter-based rollout path came with its own useful caveat, that it is not a mailbox provider requirement, and not a compliance deadline for senders, per Suped's write-up. There is no DKIM2 deadline. There is no DKIM2 to deploy.

Watch the Climb on Your Own Domain

You do not need a special tool for any of this. The tree walk is a sequence of TXT lookups, which means you can reproduce a receiver's reasoning line by line and see exactly where it would stop.

If you would rather read the result than derive it, a DNSai lookup resolves the domain and parses the published policy out of the raw answer — the p value, the rua address and the email gateway sitting in front of the domain — and the DMARC validator breaks a single record down tag by tag. The manual walk below is still worth doing once: it is how you see which name in the chain answered, which is the whole point of a tree walk.

Windows

Run each step in PowerShell or Command Prompt, working up the name:

nslookup -type=txt _dmarc.a.mail.example.com nslookup -type=txt _dmarc.mail.example.com nslookup -type=txt _dmarc.example.com

macOS

Open Terminal and walk the same labels with dig:

dig +short TXT _dmarc.a.mail.example.com dig +short TXT _dmarc.mail.example.com dig +short TXT _dmarc.example.com

Linux

Same climb, and check the response code as well as the record:

dig TXT _dmarc.mail.example.com +noall +comments +answer

An NXDOMAIN here is not noise. It is the signal np depends on.

Three things to watch while you climb. Whether more than one v=DMARC1 record answers at any single name, which would get all of them discarded. Whether anything on the path publishes psd=n, or the boundary is simply being guessed at. And whether a name that should not exist actually comes back NXDOMAIN instead of catching a wildcard.

For eleven years, the answer to "where does this domain's authority end" came from a list somebody downloaded. Now it comes from wherever the climb stops, on a name you control, in a zone you publish. The message from a.mail.example.com gets the same treatment it always did, right up until the moment a receiver walks past a name where you never planted a fencepost.

Go plant one.

Sources

  1. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) — RFC Editor / IETF, May 2026. https://www.rfc-editor.org/rfc/rfc9989.html
  2. RFC 9989, plain text (Sections 3.2.13, 4.7, 4.10, 7.4 and Appendix C.1) — RFC Editor / IETF, May 2026. https://www.rfc-editor.org/rfc/rfc9989.txt
  3. RFC 9990: DMARC Aggregate Reporting — RFC Editor / IETF, May 2026. https://www.rfc-editor.org/rfc/rfc9990.html
  4. RFC 9991: DMARC Failure Reporting — RFC Editor / IETF, May 2026. https://www.rfc-editor.org/rfc/rfc9991.html
  5. Information on RFC 7489 — RFC Editor, March 2015. https://www.rfc-editor.org/info/rfc7489
  6. Information on RFC 9091 (Experimental DMARC Extension for Public Suffix Domains) — RFC Editor, August 2021. https://www.rfc-editor.org/info/rfc9091
  7. RFC 2026: The Internet Standards Process, Revision 3, Section 4.1.1 — RFC Editor / IETF, October 1996. https://www.rfc-editor.org/rfc/rfc2026.html
  8. RFC 6410: Reducing the Standards Track to Two Maturity Levels — RFC Editor / IETF, October 2011. https://www.rfc-editor.org/rfc/rfc6410.html
  9. RFC 9989 document page — IETF Datatracker, May 2026. https://datatracker.ietf.org/doc/rfc9989/
  10. DMARC Tag Registry (DMARC Parameters) — IANA. https://www.iana.org/assignments/dmarc-parameters/dmarc-parameters.xhtml
  11. DMARC.org home page — DMARC.org, 20 May 2026. https://dmarc.org/
  12. Summary of changes in DMARCbis — DMARC.org, December 2025. https://dmarc.org/2025/12/summary-of-changes-in-dmarcbis/
  13. DMARC RFC 9989 Part 1: What Changed for Domain and Policy Discovery — Proofpoint, 24 June 2026. https://www.proofpoint.com/us/blog/threat-protection/dmarc-rfc-9989-part-1-what-changed-for-domain-and-policy-discovery
  14. draft-ietf-dkim-dkim2-spec, document page and revision history — IETF Datatracker, 5 July 2026. https://datatracker.ietf.org/doc/draft-ietf-dkim-dkim2-spec/
  15. draft-ietf-dkim-dkim2-spec-04, Status of This Memo and front matter — IETF Datatracker, 5 July 2026. https://datatracker.ietf.org/doc/html/draft-ietf-dkim-dkim2-spec-04
  16. DomainKeys Identified Mail Signatures v2 (DKIM2), draft-ietf-dkim-dkim2-spec-04 — IETF, 5 July 2026. https://www.ietf.org/archive/id/draft-ietf-dkim-dkim2-spec-04.html
  17. DomainKeys Identified Mail (dkim) working group charter — IETF Datatracker. https://datatracker.ietf.org/wg/dkim/about/
  18. DKIM2: What It Is and How It Will Change Email Authentication — EmailLabs (vendor blog), 14 May 2026. https://emaillabs.io/en/dkim2-co-to-jest/
  19. New DKIM2 deployment profile draft proposes a milter rollout path — Suped (vendor blog), 23 June 2026. https://www.suped.com/blog/new-dkim2-deployment-profile-draft-proposes-a-milter-rollout-path

Share this article

Related Articles