When a .name Domain Disappears, So Does the Identity

Imagine using the same Internet address for 25 years. It begins as a website URL, then quietly becomes an email address, an application endpoint, a place to publish documentation, and a trusted name inside devices that connect over the Internet.

That is why the planned termination of third-level .name domains matters far beyond the domain-name industry. Verisign is ending registrations such as first.last.name and the related .name email-forwarding service. The change is expected to affect approximately 22,000 registered names. Most may be inactive, but an old domain does not need thousands of visitors to become important. One email address connected to a few dozen accounts can be a serious security dependency.

A domain name is a stack

The Domain Name System, or DNS, is the Internet’s naming directory. It translates human-readable names into technical destinations such as web servers, mail servers, and application endpoints. DNS names are hierarchical, which means each part between the dots has a place in the structure.

neil.fraser.name
└─ neil third-level label
 └─ fraser second-level label
 └─ name top-level domain, or TLD

In this example, .name is the top-level domain, fraser is the second-level label, and neil is the third-level label. The complete name is a third-level domain registration.

That design was not the same as someone buying uk.co and reselling names underneath it. The .name registry was created to support personal names at the third level, with registrations maintained through the registry system and available through registrars. For years, that made first.last.name a legitimate, if unusual, alternative to more familiar domain formats.

What Verisign is actually removing

The changes are moving through ICANN’s Registry Services Evaluation Policy, usually called RSEP. This is the process a registry operator uses to add, change, or remove a service offered inside a top-level domain.

Verisign submitted the relevant requests on April 15, 2026. One request covers third-level domain registrations. The other covers second-level email addresses such as [email protected] and the forwarding system behind them. When the changes take effect, the registry will stop accepting new third-level registrations, existing third-level names will be deleted, email-forwarding addresses will be terminated, and the associated mail-routing records will be removed.

The timeline is easy to misread. ICANN’s public materials say the requests were approved on May 7, 2026, and posted on May 8. The public letter dated July 28 was the notice allowing Verisign to proceed, not the original approval date. Verisign must provide registrars with at least 90 days of notice, plus a reminder at least 30 days before the shutdown. Some registrars have told customers to expect the final cutoff in February 2027, although the exact date can vary by registrar communication.

As of September 4, 2026, the public ICANN reconsideration page lists an August 24 recommendation that the Board deny a challenge from an affected registrant. That recommendation does not erase the practical migration problem. It mainly explains that ICANN’s RSEP review is narrow: it looks for significant security, stability, or competition issues, rather than judging every customer-service, refund, or continuity consequence.

Why paying through 2040 may not be enough

It helps to separate two companies that domain owners often see as one. A registry operates the central database and DNS infrastructure for a top-level domain. A registrar is the customer-facing company where you purchase and manage a domain.

The registrar may accept payment for a registration lasting many years, but the registry controls whether that type of registration continues to exist. Removing a registry service can therefore end a name before the expiration date shown in a customer account. That feels like a lease being cancelled even though the rent has been paid, and it raises difficult questions about refunds or compensation.

ICANN’s reconsideration materials place those questions largely inside the registrar–registrant relationship. In other words, ICANN’s approval does not automatically create a universal refund or grandfathering rule. The terms that matter may be buried in the registration agreement accepted years ago.

What happens to a third-level.name domain after termination?

The largest technical risk may arrive after deletion, when an old name becomes available for reuse.

Suppose neil.fraser.name disappears and fraser.name later becomes available to another registrant. The new owner of fraser.name could potentially create a new neil.fraser.name beneath it. That does not mean every deleted name will be hijacked automatically. The parent domain must become registrable, and the registry may apply reservations or holding periods. Still, the possibility is serious because control of the parent creates control over the namespace below it.

The email-forwarding proposal includes a one-year block on re-registering certain second-level names associated with deleted forwarding addresses. That is useful protection for that particular service, but it is not the same as a permanent reservation of every parent domain used by a third-level registrant. Anyone relying on an old .name identity should treat future reuse as an unresolved dependency rather than assuming the name will remain safely frozen.

The consequences reach beyond a website. An attacker controlling a recreated domain could receive password-reset messages, impersonate an old email address, publish a replacement website, or issue new credentials for an API. Internet-connected devices may continue trying to contact the old hostname and silently fail, or they could reach an unexpected service if the name is recreated with different DNS records.

A practical migration plan

Start with an inventory, not a new logo. Search source code, configuration files, documentation, monitoring rules, certificate records, vendor allowlists, and account-recovery settings for every old hostname and email address.

DNS inspection can reveal part of the map:

dig A old.example
dig AAAA old.example
dig MX old.example
dig TXT old.example

A and AAAA records point to IPv4 and IPv6 addresses. An MX record identifies mail-handling servers. TXT records often contain verification or email-security data. These commands do not find every dependency, but they show which pieces are visible in DNS today.

Move the working service before the shutdown date. Register a replacement domain, configure its web and mail records, issue new TLS certificates, and test it from outside your own network. A TLS certificate is the digital credential that helps a browser verify a website and encrypt its connection.

Then update the identity layer. Change account-recovery addresses, rotate API keys, replace webhook destinations, update software allowlists, and reconfigure any Internet of Things devices that contact the old domain. Email forwarding can provide a temporary bridge, but it should not be the only plan; forwarding ends when the registry service ends.

The .name shutdown is a reminder that DNS names are not decorative labels. They are control points for communication, authentication, software delivery, and machines in the physical world. Once a small personal domain has carried those responsibilities for decades, deleting it is not housekeeping. It is infrastructure retirement, and it deserves the same careful planning as replacing a server or changing a company’s primary email system.