RFC 9989 was published in May 2026. It is crazy to me that email standards are still being published after so many years. After looking deeper into this RFC, I realized there are a lot of hidden gems here. If you are a systems administrator managing an organization subdomain inside a big organization's outer domain, this RFC probably affects how you should set up your DMARC record.
In this blog, we will look specifically into the new "tree walk" algorithm that the RFC describes and how to control when the walk stops as a domain admin.

No more PSL
DMARC used to rely on off-host Public Suffix Lists (PSL) to locate the boundary between public registries and private organizations.
RFC 9989 obsoletes RFC 7489 and RFC 9091 by establishing an in-band discovery algorithm executed directly against authoritative DNS servers. This update lets you maintain full control over domain boundary resolution without submitting external pull requests to third-party repositories.
Dynamic Tree Walks
This is how the new RFC 9989 DNS resolution algorithm works.
The DMARC Tree Walk algorithm starts at the sending domain and climbs toward the top-level domain by trimming left-most labels. Section 4.10 of RFC 9989 mandates that if a domain contains eight or more labels, the receiver trims labels until seven remain, capping total traversal at eight DNS queries.
"eight labels do not result in more than eight DNS queries."
This strict limit prevents DNS query loops.
Also, if a single node returns duplicate DMARC records during traversal, the receiver considers the response as "invalid" and discards all returned records for that node.
There are even complementary reporting standards now under RFC
9990 that help email providers
explicitly record whether policy discovery occurred via psl or treewalk.

How to tell a tree walk to stop
You can explicitly tell the Tree Walk to stop with a "Public Suffix Domain" tag
within the _dmarc record. That is documented in section 4.10 of the RFC.
Setting psd=n indicates that your sub-domain operates as an independent
organizational boundary. This gives sub-organizations immediate policy
sovereignty.

Korean domain hierarchies
In South Korea, admins rely on 2-tier public domain structures (2단계
공공도메인 - second-level public domains) such as co.kr and go.kr. When a
subsidiary operates at sub.company.co.kr, setting Organizational Domain (조직
도메인) boundaries previously depended on external file synchronization.
Under RFC 9989, setting v=DMARC1; psd=n; directly at
_dmarc.sub.company.co.kr tells receiving mail servers to halt the Tree Walk:
the receiver recognizes sub.company.co.kr as the organizational boundary.
How to report (Korea-specific)
If you observe domain impersonation or phishing attacks abusing your organizational boundaries in Korea:
- Report active email phishing to KISA KrCERT/CC (KISA 인터넷침해대응센터). Call the free 118 helpline for immediate incident response support.
- File criminal complaints with the National Police Agency ECRM (경찰청 사이버범죄 신고시스템). Submit cybercrime reports directly through the police investigation portal.
Have you checked whether your subdomains require explicit policy boundaries in DNS?
Explore how we audit domain authentication and penetration testing at Panke or email us at contact@pankeit.com.
References
- RFC Editor — RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) (May 2026, IETF Standards Track)
- RFC Editor — RFC 9990: DMARC Reporting Schema (May 2026, IETF Standards Track)
- KRNIC — KRNIC Domain Management Regulations (한국인터넷정보센터 도메인이름 관리세칙) (September 2026, Domain Management Policy)
