On 15 April 2026, Verisign filed two routine-looking forms with ICANN. On 7 May, ICANN approved them. On 28 July, it issued the letters making it official. The effect is that roughly 22,000 domain names, some paid up for years in advance, will be deleted from the internet along with the email addresses attached to them.
Nobody did anything wrong. No registrant forgot to renew, no registrar went bust, no court ordered a seizure. The process worked exactly as designed, and that is the part worth your attention.
TL;DR
- Verisign asked ICANN to discontinue third-level registrations in
.name(RSEP 2026013) and the email forwarding service (RSEP 2026014). ICANN approved on 7 May 2026 and issued free-to-deploy letters on 28 July 2026. - Around 22,000 registrations will be terminated, a figure one registrant’s zone-file analysis put at 22,288. Prepaid terms running to 2029 and beyond do not survive.
- ICANN’s review of a registry service change is limited by policy to three questions: security, stability and competition. Impact on existing registrants sits outside that scope, and approval triggers no public comment period.
- The engineering risk is not the deletion but what follows it, when vacated second-level names become registrable and whoever buys one can receive password-reset email for identities twenty-five years older than them.
- Your domain expiry monitor would not have fired once during any of this. Expiry was never the failure mode.
What actually happened
The .name top-level domain has always been unusual. It was built as a third-level namespace, so you register john.smith.name rather than smith.name, with a full WHOIS record and any accredited registrar, much as you would under co.uk. It also came with email forwarding at the second level, so [email protected] delivered wherever you pointed it. Both have run for roughly twenty-five years.
Verisign, which acquired the registry operator years after launch, asked to switch both off. Its stated reasoning, quoted in ICANN’s approval letter, was “limited registrar support of the service and declining usage of third-level domains”, and that discontinuation “will increase efficiency for the operation of the .name TLD”. While there are approximately 22,000 third-level registrations, Verisign said, the majority are not in use.
The filing repays a read. The standard Registry Services Evaluation Policy form asks: What effect, if any, will the proposed service have on the life cycle of domain names? Verisign answered: “None. There will not be any effect on the life cycle of domain names.”
On a narrow reading that is defensible, since nothing about the renewal, redemption or drop cycle changes. It is also the sentence that best captures why this matters: a change deleting 22,000 names was described, accurately within the form’s terms, as having no effect.
The three questions ICANN is allowed to ask
A registrant, Doytchin Spiridonov, filed a Request for Reconsideration on 2 June 2026, arguing ICANN had approved the change without weighing the impact on the people holding those registrations. ICANN’s Ombuds evaluated it on 31 July and the Board Accountability Mechanisms Committee recommended denial on 24 August. Its reasoning is clearer than any commentary on it:
“While such considerations are understandably important to the Requestor and other registrants, the scope of ICANN’s review of RSEP requests is narrow and is limited to ICANN’s consideration of security, stability, and competition issues.”
On refunds or grandfathering for registrations already paid for, the committee was equally direct: those remedies “are governed by contractual agreements between registrars and registrants, to which ICANN is not a party.”
Read that twice if you run infrastructure. The body governing the namespace has three review criteria, and “does this destroy something people depend on” is not one of them. That is not a scandal, it is published policy agreed two decades ago. But most engineering teams have quietly assumed a fourth criterion exists. It does not.
A procedural detail compounds it: two of the four possible RSEP outcomes require a public comment period, and plain approval is not one of them. The first public signal was a line on ICANN’s RSEP Process web page on 8 May. Spiridonov found it on 2 June, twenty-five days later, by looking.
Prepaid to 2040 is not a defence
The registrant who brought this to wider attention had held his domain since 2001 and paid it up to 2040. Spiridonov’s affected names expire in November 2026, February 2027 and November 2029. None of it matters, because expiry is not the mechanism. The service is being withdrawn, and the registrations go with it.
That is the gap in how most teams monitor domains. Every competent ops setup alerts on approaching expiry, auto-renew failure and registrar lock status. Not one would have gone amber at any point in a sequence that began with Verisign and ICANN meeting privately across late 2025.
The part that should worry your security team
Deletion is the boring half. The interesting half is reallocation.
When third-level registrations go, the second-level names underneath .name stop being occupied and are expected to become registrable again. Verisign has not said whether that happens by ordinary drop, by auction, or on some other schedule; for names tied to the email service, reporting suggests a one-year hold first.
Whoever registers one of those names next can stand up mail for it, and receive password-reset messages for every account, anywhere, opened with an address at that domain over the past quarter century. Those accounts cannot be enumerated and there is no central revocation. The systems on the other end behave correctly by their own logic: the address is valid, mail is delivered, the reset link works.
Same failure class as a lapsed corporate domain scooped up to harvest mail, but with a far less visible trigger. Nobody forgot to pay. A registry filed a form.
The blast radius extends past email. What else in your stack is keyed to a domain you do not fully control?
- Account recovery for cloud consoles, registrars, payment processors and code hosting
- Git commit identity and signing, where the address links a commit to a person
- SSO domain verification, usually proved by a DNS TXT record on a domain assumed permanent
- OAuth redirect URIs and webhooks hard-coded into integrations nobody maintains
- Firmware endpoints in shipped hardware, unfixable once the hostname resolves to somebody else
- Certificate issuance, where domain control validation hands the new holder a valid certificate
What to do about it
Six things, in the order we would do them:
1. Inventory the domains you depend on, not the ones you own. Grep configuration, firmware images and integration settings for hostnames; pull addresses out of git history, DKIM selectors and DNS verification records. The dependency list is always longer than the asset register.
2. Count the contract hops for each one. A second-level name under a legacy gTLD is one hop: your registrar. A third-level name, a vendor subdomain, or a ccTLD with local presence conditions is two or more. Each extra hop is another party who can withdraw the service without your agreement.
3. Separate identity roots from convenience domains. The mailbox receiving account-recovery mail, the identity on your signing key and the domain on your SSO verification record belong on the most boring, most sovereign name you hold. Not the clever short one, and never a vendor’s subdomain.
4. Monitor policy, not just expiry. ICANN’s RSEP Process page is a public feed of exactly this class of change and almost nobody reads it. Registry agreement renewals and registrar acquisitions belong on the same watchlist.
5. Rehearse a migration before you need one. Change one staff mailbox address and count how many services need a human to intervene. That number is your blast radius, and most teams have never measured it.
6. Read the termination clause before prepaying for a decade. ICANN has now stated in writing that your remedy, if any, lies with your registrar. Find out what it is while you still have leverage.
If you operate a namespace, you are the registry now
The uncomfortable inversion: if your product gives customers a subdomain, a vanity address or a tenant hostname, you occupy Verisign’s position. Your customers have built the same assumptions on your namespace that .name registrants built on Verisign’s, and your terms almost certainly reserve the right to change it.
The obligations that follow are engineering ones, not legal ones. Give notice in quarters rather than weeks, and give it to the people affected rather than an intermediary. Publish a migration path with a redirect window. Hold retired tenant names instead of recycling them, because recycling a name hands an attacker a working identity. And when someone asks what effect a change has on your customers, do not answer “none” just because the form permits it.
REPTILEHAUS builds and runs multi-tenant platforms, DNS and identity infrastructure for teams who would rather find these dependencies in an audit than in an incident. If you are not certain which domains your systems would fail without, that is the audit to book. Get in touch.
This article summarises publicly filed documents and is not legal advice.
📷 Photo by KC Shum on Unsplash
