Skip to content

Problem

The domain is in the previous agency’s name

The client believes they own their domain name, and the previous agency is listed as the registrant. Until that is corrected, the agency decides the fate of the site, the mail and the renewal.

Two separate operations, in this order: move the registrant to the client’s name, then, only afterwards, transfer the name to your registrar if you want to. Running them back to back triggers a sixty-day lock on transfers — and leaves the name parked at the registrar you were trying to leave.

Do this right now

Four moves. None of them is urgent the way an outage is urgent. All of them become urgent the day the outgoing agency stops replying.

  1. Establish who is actually the registrant

    5 min

    Query the registry over RDAP. Since the GDPR the registrant’s contact details are often redacted in public answers; the registrar is always visible, along with the creation and expiry dates and any status codes on the name. Write it all down: it is the starting point of the conversation, and it is not open to debate.

  2. Ask the outgoing agency, in writing, for a change of registrant

    10 min to write

    A change of registrant happens at the current registrar: you do not need a transfer to get it, and it is the operation that actually matters. Phrase it as a named operation, not as a favour. Copy the client in: they are the principal, and the presence of their name changes the tone of the replies.

  3. Then ask for the authorization code and the removal of the transfer lock

    5 days maximum

    The registrar must give the registrant the name’s AuthInfo code and remove the clientTransferProhibited status within five calendar days of the request, unless it provides the means to do it directly. And it is not allowed to refuse solely because of a payment dispute between itself and the registrant. Quote both points if you are kept waiting.

  4. Check the sixty-day locks before starting the transfer

    2 min

    Three situations block a transfer for sixty days: a recent registration, a recent transfer, and a recent change of registrant. The creation date is published by the registry; the other two are your own operations, so you already know them. Starting a transfer without looking costs two months.

The three sixty-day locks

They exist to stop domain hijacking, and they turn against you when you discover them after the fact. Only one of the three can be avoided, and only if you think of it beforehand.

  • Sixty days after the initial registration
    What it blocksTransfer to another registrar.
    How to avoid itYou wait. The creation date is published by the registry: look at it before promising a migration.
  • Sixty days after a registrar transfer
    What it blocksAnother transfer.
    How to avoid itYou wait, or you pick the right registrar first time rather than hopping twice.
  • Sixty days after a change of registrant
    What it blocksTransfer to another registrar.
    How to avoid itThe registrant may opt out of this lock — but only before requesting the change of registrant. Afterwards it applies.

Source: ICANN Transfer Policy (version published 21 February 2024), sections I.A.3.8, I.A.3.9 and II.C. The third lock is the only one that can be waived, and the waiver is requested before the operation, not after. That is why the order of the two steps matters so much.

The email to the outgoing agency

Tone is everything here. No threat, no apology: a request for a named operation, with the client copied and a date attached. Vague requests go unanswered; this one is hard to ignore.

Subject: example.com — change of registrant request

Hello,

I am taking over the website for [client], who has asked me to regularize the situation of their domain name example.com. The registry currently lists your company as the registrant.

I am therefore requesting a change of registrant to [client’s legal entity], using the following details: [details]. This operation takes place at your current registrar and does not involve any transfer on your side.

Please also send us the name’s authorization code and remove the transfer lock status, so that [client] can freely choose their registrar afterwards.

[Client] is copied on this message and confirms the request. Could you let me know by [date] when you expect to carry out the operation?

Kind regards,

Three things make this message work: it names the exact operation (change of registrant, not transfer), it makes clear that it costs the outgoing agency nothing, and it asks for a date rather than an agreement in principle. Copying the client is not pressure, it is proof the request comes from the principal.

The four misunderstandings that cost the most

None of them is technical. All of them are paid for in weeks.

  • Confusing registrant and registrar

    Changing registrar does not change the registrant, and changing registrant does not change the registrar. Two operations, two forms, two effects. Only the first one protects the client.

  • Believing redacted Whois hides everything

    Since the GDPR the registrant’s details are often absent from public answers. The registrar, though, is always visible — and everything goes through the registrar. The registrant’s anonymity blocks nothing.

  • Accepting a refusal based on an unpaid invoice

    A registrar may not withhold the authorization code or the removal of the transfer lock solely because of a payment dispute with the registrant. It is written into ICANN’s Transfer Policy, and quoting it often unblocks the situation in one reply.

  • Launching the transfer right after the change of registrant

    This is the trap that costs two months: the lock fires at the change of registrant, and you stay sixty days at the registrar you wanted to leave. Ask to opt out before the operation, or build the wait into your plan.

Why it happened

Without any bad intent, most of the time. At the start of a project somebody has to buy the name quickly; the agency already has an account and a card on file, so the agency buys it. Nobody asks who will be listed as the registrant, because on the day of purchase it has no visible consequence.

The consequences arrive three years later, when the relationship ends. The registrant is the only party who can authorize a transfer, change the name servers or renew the name. An outgoing agency has no reason to be malicious, but it has a thousand reasons to be slow: it no longer bills the client, nobody owns the file, and the request lands in a generic inbox.

On top of that sits a vocabulary trap that catches everyone: “it’s our domain, we pay for it” is not the same thing as “we are the registrant”. Paying the renewal invoice does not make you the registrant of a domain name.

How to avoid it next time

Buy the name on an account in the client’s name, with their address and an email address that belongs to them, even if you do the clicking and front the cost. You keep the access, they keep the ownership, and the day you part company is settled before you have started.

Write it into the quote, in one line: who is the registrant, at which registrar, and who pays the renewal. That line will one day spare you a painful conversation with a client who has not misunderstood anything — nobody had told them.

And check the registrant at every takeover, before signing. It is a three-minute lookup that tells you whether the file you are inheriting contains a time bomb.

See what the registry publishes about this domain

The report reads the registrar, the dates, the name servers, the certificate and the email authentication in one pass. Enter the client’s domain: in thirty seconds you will know where it lives and what state it is in.

No sign-up, no email required. You can paste a full address — we'll pull the domain out of it.

Knowing who owns what, across every client.

DomainVigil keeps the inventory of your portfolio — registrar, renewal date and state for each domain — and warns you when one of them moves. Five domains free, no card required.

Five domains free, forever. No card required.