Split View: DMARC가 11년 만에 표준이 되다 — RFC 9989의 트리 워크, pct 폐지, 그리고 p=reject 경고

DMARC Becomes a Standard After 11 Years — RFC 9989's Tree Walk, the pct Sunset, and the p=reject Warning

• Introduction — A Protocol Everyone Used but No One Standardized
• What Was Published — DMARC Split into Three Documents
• What Didn't Change First — Your Records Are Still Valid
• The Biggest Change — PSL Out, DNS Tree Walk In
• Tag Cleanup — Why pct Died
• The Operational Principles the Standard Nails Down for the First Time
• What the RFC Admits Itself — The Mailing List Problem Remains Unsolved
• The SPF -all Blind Spot — Rejections That Never Hit the Reports
• Where Implementations Stand
• Practical Checklist — What to Do Now, and What You Can Skip
• Closing
• References

Introduction — A Protocol Everyone Used but No One Standardized

This starts with an odd fact. Gmail and Yahoo have effectively mandated DMARC for bulk senders since 2024, banks and government agencies get audited on their adoption status, and an entire email-security startup ecosystem is built on top of it — yet RFC 7489, the document that defines DMARC, was never an IETF standard. Published in March 2015, it is an Independent Submission that never went through IETF working-group consensus, and its classification is Informational. Looking only at the document's status, the entire world's email authentication has run for 11 years on top of a document that essentially recorded "here is what someone is doing."

That ended in May 2026. The IETF DMARC working group's so-called DMARCbis effort was published as RFC 9989, making DMARC a Standards Track document and obsoleting both RFC 7489 and RFC 9091 (the experimental document that covered PSD DMARC). Per the datatracker, it is draft revision 41, an 83-page result.

You might wave this off as "congratulations on becoming a standard," but this revision actually changes the protocol's behavior. The algorithm for finding the organizational domain has been swapped out wholesale, a handful of tags have disappeared and appeared, and above all, operational principles that had long been the community's tribal knowledge are now nailed down for the first time in MUST and SHOULD NOT language. Let's go through it one piece at a time. (If SMTP and DNS themselves are unfamiliar territory, DNS and Email Protocols is worth reading first.)

What Was Published — DMARC Split into Three Documents

The single RFC 7489 spec has been split into three documents. All of them were published together in May 2026, and all of them are Standards Track.

• RFC 9989 — the DMARC core. Policy record syntax, alignment evaluation, policy discovery. It obsoletes RFC 7489 and RFC 9091. The editors are T. Herr of Valimail and J. Levine of Standcore.
• RFC 9990 — aggregate reporting. The XML report format and transport method were split off into this document.
• RFC 9991 — failure reporting. It updates RFC 6591.

Splitting off the reporting spec is not mere document housekeeping — it is a structural change that lets the reporting format evolve independently of the core going forward. For reference, RFC 9989's Appendix C.9 also records item by item how each of the 15 errata that accumulated against RFC 7489 over 11 years was disposed of.

What Didn't Change First — Your Records Are Still Valid

The single most important fact for practitioners is this: the version string stays the same. RFC 9989's definition of the v tag still specifies v=DMARC1 as the only valid value (case-sensitive, and it must be the record's first tag). The "DMARC2 is coming" rumor that once circulated in the community never materialized. Whatever record sits in DNS today remains valid under the new spec, and there is no migration event of any kind.

The reason this is possible lies in the spec's extension rule — because unknown tags MUST be ignored, adding a new tag never requires a version bump. That is exactly why the t, np, and psd tags we will see below could all be added inside v=DMARC1. Conversely, a retired tag like pct simply becomes an "unknown tag" to a new-generation receiver and is silently ignored.

The Biggest Change — PSL Out, DNS Tree Walk In

Under RFC 7489, the method for determining the Organizational Domain was the Public Suffix List (PSL). RFC 7489 itself was aware of the problems with this approach — it never mandated which PSL to use (it only suggested publicsuffix.org), gave no guidance on update cadence, and acknowledged that different receivers using different PSLs would create interoperability problems, writing that the method "should be replaced" once something more reliable came along. A volunteer-maintained list file living outside the IETF serving as the reference point for the whole world's email policy determination was always an uncomfortable dependency.

RFC 9989 replaces this with a DNS tree walk. Instead of an external list, it walks straight up the DNS hierarchy looking for a DMARC record.

Here is how it works. First, it queries the TXT record at the sender domain (the domain in RFC5322.From) with _dmarc. prepended; if there is none, it strips off labels one at a time and climbs upward. There is a cap on the number of queries to prevent DoS — up to 8 queries. A domain with more than 8 labels skips the middle and jumps straight to the point 7 labels from the right. Taking the RFC's own example, the full tree walk for a 13-label domain finishes in exactly the following 8 lookups.

Sender domain: a.b.c.d.e.f.g.h.i.j.mail.example.com

1. _dmarc.a.b.c.d.e.f.g.h.i.j.mail.example.com   (original domain)
2. _dmarc.g.h.i.j.mail.example.com               (jump to the rightmost 7 labels)
3. _dmarc.h.i.j.mail.example.com
4. _dmarc.i.j.mail.example.com
5. _dmarc.j.mail.example.com
6. _dmarc.mail.example.com
7. _dmarc.example.com
8. _dmarc.com

The rationale for setting the cap at 8 is also in the document — at publication time, observed data showed real-world sending domains going up to 7 labels, plus one extra for headroom.

The rule for picking the organizational domain among the records found while walking up is tied to the new psd tag. Summarized:

• If a valid record has psd=n, that domain is the organizational domain. Done.
• If a record encountered along the walk has psd=y (a declaration that this is a public-suffix-level domain), the domain one label below it is the organizational domain.
• If neither is present, the name with the fewest labels among those where a valid record was found is the organizational domain.

This design lets PSD DMARC — the public-suffix-level policy (for example, a country-TLD operator blocking impersonation of non-existent domains beneath it) that RFC 9091 tried experimentally — get absorbed into the core spec without a separate registry. RFC 9989 dryly records the experimental result for 9091 as "not implemented as written" and obsoletes it.

The transition-era trap is spelled out in the spec too. A receiver implementing RFC 7489 (PSL-based) and one implementing RFC 9989 (tree walk) can arrive at different organizational domains, and therefore different policies and different alignment verdicts, for the same piece of mail. The spec offers two workarounds — publish an explicit DMARC record on every domain actually used for sending, and use strict alignment. If the sending domain itself has a record, either kind of receiver terminates on the very first query before any walking happens, so the algorithmic difference never surfaces.

Tag Cleanup — Why pct Died

This revision adds three tags (np, psd, t) and removes three (pct, rf, ri).

The story behind retiring pct is a good one. It was originally meant as a gradual-rollout device — "apply the policy to only N% of mail" — but the operational experience recorded in RFC 9989's Appendix A.6 is this: values other than 0 and 100 were rarely applied precisely, and implementations varied widely. Yet pct=0 alone survived, for a completely different purpose. Some intermediaries (mailing lists, etc.) and mailbox providers started reading pct=0 as a signal that "this domain is about to turn its policy on" and using it as a trigger to rewrite the From header so as to avoid DMARC failures. From a domain owner's perspective, comparing aggregate reports before and after turning on pct=0 let you estimate "how much traffic goes through intermediaries that don't rewrite From" — genuinely useful for deciding whether it was safe to move to enforcement.

So instead of keeping a percentage tag whose valid values were effectively just two, RFC 9989 distilled out only the surviving function and replaced it with the t tag (testing). t=y corresponds to pct=0, and the default t=n corresponds to pct=100. The meaning of t=y is precisely defined — it is a request to the verifier not to apply the declared policy as-is, but to apply it one notch lower. With t=y, p=reject is treated like quarantine, p=quarantine is treated like none, and it has no effect on report generation.

The np tag was imported from RFC 9091, and it is a policy for non-existent subdomains (NXDOMAIN, per RFC 8020 semantics). The fallback order is: if there is no np, use sp; if there is no sp either, use p. In practice, this is a tool you can use immediately against subdomain impersonation — you can observe real, existing subdomains under sp=none while immediately blocking impersonation of names that don't exist at all under np=reject.

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; t=y; sp=none; np=reject; rua=mailto:dmarc-rpt@example.com"

The rf (failure report format) and ri (report interval) tags were removed, and the syntax for specifying a maximum size on a report URI is also gone (the old syntax is now ignored). The reporting details now live in the territory of RFC 9990/9991.

The Operational Principles the Standard Nails Down for the First Time

In my view, the real weight of this revision lies here rather than in the algorithm. Things that were tribal knowledge — "everyone just does it this way" — for the past decade have become normative language (MUST/SHOULD) for the first time. The following is drawn from sections 7.4 and 8 of RFC 9989.

First, p=reject domains must not rely on SPF alone (MUST NOT). DKIM signing is mandatory (MUST). The reason is forwarding. In mail flows that relay messages — alumni mail relays, role-based aliases, and the like — SPF is almost guaranteed to break, because the sending IP the final recipient sees belongs to the relay, not the original sender. DKIM signing, by contrast, survives relaying as long as the body isn't modified. If a domain that used to pass DMARC on SPF alone turns on p=reject, legitimate relayed mail gets silently dropped.

Second, a domain where ordinary users send mail should not publish p=reject (SHOULD NOT). If employees or members can post to internet mailing lists from a domain, p=reject inflicts real damage on those lists and their subscribers. The spec even lays out a procedure if you must go there — p=none for at least one month, then p=quarantine for the same period, and only decide after comparing the disposition results in the aggregate reports. It also implies that a domain that only sends machine-generated transactional mail, like a bank's, and a domain where people freely write mail, deserve different policies.

Third, a receiver must not reject mail on the sole basis of p=reject (MUST NOT). Without other supporting analysis, a DMARC failure alone must (MUST) be treated like p=quarantine. In other words, the sending domain's policy declaration is input for the receiver to consider, not a command — what large receivers like Gmail have actually done in practice has become the standard's own sentence.

Section 8, which defines a checklist for "full DMARC participation," is also worth a look. Domain owners are expected to have both aligned SPF and aligned DKIM, set up an aggregate-report inbox and actually analyze it, and publish records on both the sending domain and the organizational domain. Receivers are expected to send aggregate reports at least once a day (SHOULD).

What the RFC Admits Itself — The Mailing List Problem Remains Unsolved

Section 7.4 contains a paragraph unusually candid for a standards document. Paraphrased: despite all the advice above, in practice almost no receiver applies mitigations for indirect mail flows, almost no organization considers the impact on its own users' indirect mail, and nothing in this document seems likely to change that reality. As a result, mail that passes through mailing lists without modifying From is frequently rejected because of p=reject, and over the past decade every piece of list software has adopted a From-rewriting workaround — a fact the document records as now settled.

So how far has the technology that could save lists without rewriting From actually come? The candidate RFC 9989 names directly is ARC (Authenticated Received Chain, RFC 8617), and its assessment is unsentimental — "none of the methods have become widely used." In fact, RFC 8617 has sat at Experimental status since 2019 and remains there today. The section closes with a line saying the document will be updated once such a method achieves wide adoption. In short, DMARC's oldest side effect remains an open problem even after standardization, and the standard says so itself.

The SPF -all Blind Spot — Rejections That Never Hit the Reports

One operational trap flagged in Section 7.1 deserves separate mention. SPF can be evaluated early in the SMTP transaction, before the message body is even transmitted. That means mail from a domain whose SPF record ends in a hard fail (-all) can be rejected before DMARC processing even begins. The problem here is two layers deep.

• Mail that would have passed under DMARC — because it carries an aligned DKIM signature — can get cut off first at the SPF stage.
• Because mail rejected before the DATA stage never gets far enough for the From domain to be revealed, it never shows up in the aggregate reports at all.

If you're using DMARC aggregate reports to monitor your sending posture, early rejections caused by -all happen entirely outside that monitoring net. This is the point where "the reports look clean" and "all my mail is actually getting through" become two different claims, and any domain using -all needs to be aware of this blind spot. Controlling rejection through DMARC policy on top of a soft fail (~all) and solid DKIM alignment is the better choice for visibility.

Where Implementations Stand

Two months after publication, we are clearly in a transition period. A few checkable data points:

• OpenDMARC opened a gap-analysis issue against RFC 9989/9990/9991 on 2026-05-27 and is tracking it, and a walk_mode selection PR that lets you choose organizational-domain discovery among the legacy 7489 walk, PSL, the 9989 tree walk, or automatic was merged into the develop branch on 2026-06-21. Even in a reference-grade open-source implementation, the tree walk has only just landed in a development branch.
• The Dutch government-affiliated diagnostic tool Internet.nl also has an open issue tracking the PSL-to-tree-walk swap.
• Gmail's sender guidelines are, as of this writing, still on the 2024 regime — senders sending 5,000 or more messages a day through Gmail accounts must set up both SPF and DKIM and publish DMARC, though the policy may be none (official documentation). There is no mention of RFC 9989 anywhere on the page.

There's no public material confirming whether large mailbox providers have internally switched to the tree walk, so I won't assert anything here. What is clear is that PSL-based and tree-walk-based receivers will coexist on the internet for a while, which makes the workaround mentioned above — publishing explicit records on every domain used for sending — a real, practical defense for the transition period.

Practical Checklist — What to Do Now, and What You Can Skip

Start with what you don't need to do. Leave v=DMARC1 in your records as-is. There is no such thing as a migration to DMARC2. Your existing deployment keeps working.

Here is what's actually worth doing.

1. Secure DKIM alignment first. If you're at p=reject or planning to get there, verify that every sending path carries an aligned DKIM signature. A p=reject that depends on SPF passing alone is now an explicit standards violation (MUST NOT).
2. Clean pct, rf, and ri out of your records. New-generation receivers ignore them anyway, but legacy receivers still interpret pct, which is exactly why the two populations behave differently. If you need a gradual-rollout signal, move to t=y — but keep in mind that legacy receivers, in turn, don't understand t either.
3. Publish an explicit DMARC record on every domain actually used for sending. This is the spec's own recommended way to head off the possibility that PSL-based and tree-walk-based receivers land on different answers.
4. Use np if you're worried about impersonation of non-existent subdomains. Separate from your policy for real, existing subdomains (sp), you can strongly block only names that resolve NXDOMAIN.
5. If you're using -all, be aware of the blind spot in your aggregate reports. Mail rejected before DATA never shows up in the reports.
6. Reconsider p=reject on domains ordinary users send from. A reject transition that skipped the standard's prescribed procedure — none for at least a month, quarantine for the same period, comparing the reports — is now something people can push back on with a reference document in hand.

Closing

Looked at purely in terms of protocol bits, this standardization is a quiet revision — the records stay the same, and most of the pass/fail evaluation logic stays the same too. But three things have substantively changed: organizational-domain determination moved from dependency on an external list (PSL) to DNS's own discovery (a tree walk, up to 8 queries); the gradual-rollout device was replaced with a form validated by real-world experience (the t tag); and operational principles became citable normative sentences for the first time — DKIM is mandatory for p=reject, don't reject on a user domain, and receivers must not discard mail on a reject declaration alone.

And the most trustworthy part of this standard is that it wrote its own limitations into the document. The mailing-list problem remains unsolved, ARC remains Experimental, and the standard even predicts that receivers won't follow its own advice. The conclusion of an 11-year standardization effort isn't "completion" — it's "an honest record of reality." For a 40-year-old system like email, that actually seems like a fitting ending.

References

• RFC 9989 — Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 9990 — DMARC Aggregate Reporting
• RFC 9991 — DMARC Failure Reporting
• draft-ietf-dmarc-dmarcbis — IETF datatracker
• RFC 7489 — DMARC (2015, Informational, obsoleted)
• RFC 8617 — Authenticated Received Chain (ARC), Experimental
• RFC 7960 — Interoperability Issues Between DMARC and Indirect Email Flows
• OpenDMARC — DMARCbis gap-analysis issue #371 / walk_mode PR #430
• Gmail sender guidelines — bulk sender requirements
• Internet.nl — DMARCbis tree-walk issue #1809