For two years, domain accountability in DNS abuse enforcement has effectively meant one report, one domain, one mitigation decision. That's the practical scope of the obligation ICANN's Registrar Accreditation Agreement has placed on registrars since April 2024 — investigate the domain named in the complaint, mitigate it if the evidence holds, move to the next report. It's a clean, auditable, defensible model. It's also not how the abuse it's supposed to stop actually operates, and ICANN's own policy community is now in the middle of deciding what to do about that. The One-Domain Rule The current mitigation requirement is deliberately narrow. A registrar or registry operator receives an abuse report on a specific domain — phishing, malware, botnet infrastructure, pharming, spam used to deliver any of those. They evaluate the evidence. If it holds up, they act on that domain: suspension, in most cases, or a disruption measure for compromised domains that shouldn't be punished the same way a knowingly-registered one should. ICANN Compliance's own two-year enforcement report, published this June, shows the model working as designed at the domain level — nearly 530 investigations opened since April 2024, more than 480 resolved, roughly two-thirds ending in direct registrar action. Over 25,000 individual domains mitigated. What that number doesn't show is how many of those 25,000 domains belonged to the same operator. Why Domain-Level Enforcement Loses the Race It's Running Nobody who has actually chased a phishing campaign believes it lives on one domain. Coordinated abuse — credential harvesting kits, malware distribution, romance-scam infrastructure — is built on portfolios: dozens or hundreds of domains registered in bursts, often through the same account, registrant contact, or other identifying signal, cycling through disposable names faster than any single-domain takedown process can keep pace. Mitigate one, and the campaign doesn't stop. It just stops using that domain. The registrar did everything the current rule requires and the operator lost nothing that mattered. That gap — one report closes one instance of an ongoing operation, not the operation — is what ICANN's DNS Abuse Small Team flagged as the highest-priority target when it scoped the community's DNS abuse policy work in late 2025. It's a domain accountability gap, not a detection gap — the process was never built to ask what else the same registrant controls. What Associated Domain Checks Actually Proposes The response under active development is called Associated Domain Checks, and it's important to be precise about what stage it's actually at, because it is not a rule yet. The GNSO Council adopted the working group's charter in January 2026. The working group has met continuously since — it held four dedicated sessions at ICANN85 in Mumbai and another four at ICANN86 in Seville this June — and the direction under discussion would have a registrar, once a domain under its management is confirmed engaged in abuse, check other domains associated through defined signals and evaluate whether those domains warrant further action — the first real challenge to two years of domain-only accountability. That's the proposal. It is not settled. The working group's own deliberations through mid-2026 show real, unresolved disagreement on the two questions that determine whether this becomes meaningful policy or a compliance formality: what threshold triggers the check — is one confirmed abusive domain enough, or does it need corroboration — and whether the check has to happen before or after mitigation on the original domain. Working group members have raised the "guilt by association" risk directly: an associated-domain framework built too loosely could sweep in a registrant's unrelated, legitimate domains on the strength of a shared account. The working group's target for its Initial Report is February 2027. Anyone writing about this as an imminent obligation is writing about a different process than the one actually underway. What This Means for a Portfolio You Didn't Think Was at Risk Here's the part that should matter to you even though you're not a registrar. If Associated Domain Checks lands anywhere close to its current scope, the unit that gets evaluated when abuse is found stops being the domain and starts being the account behind it — domain accountability, in effect, moving up a level — and enterprise domain portfolios are exactly the kind of structure that assumption wasn't built around. Most organizations running a real domain footprint — brand-defense registrations, regional and country-code variants, subsidiary and M&A-inherited domains, dormant properties nobody's touched since a rebrand — don't manage that footprint as one clean account. It accretes: different registrars picked up at different points, legacy accounts from acquired companies, a marketing agency's registrant contact still on file for a domain nobody in IT knows exists. Those linkages are exactly the kind of relationships a portfolio owner should understand before a policy built around associated-domain analysis forces the question. That's not a reason to expect your legitimate domains get swept up wholesale; the working group's own stated concern is preventing exactly that outcome. It is a reason to know, today, what your actual account-level footprint looks like — because the assumption an enterprise architect has been able to rely on for two decades, that a domain's fate is its own, may not hold the way it used to once the containment unit for abuse enforcement moves up a level. Domain Accountability, Under Reconstruction The instructive part isn't that a niche corner of ICANN policy is getting more aggressive. It's that this is the same architectural move Rack2Cloud has already named in a different system entirely. Identity Is Becoming the New Infrastructure Boundary established Framework #160, Identity Boundary Inversion, for enterprise access architecture: the real trust boundary stopped being network topology — the resource's location — and became the identity acting on it. The current domain-level model makes the resource the unit of accountability, regardless of whether the underlying actor operates across multiple resources. Associated Domain Checks is that same inversion appearing in domain governance: the resource-level unit stops being sufficient once the thing doing harm operates at the actor level instead. Nobody planned this as a coordinated shift across DNS policy and enterprise identity architecture. It's the same underlying failure mode — resource-scoped accountability against an actor-scoped threat — showing up wherever that mismatch gets expensive enough to fix. What to Check in Your Own Portfolio Now None of this requires a compliance project. It requires knowing the answer to a handful of questions most infrastructure teams have never actually had to ask, because the domain has never been anyone's containment unit before. Registrant of record — who is the registrant on every domain your organization holds, not who manages it operationally, but whose name and account it sits under Shared signals — which domains share a registrant email, account login, or billing relationship, including ones acquired through M&A or picked up by an agency years ago Dormant coupling — which domains are dormant but still technically active and still coupled to a live account Third-party control — which agencies, resellers, or former employees retain administrative control over any domain in the portfolio Exposure signal — where a single compromised credential or account signal would create exposure across more domains than anyone tracking incident response actually knows about That last one is the operational risk that exists regardless of what ICANN eventually decides. A registrar checking for associated domains after an abuse finding is doing, defensively, what your own team should already be able to do proactively: produce an accurate account-level map of every domain you hold, on demand, before you need it for an incident — not after. Download: Domain Portfolio Inventory Carousel (PDF) — the five questions above, as a save-able slide deck. Architect's Verdict Domain accountability was never really about the domain. The domain was just the convenient unit — easy to name in a report, easy to act on individually, easy to audit one at a time. What's changing isn't that DNS abuse got worse. It's that the policy apparatus built around domain-level accountability finally caught up to how the abuse it's chasing has always operated: at the account level, not the resource level. Most enterprise domain portfolios have never had to answer for their own account-level structure, because nothing has ever asked. That assumption may become less reliable as the policy develops — with both the scope and the eventual trigger still undecided — which means the honest move isn't to wait for ICANN's Initial Report. It's to build the account-level map before a regulator, a registrar, or an incident forces you to build it under worse conditions. The domain was the containment unit because nobody had a reason to look past it. That reason is now actively under construction. Originally published at rack2cloud.com