Who Really Owns Your Company's Domain Name

The Registrant of Record Is the Party With Control

A domain name registration is a contractual right to use a name for a term, held against a registrar under a registration agreement that incorporates ICANN policy. The party named in that registration as the registrant — the Registered Name Holder — is the party with control. Registries and registrars act on instructions authenticated against the registrant account. They do not act on evidence of who funded the purchase.

Three things that feel like ownership are not:

• Paying the invoice. The billing contact on a registration confers no control at all.
• Owning the trademark. A registered mark gives a company a claim it can bring against a registrant. It does not give it standing with the registrar to demand a transfer.
• Using the name in commerce. Twenty years of letterhead, email addresses and business cards do not change the registration record.

The record also carries administrative, technical and billing contacts, and those roles are routinely conflated with ownership. Only the registrant field determines who can move, change, or lose the name. A company that reimbursed a developer for a registration but is not the named registrant has no direct standing with the registrar at all.

How Companies End Up Not Being Their Own Registrant

The patterns are consistent enough to be predictable:

• The developer who registered it on a personal account because it was faster. The client had not set up a registrar account, the launch date was fixed, and the developer had a card on file. The site went live and nobody went back.
• The agency that registered it as part of a launch. The domain was one line on a project checklist, registered inside the agency's own reseller account alongside forty other clients.
• The employee who used a personal email address. The corporate mailbox did not exist yet, or the marketing manager expensed a campaign domain on a personal card. Three years later that person left.
• The acquisition where nobody checked. The domain appeared on the asset schedule, everyone assumed it moved with the business, and no one opened the registration record.

The common thread is that registration is a five-minute administrative act, performed under time pressure by whoever is closest to the keyboard, and never revisited because the site keeps working. The defect is invisible for years. It surfaces only when something forces a change: a redesign, a migration, a renewal, a dispute, or a sale.

Registry, Registrar, and the Reseller in the Middle

Three parties sit behind every gTLD registration, and they have different powers.

• The registry operator runs the authoritative database for a top-level domain — Verisign for .com and .net, PIR for .org, and a separate operator for each other gTLD and country-code TLD. It holds the authoritative record and applies registry-level status codes.
• The registrar is an ICANN-accredited entity with a contractual relationship to both the registry and the registrant. It sponsors the registration, holds the registrant account, and applies registrar-level status codes.
• The reseller is not accredited by ICANN. It sells registrations under an accredited registrar's accreditation. Hosting companies, web agencies and platform vendors are very frequently resellers.

An intervening reseller complicates everything, and it is the most common structural reason a company cannot reach its own registration. The company has a relationship with the reseller only; the accredited registrar has no relationship with the company. If the reseller is unresponsive, defunct, or already in dispute with the client, there is no account to log into and no obvious counterparty. The escalation route is to identify the accredited registrar of record from the registry's authoritative record rather than from the reseller's branding, because accredited registrars carry obligations under the Registrar Accreditation Agreement and are the party ICANN's compliance function can act against.

What the Registration Record Shows, and What It Hides

Public registration data — historically WHOIS, increasingly served over RDAP — is substantially redacted. Under ICANN's Registration Data Policy, which became effective 21 August 2025, the published set generally includes the domain name, the registrar and its abuse contact, the status codes, creation and expiry dates, name servers, and a defined set of registrant fields including name, street, city, country and phone. Registrant email and technical email are subject to mandatory redaction, replaced by a web contact form or an anonymised forwarding address. Other fields — registrant organisation, postal code, phone, and various identifiers — may be redacted where redaction is required by applicable law or where the contracted party has a commercially reasonable purpose.

Because redaction is partly mandatory and partly optional, what appears varies by registrar, by registry, and by where the registrant is located. There is no single universal rule about what a lookup will show.

For a company checking its own domain, this is usually enough: the registrant name is visible, and seeing an individual's name there is the answer. Where the fields are redacted or a privacy service is the registrant of record, the routes behind the curtain are a request to the registrar, which decides whether to disclose; a subpoena or court order; or a UDRP filing, in which the provider obtains the underlying registrant data from the registrar — which is why complaints are commonly amended after filing to name the disclosed registrant.

Locks, Auth Codes, and the 60-Day Rule Now in Force

Domain status is expressed in EPP status codes, split between client codes set by the registrar and server codes set by the registry.

• clientTransferProhibited is what is usually called registrar lock. It directs the registry to reject transfer requests, it is on by default at most registrars, and the registrant can normally toggle it from the control panel. It has to be cleared before a transfer out.
• serverTransferProhibited is set by the registry and requires the registrar to coordinate with the registry operator to remove. Registry lock as a commercial product is this family of codes applied deliberately, with out-of-band, manually authenticated confirmation — a designated contact, a passphrase, a phone callback — required before any change to transfer, update, delete or nameserver state. It is the strongest available protection against hijacking, and it belongs on any name carrying a company's website, mail or authentication. It is available for many but not all TLDs.

The authorisation code — auth code, EPP code, AuthInfo — is a per-domain secret issued by the losing registrar to the registrant and used by the gaining registrar to authenticate a transfer. Anyone holding it who can also receive the confirmation message can move the domain. Treat it as a credential of the same sensitivity as a root password, and rotate it after any agency or employee departure.

The Transfer Policy in force is the version updated 21 February 2024, which contracted parties were required to implement by 21 August 2025. Under it, a registrar must impose a 60-day inter-registrar transfer lock following a change of registrant, though a registrar may permit the holder to opt out of that lock in advance of the change; a registrar may deny a transfer within 60 days of an earlier transfer or of initial registration; and a completed transfer extends the registration by a year. A GNSO policy review that would remove the change-of-registrant lock was adopted by the GNSO Council in March 2025 and sent to the ICANN Board, which opened public comment in April 2025. As of July 2026 the Board has not adopted it, and the 60-day locks remain part of the policy in effect. Guidance stating the lock has been eliminated is describing a pending recommendation, not current policy.

Expiry Is a Countdown, Not a Grace Period

ICANN's Expired Registration Recovery Policy requires the registrar to send a notice roughly a month before expiry, another roughly a week before, and at least one more within five days after expiry with renewal instructions. It also requires the registrar to interrupt DNS resolution for a period after expiry while renewal is still possible — deliberately, so that the lapse becomes visible instead of the site quietly continuing to resolve.

What follows runs on a fixed clock:

• Auto-renew grace period. The registry auto-renews on expiry and the registrar decides whether to bill, hold, or delete. The length is set by the registry agreement and varies; there is no single ICANN-mandated figure. Renewal is usually still possible, often with a late fee.
• Redemption Grace Period — 30 days. If the registration is deleted, it can be restored only by the registrar that deleted it, at the registrant's request, for a substantial restore fee. DNS does not resolve during this period.
• pendingDelete — five calendar days. The name cannot be renewed, restored or transferred at all.
• Drop. The name returns to the available pool and is contested at the moment of release by backorder and drop-catch services.

This is why a lapsed renewal is an emergency rather than an administrative annoyance. Resolution stops before the name is gone, which takes down the website and, more damagingly, company mail — and with it every password reset, single sign-on flow and vendor portal keyed to an address at that domain. The practical chance of quietly re-registering a lapsed corporate name after the drop is low. Some registrars also park expired names on advertising pages or auction them near the end of the renewable window. Country-code domains sit outside ICANN consensus policy entirely and follow their own registry rules.

Recovery, and Where a Legal Route Becomes Necessary

The first step is almost always the cheapest: ask, in writing, for a documented change of registrant and release of the authorisation code. Where the holder cooperates, sequence matters — elect the opt-out from the 60-day lock before the change of registrant, then change, then transfer, or plan around the two-month wait.

Where the account is in the company's name but only a departed individual holds credentials, the registrar's account recovery process is the route, and it typically requires formation documents, an officer's declaration and billing records to prove corporate identity. Attempting to access an account the company is not authorised on is a different problem entirely, and raises exposure under the Computer Fraud and Abuse Act and state computer-crime statutes.

Registrars generally will not adjudicate ownership. They point to the registration agreement and to legal process. ICANN's compliance function enforces registrar obligations but does not decide who owns a name, and the Registrar Transfer Dispute Resolution Policy is a registrar-to-registrar mechanism about whether a transfer complied with the Transfer Policy — it has a twelve-month filing limit and is not available to registrants at all.

A legal route becomes necessary once there are genuinely competing claims: a contract dispute with a former developer, a departed-founder dispute, a fraudulent transfer. The practical relief is a court order directing transfer, which registrars will act on, and in appropriate cases interim relief freezing changes to the registration. Where the name incorporates the company's mark, the UDRP or the ACPA may also be available — though the UDRP is a trademark instrument, not a general ownership forum, and it cannot resolve a contract dispute with a developer who has a colourable claim of his own.

The Controls That Prevent All of This

A preventative checklist, in the order it is worth doing:

• A corporate registrar account in the company's legal name, held directly with an accredited registrar rather than through a reseller, with the company named as registrant of record.
• A role-based email address of record that survives departures, monitored by more than one person, and hosted on a domain other than the one being protected — because if the primary domain fails, recovery mail on that domain fails with it.
• Registry lock on the names that carry the website, the mail and the authentication.
• Renewal monitoring independent of the registrar's own reminders: multi-year registrations, auto-renew on a corporate payment instrument that is not in an individual's name, and a diarised date owned by a named person.
• An annual audit of the registration record itself — registrant, contacts, status codes, expiry dates, name servers — reconciled against a written inventory of every domain the company holds, including defensive and country-code variants.

The reason this is a board-level asset question rather than an IT ticket is what control of the name actually confers. Whoever controls the domain's DNS can obtain a publicly trusted TLS certificate for it, redirect the MX records and receive the company's mail, alter the SPF, DKIM and DMARC records that establish whether the company's mail is authentic, and point the website somewhere else. That is not a service restored from backup. It is a single point of failure with a renewal date, sitting in a record most boards have never seen, frequently in someone else's name. CAA records, which restrict which certificate authorities may issue for a domain, and monitoring of Certificate Transparency logs for unauthorised issuance are both cheap partial controls worth having in place first.

When Ownership Becomes a Formal Dispute

Once a domain question reaches a court, the issues counsel needs answered are technical and historical: who was the registrant of record on a particular date, when the registrant changed and on whose instruction, which account and which email address the instruction came from, what the registrar's own records show about authentication and notice, where the name servers pointed at each stage, and what the site displayed while it did. Registration data is redacted in the present and patchy in the archive, so establishing that history normally means combining registry records, historical registration archives, DNS history, certificate transparency records and the registrar's internal records obtained by request or subpoena. Reconstructing and explaining that sequence is what an expert witness is engaged to do.

Preserve early, because most of it expires on a retention schedule. Registrar account change logs, notification messages sent to the address of record, hosting records and DNS change history are routinely purged long before a dispute matures. A written preservation request to the registrar, the DNS host and anyone who has held the account, sent as soon as the problem is identified, preserves more than any later reconstruction can recover.

Frequently Asked Questions