A website can be rebuilt. A domain can be moved. Losing control of the registrar account is harder to untangle, especially when the domain sits in a developer’s personal account and the recovery email belongs to someone who has left the project.
Consider a familiar client project. A restaurant owner asks a freelancer to “buy everything” and sends a card number. The freelancer creates the registrar account with a personal email because it is quicker. Two years later the freelancer is unavailable, the card has expired, and renewal notices are landing in an inbox the restaurant cannot open. The website may still be online today, but the business does not have dependable control of its public address.
Decide the owner before searching for a name
For a client website, the client or client company should normally be the domain registrant and control the registrar account. The developer can receive delegated access where the registrar supports it. If delegated access is unavailable, use a client-controlled account and record who can sign in. Avoid placing unrelated clients in one personal registrar account; a billing dispute or compromised login can affect every domain in it.
ICANN defines the registrant as the individual or entity that registers the name and enters into a contract with the registrar. The registrant has rights and responsibilities for managing, renewing, and transferring the registration. That contractual position is more important than the name shown on an agency invoice. Read ICANN’s information for registrants and the registrar’s current agreement before payment.
Create a Domain Ownership Card
Make one private record before checkout. It should answer these questions without exposing passwords:
| Field | What to record | Reason |
|---|---|---|
| Registrant | Legal person or organization | Identifies the contracting holder |
| Registrar account | Account name and client-controlled email | Shows where the domain is managed |
| Recovery route | Recovery email and phone owner | Prevents one-person lockout |
| MFA custody | Who holds the primary and backup factors | Keeps access available when staff change |
| Renewal | Date, auto-renew setting, payment owner | Reduces accidental expiration |
| DNS operator | Company and account that hosts DNS | DNS may be separate from the registrar |
| Approved helpers | Developer or agency with delegated access | Separates assistance from ownership |
Store the card in a private business vault. Store credentials and recovery codes in a password manager rather than inside the card. CISA recommends multifactor authentication for online accounts that offer it. For a domain account, prefer a phishing-resistant method such as a security key or passkey when the registrar supports one, and keep a protected recovery method for the organization.
Use an email address that can survive the website
Do not make the only registrar login admin@the-new-domain.example. If DNS or email for that domain fails, password recovery can fail with it. Use an established, client-controlled address that does not depend solely on the new domain. Add a second authorized administrator when the service allows it, but keep individual logins so actions can be traced.
Keep contact information current. ICANN notes that renewal options and fees vary by registrar and that registrants should maintain accurate contact information to receive important notices. Calendar reminders are useful, but they do not replace auto-renew, a valid payment method, and periodic account checks.
Separate four kinds of control
Teams often say “we have the domain login” when they mean only one part of the system. Check each control separately:
- Registration control: renew, unlock, obtain the transfer authorization code, and change contact details.
- DNS control: change where the website, email, and verification records point.
- Hosting control: access site files, database, backups, logs, and billing.
- Application control: administer WordPress, an ecommerce platform, or another content system.
A developer may need all four during a launch, but that does not require permanent ownership of all four. Use role-based or delegated access where possible. When shared access is unavoidable, record the reason and replace it after launch.
Run a five-minute recovery rehearsal
Before the project depends on the domain, ask the client owner to sign in from a private browser window. Confirm the recovery email and phone, locate the renewal date, find the DNS page, and identify the domain lock setting. Do not request an authorization code unless a transfer is planned; simply confirm the owner knows where the transfer controls are.
ICANN’s transfer guidance says a transfer generally requires an AuthInfo code and may be restricted during certain 60-day periods, including after initial registration, a previous transfer, or some registrant changes. That is another reason to settle ownership early rather than changing the registrant immediately before a planned move.
The decision before checkout
Proceed only when the client can answer: “Who owns the registration, who receives renewal notices, and how do we recover access without the developer?” If the answer relies on one person’s memory, stop and fix the account plan. The next step is choosing hosting. There, the key question changes from ownership to responsibility: who will handle updates, monitoring, backups, and recovery after the launch?
How we researched this guide
This guide applies ICANN registrant and transfer guidance to a common client handover problem. It does not provide legal advice and does not rank registrars. Account roles and recovery features differ, so check the selected registrar’s current controls and agreement. No affiliate links appear in this article.
