Who Owns Your Domain? Settle It Before a Website Project Starts

A new website can be designed, written, and built on schedule and still fail to launch, because nobody on the client side can log in to the account that controls the domain. It happens more often than it should: the domain was registered years ago by a former employee, an earlier web designer, or a relative who “handled the computer stuff,” and the business has been renewing it, or assuming someone was, ever since.

This article explains what controlling a domain actually means, how the rules set by ICANN (the Internet Corporation for Assigned Names and Numbers, which coordinates generic top-level domains such as .com and .org) decide who can move or keep a name, and what to confirm before a website project begins.

---

Why domain control belongs in project planning

A domain feels like a technical detail, but it is the address every other part of the business depends on. The website, the contact form’s email notifications, and usually the company’s email itself all rely on records attached to that one name. Losing control of it doesn’t just delay a launch; it can take the business offline.

ICANN’s Security and Stability Advisory Committee made the same argument in SAC044, A Registrant’s Guide to Protecting Domain Name Registration Accounts (2010). The report compares domain registrations to brick-and-mortar assets and urges organizations to protect them against threats or circumstances that could lead to temporary or permanent loss of the name.

Three layers that are easy to confuse

Most ownership problems start because people treat three separate things as one:

• The registrant. The person or organization named on the registration, which ICANN’s policies call the Registered Name Holder. This is the legal holder of the name.
• The registrar account. The login at the company where the domain is registered. Whoever holds it can change settings, renewal options, and often the registrant details themselves.
• The DNS host. The service that publishes the domain’s records: where the website lives, where email goes, and which services are verified to send on the domain’s behalf. It may be the registrar, the web host, or a separate provider.

A business can be the registrant while an old agency holds the registrar login, or hold the login while the DNS sits in a hosting account nobody remembers. Each gap creates a different kind of delay.

---

What ICANN’s rules say about who decides

ICANN’s Transfer Policy is clear about authority. It states that the Registered Name Holder is the only party with the authority to approve or deny a transfer request to a new registrar. In other words, the name on the registration matters more than who paid the invoice.

The transfer code and the five-day window

Moving a domain to a different registrar requires a transfer authorization code (the policy calls it the “AuthInfo” code). Under the Transfer Policy, if a registrar doesn’t let the holder generate the code and remove the transfer lock themselves, it must provide the code and remove the lock within five calendar days of the holder’s request. The policy also bars registrars from making that process more restrictive than the process for changing the holder’s contact or name server details.

That is a useful protection, but it only helps the registrant. If the registration names a former designer, the code goes to them.

Locks that can add 60 days

The current Transfer Policy lets a registrar deny a transfer to another registrar within 60 days of the domain’s creation date, or within 60 days of a previous transfer. It also requires a 60-day inter-registrar transfer lock after a Change of Registrant (a change to the holder’s name, organization, or email), unless the registrar offered an opt-out and the holder used it before the change.

The policy itself contains practical advice for that situation: if the end goal is to move the domain to a different registrar, request the transfer before changing the registrant, to avoid triggering the lock.

The rules are changing. On 7 June 2026, the ICANN Board adopted a package of Transfer Policy recommendations that, among other things, would remove the 60-day lock after a Change of Registrant and standardize the restriction after initial registration at 720 hours (30 days). The Board directed ICANN org to implement them; as of this writing, the current policy text with its 60-day rules is still the one registrars follow. Plan with the existing rules until your registrar says otherwise.

“A launch date is something you set. A transfer lock is something you inherit.”

• Windware Studio Practice Note

Renewal deadlines and what lapses take with them

ICANN’s Expired Registration Recovery Policy requires registrars to send at least two reminders before a generic top-level domain expires, one about a month ahead and one about a week ahead, and another within five days after expiry if the name hasn’t been renewed. Those reminders go to the contact details on file. If that address belongs to a departed employee, nobody sees them.

If the registration is deleted, most generic top-level domain registries must offer a 30-day Redemption Grace Period during which the name can still be restored. During that period, the registry must disable DNS resolution, so the website and any email on the domain stop working. Restoring the name is possible, but it is a recovery, usually with a fee, not a routine renewal.

---

A pre-kickoff domain check

The simplest place to start is ICANN’s lookup tool at lookup.icann.org. Since 28 January 2025, ICANN has treated RDAP (the Registration Data Access Protocol) as the definitive source for generic top-level domain registration data, replacing the older WHOIS services. A lookup shows the registrar, key dates, name servers, and status codes, though personal contact details are often redacted.

Consider a small accounting practice planning a redesign. A lookup shows the domain was registered nine years ago, the registrar is one nobody at the firm recognizes, and the name servers point to the hosting company of the designer who built the previous site. None of that is a crisis yet. It becomes one if it is discovered the week the new site is ready to go live.

Checklist: confirm before the project starts

• The registrant shown with the registrar is the business itself, not an individual employee or an outside supplier.
• At least two people at the business can log in to the registrar account, using a shared role address rather than one person’s inbox.
• Contact details on the registration are current, so ICANN-required renewal notices reach someone.
• The expiration date is recorded, with auto-renew on and a payment method that won’t expire before it.
• You know where DNS is hosted and can log in there too.
• Existing records are exported or documented, especially the ones that route email.
• If the registrant or registrar needs to change, the change is scheduled with the 60-day rules in mind.

Who should hold what

Asset	Who should control it	Who may need delegated access
Domain registration (registrant)	The business	No one; this should not be delegated
Registrar account	The business, with two or more owners	The studio, through a user or delegate role where the registrar supports one
DNS host	The business	The studio, for launch-day record changes
Web hosting	The business or the studio, by agreement	Whichever party maintains the site

---

What this check does not cover

ICANN’s policies apply to generic top-level domains. Country-code domains such as .mx, .ca, or .co.uk are run under their own registries’ rules, which can differ on transfers, locks, and expiry. The same three questions still apply; the deadlines may not.

The check also doesn’t resolve disputes. If a former supplier refuses to hand over a domain, or two parties both claim it, the registrar’s dispute processes or legal advice are the next step, not a web studio. The earlier that situation surfaces, the more room there is to handle it calmly.

---

Practical takeaways for your next website

1. Separate the three layers. Know who the registrant is, who holds the registrar login, and where DNS lives. They are often different.
2. Put the business on the registration. ICANN’s Transfer Policy gives transfer authority to the Registered Name Holder, so that is the name that should be yours.
3. Fix ownership before design starts. Transfer and change-of-registrant locks can run for 60 days under current rules, longer than many launch timelines allow for.
4. Make renewal notices land somewhere. Use a shared address, keep auto-renew on, and record the expiry date where the team will see it.
5. Grant access rather than handing over ownership. A studio needs to edit DNS on launch day. It doesn’t need to own your domain.

---

Ready to Discuss Your Website?

If you are planning a new website, a service redesign, or custom development for your business, we’re here to help you start with the foundations confirmed, including the domain your site depends on.

• Explore Our Services: Web Design · Web Development · Website Redesign
• Start a Conversation: Tell us about your project via our Contact Form or email us directly at [email protected].