Verisign plans to delete every third-level .name domain in February 2027, ending about 22,000 registrations, including some paid beyond 2030. The change affects addresses such as firstname.lastname.name and the associated email forwarding service. As of September 6, 2026, affected holders have about five months to move.
A normal domain expiry alert won't catch this. The registrations are being discontinued as a class, regardless of their renewal dates. ICANN approved the plan in May without directly notifying registrants. In August, its Board Accountability Mechanisms Committee recommended denying the only formal challenge filed against it.
The issue drew wider attention on September 3, when Neil Fraser reported that his website, email and IoT endpoints would be terminated even though neil.fraser.name is paid through 2040. He has held the name since 2001. His post reached the top of Hacker News with more than 2,000 upvotes. The relevant paperwork had been on ICANN's website since May 8.
What ICANN approved
On April 15, 2026, Verisign submitted two requests through ICANN's Registry Services Evaluation Process, or RSEP. RSEP 2026013 discontinues third-level .name registrations. RSEP 2026014 shuts down the email forwarding service that delivers messages addressed to neil@fraser.name to the holder of neil.fraser.name.
Verisign cited “declining usage and limited registrar support of the service,” according to Domain Incite. ICANN approved both requests on May 7. Implementation letters followed on July 28, and registrars are to receive 90 days' notice before deletion.
The RSEP review covers three questions: whether a registry change harms security, stability or competition. ICANN found no harm in those categories. The process didn't require a separate assessment of what the shutdown would mean for registrants, and a straightforward approval doesn't trigger a public comment period.
Verisign's filing described the effect on the domain life cycle as “None.” Doytchin Spiridonov, a registrar employee in Bulgaria who owns three affected domains, examined the zone file and counted 22,288 third-level registrations. He found ICANN's notice 25 days after publication and filed a Request for Reconsideration on June 2.
ICANN's Ombuds evaluated the request on July 31. On August 24, the Board Accountability Mechanisms Committee recommended denial, explaining that “the scope of ICANN's review of RSEP requests is narrow and is limited to ICANN's consideration of security, stability, and competition issues.” The consequences for registrants weren't a separate part of that review.
Why third-level .name registrations exist
ICANN approved .name in 2000. Global Name Registry launched it in 2001 as a top-level domain for individuals. For its first three years, registration was available only at the third level, in the form firstname.lastname.name.
Second-level registrations, such as lastname.name, opened in 2004. A rule protected existing third-level holders: lastname.name couldn't be sold if someone already held something.lastname.name. Verisign later bought Global Name Registry and has operated the zone since.
This left .name with an unusual structure. Most registrars never built support for third-level sales. The boundary between registry-controlled names and registrant-controlled names also depends on what has already been registered. That complicates its representation in the Public Suffix List, which helps software identify those boundaries for uses such as cookie and certificate scoping.
Domain Incite puts the entire .name zone at about 96,000 domains. Third-level registrations therefore account for less than a quarter of an already small zone. Verisign's stated rationale treats the shutdown as retiring a little-used service with limited registrar support. For holders with years remaining on their registrations, it means losing an address they have already paid to keep.
Fraser said he chose .name in 2001 because Verisign didn't run it. That choice lasted 25 years before this shutdown.
Email creates the longer-term risk
A website move leaves broken links and requires redirects while the old domain remains available. Once that domain is deleted, its former holder can no longer rely on it to redirect visitors. An email address used for decades creates a larger migration problem because other services may still trust it for account recovery.
Under the planned sequence, neil.fraser.name is deleted in February 2027 and forwarding for neil@fraser.name stops the same day. Domain Incite reports that second-level names used by the email service become available for registration one year later.
Someone who then registers fraser.name could publish an MX record, which tells mail systems where to deliver messages for that domain. That person could receive password resets, two-factor authentication fallback messages and account recovery mail still addressed to neil@fraser.name.
Fraser warned that this could expose hundreds of accounts linked to his address and allow an attacker to commit code using his authentication. The risk depends on which accounts still use the address and what other protections those accounts have. It doesn't require an attacker to compromise the old mailbox if control of the domain is enough to receive new recovery messages.
The roughly 22,000 affected registrations indicate the scale of the migration, though they don't establish how many people use forwarding or how many accounts are exposed. Long-lived addresses can be tied to bank accounts, GitHub, registrars and cloud consoles. They can also appear in commit-signing identities and TLS certificate contacts. Each dependency needs checking rather than assuming an email forwarding change will cover it.
ICANN's finding of no security issue should be read within the scope of its review. A registry can discontinue a service without damaging the operation of DNS itself. The later reuse of an address for account recovery is a different security risk, and normal DNS operation doesn't prevent it.
Expiry monitoring covers a different failure
A writeup at reptile.haus identified the monitoring gap: an expiry monitor wouldn't have fired because expiry wasn't the failure mode.
Common domain protections address missed renewals, expired payment cards, warnings sent to abandoned mailboxes and fraudulent transfers. Automatic renewal, current contact details and transfer locks all help with those problems. They don't prevent a registry from retiring an entire category of registration.
In this case, the change was documented on an ICANN policy page, with formal notice going to registrars rather than directly to the people holding the names. A registration paid through 2040 can still disappear in 2027 without ever approaching its recorded expiry date.
A domain also depends on a chain of agreements: the registrant's agreement with a registrar, the registrar's with a registry, and the registry's with ICANN. Renewal and transfer controls don't eliminate policy or eligibility changes elsewhere in that chain. UK residents who lost .eu eligibility after Brexit encountered a different version of this dependency.
What affected operators should do before February
Moving a long-used email identity across hundreds of accounts can take months. The immediate work is to find those dependencies and change them while the existing address still receives mail.
- Search personal and team password managers for “.name”. Check recovery email addresses, commit-signing identities, certificate contacts and OAuth redirect addresses. Anything using an affected third-level domain or its forwarding address needs a replacement before February 2027.
- Ask the registrar about the matching second-level name. Establish whether an affected holder can claim it before public registration opens. Under the 2004 rule, it remains blocked while a third-level registration exists. There may be no priority route, leaving existing holders to wait with everyone else.
- Move email and update recovery addresses now. A second-level domain under a registry with straightforward rules avoids this particular third-level dependency, though it doesn't remove all registry risk. Changing a primary login address may not change a separate recovery address, so both need checking.
- Record registry-service dependencies in the domain inventory. Note which services each name relies on and whether a discontinuation could remove the registration or its email service. Expiry dates alone don't describe that exposure.
As of September 6, the committee's denial recommendation is not a final board decision. The expectation is that the board will adopt it and Verisign will proceed on schedule. An account takeover could occur after second-level names become available in 2028. Removing old recovery addresses before that point would close the most direct route to such an attack.
