Who should own the domain — you or your web agency?

You should own the domain — the business, not the agency. Concretely: the business is the named registrant, and the registrar account the domain lives in is one the business controls, with the agency given delegated access to do its work. That’s the consistent industry consensus — and the setup good agencies want too, because a client domain in an agency account is a liability for both sides. Worth saying up front: an agency holding a client’s domain usually got there through convenience rather than malice — someone had to register the thing in week one, and the agency was already logged in. The fix is usually administrative, not adversarial. Below: how ownership works, the 60-day trap, what to do when a handover goes wrong, and what the contract should say.

Who actually owns a domain — the name on the record or the login?

Both matter, and they’re formally different things. ICANN’s 2013 Registrar Accreditation Agreement defines two separate roles: the Registered Name Holder — the registrant — and the Account Holder, the person or entity paying for or otherwise controlling management of the name when that isn’t the Registered Name Holder. ICANN’s own contract contemplates that the name on the record and the hands on the account can be different parties. (The domain glossary covers the cast of characters.)

On paper, the registrant is the owner. In practice, control follows login credentials: whoever holds the registrar account password and its 2FA can change the registrant, repoint DNS, or start a transfer, whatever the record says. So ask two questions: whose name is on the registration, and who can log in? Healthy: the business, twice. The common agency setup answers the second — sometimes both — with the agency.

Why does the agency have it in the first place?

The usual story: registration was one small step in an onboarding session that also set up hosting, DNS, and email, and the domain landed in the agency’s account by path of least resistance. Nobody chose an ownership structure; one congealed.

It helps to see the four layers — domain registration, DNS hosting, web hosting, email hosting — as the independently swappable relationships they are. An agency can legitimately hold some and not others — control of one doesn’t imply control of another, and running a client’s hosting and DNS is ordinary service delivery. Registration is the layer that belongs with the business, because everything else hangs off it.

Can’t you just check the WHOIS contacts to see who owns it?

Not anymore. If “you’re listed as the admin contact” was ever the reassurance, that signal is largely gone. ICANN’s Registration Data Policy took effect on 21 August 2025, establishing a “Minimum Data Set” in which only the Registrant contact is mandatory. The Billing contact was eliminated outright; the policy permits — rather than requires — registrars to delete admin-contact data collected before it took effect, which the large ones have largely done; and the Tech contact survives as an optional element a registrar may still offer. GoDaddy, for one, stopped displaying those contacts and deleted the historical records for most domains, while noting that other contact information can still be collected without appearing in public listings. Separately, since 28 January 2025 gTLD registrars are no longer contractually obliged to run a WHOIS service at all; RDAP is now the authoritative lookup protocol.

The upshot: if “you’re the admin contact” was your claim to the domain, that comfort blanket has been retired. Checking ownership today means reading the registrant field over RDAP — frequently redacted, and GDPR, WHOIS privacy, and your domain covers what’s actually visible there — then asking the better question: whose registrar account is it in?

How do you move ownership when everyone agrees?

Amicable handovers are the common case, with exactly one trap to know before you touch anything.

Correcting the registrant is a formal process. Under ICANN policy, a “material change” of registrant is a change to the registrant’s name, organization, or email (or the admin contact email where there’s no registrant email) that isn’t a typo fix — and registrars may treat any change to the name or organization field as material. Both the prior and the new registrant must confirm; once both do, the registrar must process within one day.

There’s a wrinkle here that cuts directly against the client, and almost nobody mentions it. The Transfer Policy lets either party appoint a Designated Agent to approve the change on its behalf — and major registrars appoint themselves in their own registration agreements. Namecheap, for instance, documents that when it acts as Designated Agent the registrant doesn’t need to receive or confirm an email for the change to proceed. So the confirmation email you’re picturing may never arrive: an agency with account access can complete a registrant change without anything landing in the client’s inbox. If you’re the client, don’t treat “I never got an email” as evidence that nothing happened.

Now the sequencing trap: a confirmed change of registrant triggers a mandatory 60-day lock against transferring the domain to another registrar. The policy permits an opt-out but doesn’t require registrars to offer it — DNSimple states plainly that it doesn’t support opting out — and only the prior registrant can exercise it, only before the change is submitted.

The cleanest answer is to get the order right, and ICANN’s own policy tells registrars to advise it: if the endgame is a different registrar, do the inter-registrar transfer first, then change the registrant. That sidesteps the 60-day lock entirely, rather than opting out of it or waiting it out. Full moving-day mechanics are in transferring a domain to another registrar.

Don’t confuse the ICANN lock with ordinary registrar lock — but don’t assume they’re unrelated either. clientTransferProhibited is normally voluntary and toggleable from the control panel. However, registrars aren’t required to use a particular status code for the 60-day lock, and ICANN’s implementation note says that a registrar choosing to use clientTransferProhibited for it must lock the name so the registrant cannot remove it. Same status code, two different rules — which is exactly why the toggle sometimes appears greyed out or silently re-applies itself.

One forward-looking note, and it matters more than it sounds. ICANN’s board adopted Transfer Policy changes on 7 June 2026 that lift change of registrant out of the Transfer Policy entirely, into a standalone Change of Registrant Data (CORD) policy — and in the process remove the 60-day post-change lock, the Designated Agent role, and the requirement to get confirmation from both registrants. Separately, the registration and post-transfer locks drop to 30 days. None of it is in effect: an Implementation Review Team has to turn the recommendations into policy language first, and registrars have asked for an 18-month buffer after that work concludes — so this is years away, not months. Plan around today’s rules; just know the ground is due to move, and that most of the traps in this section are the ones being removed.

What if the agency won’t hand it over?

What follows is general information about policies and reported cases, not legal advice — for a live dispute, talk to a lawyer in your jurisdiction.

First, separate the fights. If the standoff is really an unpaid-invoice dispute wearing a domain costume, none of the routes below resolves the contract question — settle that on its own track. Then, roughly in order of speed:

Check whether you’re already the registrant — because if you are, you have a direct right most people never use. This is the single most useful thing in this article, and it costs nothing. Under ICANN’s Transfer Policy, a registrar must give the Registered Name Holder the authorization code and remove clientTransferProhibited within five calendar days of the holder’s request where it doesn’t offer self-service. The process for doing so may be no more restrictive than the one for changing any other contact or nameserver detail. And a registrar must not refuse to release the code or lift the lock solely because of a payment dispute between it and the registrant. So if the business is named as registrant but locked out of the agency’s account, the route isn’t a lawyer — it’s an identity-verified request straight to the registrar, with a deadline attached. If the registrar stonewalls, that’s an ICANN Contractual Compliance complaint, which is free.

That’s the distinction to hold onto: ICANN won’t referee who owns a domain, but it does enforce what registrars owe the named holder. “Don’t expect ICANN to help” is true of the first and wrong about the second.

The registrar’s own dispute channel. Where the registrant of record isn’t you, the registrar’s dispute or account-recovery process is the next stop. Be realistic about the bar: no registrar hands over a domain on mere assertion of entitlement — they require proof of identity matching the account record, the account credentials or authorization code, or a court order or arbitration award. That barrier is deliberate; it’s the same one that stops social-engineering domain theft. (GoDaddy’s public “Request for Dispute on Transfer Away” form is a narrower thing than it sounds — it’s for domains that have already been transferred away, not for one still sitting in someone else’s account.)

UDRP — often the wrong tool, but not always, and the difference is factual. UDRP is available in principle to a trademark holder, and it’s the standard play when a stranger registers your business name. Agency disputes run into its conjunctive test: the complainant must show the domain was registered and used in bad faith. Where the agency registered the name fresh, as a legitimate act during a working relationship, that first limb usually fails — and the “retroactive bad faith” theory some 2009–2010 decisions floated has not been followed since.

But there’s a second, very common fact pattern where the analysis flips. WIPO’s panel consensus treats a transfer to the current holder as the relevant registration date — so if the client registered the domain first and later pushed it into the agency’s account, it’s the agency’s acquisition that gets assessed for bad faith, not the original registration. Panels have ordered transfers on facts like these. Which pattern you’re in is a question of history, not vibes: find out who registered it and when it moved.

Its remedies are narrow regardless — transfer, cancellation, or denial; no damages, no ruling on the underlying contract — and the Policy doesn’t bar court action either way. If you do win, note that the registrar waits ten business days before implementing, and a respondent who files suit in that window stops it.

Two cautions before anyone files. A complaint brought where the complainant clearly ought to have known it could not succeed can draw a published finding of Reverse Domain Name Hijacking — a real cost for a client with a weak case, and the only outcome an agency can actually “win.” And withholding payment does not create a claim on a domain; a client may owe the invoice regardless of who holds the name.

Outside gTLDs, the rules differ — sometimes in your favour. The above is the .com-style regime. Country-code registries run their own processes, and at least one is materially easier: Nominet’s DRS for .uk turns on an “Abusive Registration”, defined as a domain registered, acquired or used unfairly — a disjunctive test, so the very limb that sinks most gTLD agency complaints doesn’t apply. (DRS administration moved to WIPO in July 2026.) .de has DENIC’s DISPUTE entry, which blocks transfer and assigns you the name if it’s ever released, and .eu has its own ADR. If your domain isn’t a gTLD, check the registry before concluding you have no route.

Court — and warnings in both directions. In the United States, courts have found that using a domain as leverage in a business or payment dispute can violate the Anticybersquatting Consumer Protection Act; the reported case, DSPT International, Inc. v. Nahum, concerned a departing employee rather than an agency, and statutory damages there run to five figures per domain. The predicate matters, though, and the article would be misleading without it: ACPA requires the domain to be identical or confusingly similar to a trademark the claimant owns, and bad-faith intent to profit from that mark. If your business name isn’t a protectable mark, this route likely isn’t open — which is also why agencies shouldn’t read it as blanket exposure.

The honest summary for agencies: holding the domain over an invoice is the move that creates liability. Suspending work, or hosting, or deliverables under the terms of your contract is a different thing, generally lawful, and usually the lever you actually have. Use that one.

And the option nobody wants to say out loud: change the name. If you’re not the registrant, the domain isn’t a trademark you own, no ccTLD process applies, and the agency won’t move — the remaining routes are a lawsuit or a rebrand, and for a small business the lawsuit is frequently the more expensive one. That’s a genuinely bad outcome, not a silver lining, and it’s worth pricing honestly against the alternatives rather than fighting on principle. When and how to rename a project covers doing it without losing what you’ve built.

What happens if nobody renews it during a standoff?

Nothing rescues it automatically — a disputed domain follows the ordinary expiry lifecycle regardless of who’s feuding: an auto-renew grace period of up to 45 days, then a 30-day Redemption Grace Period in which it’s restorable (usually for a premium fee), then 5 days of Pending Delete, then public re-registration. Don’t count on that last step, though: registrars routinely auction expiring names during the grace period, so a contested domain can be sold to a stranger before it ever drops. An agency that’s stopped caring plus a client who can’t log in is exactly how names die. Whatever else is unresolved, make sure someone renews — and if it’s already lapsed, move fast with recovering an expired domain.

What does a healthy client–agency setup look like?

One principle: the client owns the registrar account; the agency gets delegated access. Most major registrars support some version of that — though not all do, and the defaults are worse than the principle implies. Verified July 2026:

Registrar	Mechanism	What delegated access actually grants	The catch
Porkbun	Authorized Users; Subaccounts	Authorized Users get full access to the account and every domain in it — not per-domain, not scoped to one engagement	But they cannot unlock a domain, initiate a transfer, or pull an auth code. Subaccounts keep transfer control at the parent
GoDaddy	Delegate Access	Folder-based permission levels — but a delegate granted the top level can make purchases with saved payment methods, and a delegate granted Transfer rights can move domains out, delete them, or list them for sale	Domain delegates default to Administrative Access to All Domains. Safe only if you deliberately withhold Transfer and scope the folder
Squarespace Domains	”Invite domain manager”	Manage settings and DNS, connect to a site, add and remove other contributors — and transfer the domain away	Only the Owner contact receives the transfer authorization email, which is the real brake. Owner-only: billing, auto-renew, reactivation, deletion
Cloudflare	Role-based multi-user access	Roles scoped at account, domain, and resource level	Domain-scoped roles and the Organizations feature are Enterprise. Small accounts get much blunter controls
Namecheap	Share Access	Another Namecheap account receives granular per-setting permissions	Namecheap’s own docs decline to enumerate the permission set; we could not confirm that contact changes are non-shareable
Hover	None	No delegate or shared-access feature — third parties log in as the owner, using a 2FA code the owner emails them each time	The thing this whole section says not to do

Read that table as a warning as much as a menu. Porkbun comes closest to the ideal — an Authorized User can run the domain day to day but structurally cannot move it — but “scoped to the work” oversells even that, since access is account-wide. GoDaddy’s and Squarespace’s delegation can hand over the transfer lever itself unless it’s deliberately configured not to. Granting access is not the same as retaining control; check what the default actually permits before you rely on it. (Squarespace Domains, for context, is where Google Domains customers landed after the 7 September 2023 acquisition.)

Two things this model quietly assumes, and both are worth checking.

There may be no client-facing account at all. A large share of agency-held domains don’t sit in a retail registrar account — they sit behind a reseller platform, where the agency buys through an upstream provider and the client has no login to be granted. Delegated access isn’t an option there; the only routes are through the agency or the upstream registrar. If you’re a client and can’t find your domain at any registrar you recognise, a reseller arrangement is the likeliest reason.

Moving the account isn’t finished until the recovery paths move. The classic post-handover failure is an account that now belongs to the client while its password-reset email, recovery phone, and 2FA still point at someone at the agency. That’s not ownership; it’s a courtesy. Re-point every recovery channel as part of the handover, not afterwards.

Choosing a home for the account? See the best registrars for indie hackers — then lock it down per the first hour after registering a domain before handing out any access.

What should the contract actually say?

There is no ICANN, legal, or industry-body standard governing domain-ownership clauses in web-design contracts. Even the AIGA Standard Form of Agreement for Design Services — the closest thing to a recognized industry template — covers IP and deliverable ownership but contains no domain-specific provisions. What exists is a remarkably consistent practitioner consensus — industry norm and best practice, not a legal requirement:

• The domain is registered in the client’s name — the client is the registrant from day one.
• The client gets full access to registration and hosting information — no mystery accounts.
• The client owns the domain outright once paid — in writing.

For agencies, this isn’t a concession; it’s a differentiator. “You’ll own your domain, in your own account, from day one” is an easy thing to say in a pitch, and clean offboarding beats the alternatives. But it does carry a real cost that’s worth pricing rather than absorbing: once the client holds the account, you can no longer guarantee renewal — and you will still get the call when the site goes dark. So get the other half in writing too:

• Renewal is the client’s responsibility, and the agency isn’t liable for expiry or lapse.
• The agency is removed as a contact at offboarding, so it stops being the default blame address.
• Offboarding is a defined, billable task rather than an unpaid scramble.

(Agencies naming their own studio: that’s its own guide.)

Domain Yoga can’t move a domain, referee a dispute, or register anything — it’s a naming tool, and no part of this article is a problem it solves. The one place it’s relevant is the exit above: if a name is genuinely unrecoverable and rebranding is the cheaper road, Domain Yoga turns one prompt into roughly 250 availability-checked, brandability-ranked ideas for $2–$5 per search. That’s the whole claim.

This article is general information about domain policies and industry practice, not legal advice. Ownership disputes turn on contracts and jurisdiction; for anything live, consult a lawyer.