Who Actually Controls Your Domain Name, and the 60-Day Trap Most Owners Find Too Late

Three parties, and only one of them is you

The registrant is the entity the domain belongs to, the registrar is the company that sells and manages the registration, and the account holder is whoever can actually log in. Those are frequently three different parties, and the third one is the practical answer to who controls it.

Start by separating the roles, because the confusion here causes real damage. The registrant, or in policy language the Registered Name Holder, is the entity in whose name the domain is registered. The registrar is the accredited company that sells and administers it. Then there is the entirely unofficial third role: whoever knows the login. In small businesses that third person is very often a developer or a marketing agency from years ago.

The policy is clear about whose word carries weight. It states that the Registered Name Holder and the Administrative Contact are the only parties with authority to approve or deny a transfer request, and that in a dispute the Registered Name Holder authority supersedes that of the Administrative Contact¹. So the name on the registration matters more than who holds the password. That is genuinely reassuring, provided the name on the registration is yours.

Which is the thing to go and check today rather than at the point of crisis. Registration data for a domain is published through what the current policy calls RDDS, the Registration Data Directory Services, and your registrar can tell you what is recorded against your name¹. If the registrant is a former developer, a defunct agency, or a personal email nobody monitors, you have a problem that is entirely solvable now and considerably less solvable during an outage.

It is worth noting the scope. These are the rules for generic top-level domains, the .com, .net and .org family. Country-code domains run their own policies, so if you hold a ccTLD the specifics below may not apply to you even where the principle does.

The 60-day trap, and the order that avoids it

Changing the registrant email address counts as a Change of Registrant, which can impose a 60-day lock on moving the domain. ICANN requires registrars to advise transferring first and updating details second. Almost everybody does it the other way round.

Here is the sequence that catches people. You decide to move your domain somewhere better managed. Being organized, you first log in and correct the contact details, because the email on file is an old one. Then you request the transfer and discover you cannot move for two months.

The policy defines a Change of Registrant as a material change to the registrant name, organization or email address, and states explicitly that any change to the registered name holder email address is a material change¹. It then requires that a registrar must deny a transfer where it imposed a 60-day inter-registrar transfer lock following a Change of Registrant and you did not opt out of that lock before making the request¹.

ICANN clearly knows this catches people, because it obliges registrars to warn you. The policy requires the registrar to inform you that if your final goal is to transfer the domain to a different registrar, you are advised to request the inter-registrar transfer before the Change of Registrant, in order to avoid triggering the 60-day lock¹. Whether that warning reaches you in a form you notice is another matter entirely.

Two other 60-day windows exist alongside it. A registrar may deny a transfer requested within 60 days of the creation date shown in the registry record, and may deny one within 60 days after the domain was previously transferred¹. So a freshly registered domain and a freshly moved domain both sit still for a while. None of this is a reason to panic. It is a reason to plan the order.

1. Decide where the domain is going first. Choose the destination before you touch anything, because the sequence depends on it.
2. Do not update the registrant details yet. Changing the name, organization or email address is what arms the 60-day lock.
3. Unlock and request the transfer code. The registrar has five calendar days to provide it if there is no self-service option.
4. Complete the transfer. Move the registration to the destination registrar first, while the details are still whatever they were.
5. Then correct the contact details. Once the domain has arrived, update the registrant record properly at the new registrar.
6. Record where it lives and when it renews. Somewhere that is not one person’s memory, and not an inbox on the domain itself.

If your registration is currently in somebody else’s name, fix that first and accept the 60-day wait as the cost of doing it properly. A lock you chose is a very different situation from a lock you discover during an emergency.

What a registrar is not allowed to do

A registrar may not use the transfer process to collect money, may not deny a transfer simply because you have not responded, and must hand over the transfer code and remove the lock within five calendar days. Silence defaults to allowing the transfer, not blocking it.

This section exists because of a specific and common situation: the developer who built the site also registered the domain, the relationship has ended, and the domain is now leverage. Owners in that position usually assume they have no options. The policy says otherwise, and it is worth reading the actual wording rather than accepting the first no.

On money, the policy is direct. It states that in the event of a dispute over payment, the registrar must not employ transfer processes as a mechanism to secure payment for services, noting that it has other collection mechanisms available that are independent of the transfer process¹. There are narrow exceptions concerning unpaid previous registration periods, but a general commercial dispute is not one of them.

On the practical obstacles, the list of things that are not valid grounds for denial includes nonpayment for a pending or future registration period, no response from the Registered Name Holder, and a domain sitting in registrar lock status where you were not given a reasonable opportunity to unlock it¹. And the policy sets a clock: where the registrar does not provide self-service facilities, it must give you the unique AuthInfo code and remove the ClientTransferProhibited status within five calendar days of your initial request¹.

The most useful clause is the one about doing nothing. The policy states that where the Registered Name Holder has not confirmed the request and the registrar has not explicitly denied it, the default action is that the registrar must allow the transfer to proceed¹. Stonewalling is not an effective strategy, because the process is built to move forward in the absence of a decision rather than stall. If you are being ignored, that clause and your registrar complaint route are the two things to reach for.

• A billing argument is not grounds to hold your domain.
• Not replying to them is not grounds for denial either.
• Five calendar days to hand over the code and remove the lock.
• Silence from the losing registrar defaults to the transfer proceeding.
• The registrant name outranks the administrative contact in a dispute.

What expiry actually does, which is worse than most people expect

The registrar is required to interrupt DNS resolution once a registration expires, so the site and email go down by design rather than by neglect. After deletion there is a 30-day redemption window, restore fees apply, and the warning emails may go to an address on the domain that has already stopped working.

Most owners assume expiry is like a late bill: a warning, then eventually a consequence. The Expired Registration Recovery Policy describes something more abrupt. It requires that the existing DNS resolution path be interrupted by the registrar, both for registrations deleted within eight days of expiry and, for later deletions, across at least the final eight consecutive days during which the registration remains renewable².

Read that as a business owner. Interrupting DNS resolution does not only take the website down. It takes down anything that depends on the domain, and for most small businesses that includes email. The moment the site goes dark, the channel most customers use to reach you goes dark alongside it, which is why an expiry is so much more expensive than the renewal fee it started as.

The warnings are real but easy to miss. Registrars must notify the holder at least twice before expiry, approximately one month before and approximately one week before². ICANN also records a best practice that registrars should advise holders to provide a secondary email point of contact that is not associated with the domain name itself, so reminders can still arrive if the domain stops working². That advice exists because the alternative is sending an expiry notice to an inbox the expiry has already disabled.

If it goes past deletion there is still a route back, and a cost. Registries must offer a Redemption Grace Period of 30 days immediately following deletion, during which the deleted registration can be restored at the holder’s request by the registrar that deleted it². Registrars must make their renewal, post-expiration renewal and redemption or restore fees available². Those restore fees are typically far above a normal renewal, and we are deliberately not quoting a figure because it varies by registrar and you should check your own.

What to do this week

Find out who the registrant is, get the renewal date somewhere durable, put a contact address on the record that does not depend on the domain itself, and turn on auto-renew. None of this costs anything and all of it prevents the expensive version.

The whole subject collapses into a short list of things that take an afternoon. Confirm which registrar holds the domain and log in yourself rather than being told what it says. Check that the registrant name is your business and not an individual who no longer works with you. Note the renewal date somewhere that is not a single person’s memory.

Then fix the contact address, because this is the failure that turns a small problem into an outage. Put an email on the record that does not sit on the domain in question, exactly as ICANN best practice recommends². A free mailbox on another provider is fine. The requirement is simply that it keeps working on the day the domain stops.

Turn on auto-renew, and separately confirm the card on file has not expired, since an auto-renew pointed at a dead card is a manual renewal wearing a disguise. Then, if the registrant details need correcting and you also intend to move the domain at some point, remember the order: transfer first, correct second¹. Doing it in the other sequence is what costs you 60 days.

Where we come into this is small and worth stating plainly. When we take on a site we make sure the domain is registered to the business rather than to us, that DNS sits somewhere the business can reach, and that renewal is not one forgotten calendar entry away from an outage. We do not want to be the answer to the question this article asks, which is the same reason we wrote about who is responsible for applying updates. If you would like a look at how your setup is currently arranged, our free SEO audit is the easiest starting point.