Three unrelated jobs get called "domain transfer" and only one of them needs an auth code. Google's own related searches give the confusion away: the most frequent one is moving a domain to a different host, which is not a domain transfer at all and takes about ten minutes with no code and no lock.
Separating them matters, because each carries its own rules and its own clock, and mixing them up is exactly what leaves someone stuck behind a sixty-day lock they never saw coming.

The three jobs
Changing servers. The domain stays where it is and you simply point the DNS records or nameservers at the new host. No auth code, no approval, no lock. The only things to watch are DNS propagation and making sure the site is already running on the destination before you switch.
Changing owner. The domain moves from one person or company to another, which is what happens when a domain is bought or sold.
Changing registrar. Ownership stays put but the domain moves from one registrar to another. This is the only case that needs an auth code, and the only one ICANN's rules govern.
What the policy actually guarantees you
For .com, .net and the other ICANN-governed extensions, the ICANN Transfer Policy promises several things your current provider is unlikely to volunteer.
Your registrar must hand over the AuthInfo code and clear the ClientTransferProhibited status within five calendar days of your request, unless it gives you self-service tools to do both yourself. Memorise the next sentence, because it settles most arguments: a registrar may not refuse to release the code or lift the lock solely because of a billing dispute with you. The policy says so in as many words.
There is a clock running the other way too. If the losing registrar fails to respond to the registry's notification within five calendar days, the transfer defaults to approved. Silence works in your favour, not against you.
The sixty-day lock is three locks
People get caught here because they think there is one lock when there are three. A transfer is refused if it is requested within sixty days of the domain's creation date. Sixty days after any inter-registrar transfer, it locks again. And the third, least known and most damaging, arrives after a change of registrant.
Here is the part that is almost never written down and sits in the policy text itself: you can opt out of that lock before the change of registrant, and ICANN explicitly advises requesting the inter-registrar transfer first if your end goal is a different registrar. Do it in the other order and you wait two months with nobody at fault.
Country domains play by different rules entirely
None of the above binds a country-code registry. ICANN's policy governs accredited registrars for generic extensions; a ccTLD writes its own, and the differences are not cosmetic.
The one we operate inside is a clear example. IRNIC is itself the registry for .ir, with resellers working underneath it, so an inter-registrar transfer in the .com sense does not exist there and no auth code is involved. What IRNIC calls a transfer is a change of ownership between two user accounts inside its own panel. Moving a .ir domain between agents changes which agent manages it, not who registered it.
There is also a current requirement on IRNIC's own site that surprises people: an individual can only file .ir domain requests if their identity has already been verified, and IRNIC is asking domain holders to complete that verification. Registered companies are exempt. If your account is unverified, your transfer is not rejected or locked, it simply cannot be submitted. Whatever ccTLD you hold, read the registry's own page before you plan a date, because this class of rule never appears in a reseller's help centre.
The order we do it in
We bring the site up on the destination server first and test it through a hosts file, then lower the TTL on the records, then switch nameservers, and only then move the registrar. The reasoning is simple: if anything goes wrong mid-transfer, the site and the email are already independent of the old registrar and keep running.
The more common order, domain first and hosting afterwards, is what causes email outages. Mail depends on MX records, and records usually live wherever DNS is served. Move that with the registrar without rebuilding the records somewhere else in advance and messages disappear quietly, with nobody noticing until a customer phones.
Questions people ask
How do I move a domain to a different host?
That job is not a domain transfer. Point the nameservers or DNS records at the new host and you are done; the domain stays with the same registrar and no auth code is needed. If you are choosing a destination, our hosting plans list the specifications side by side.
Is moving a country domain to a new host different?
Not on the hosting side, which is identical. The only difference is where you edit the nameservers, which for .ir means the IRNIC panel or your agent's. The registration conditions themselves are covered on our .ir domain registration page.
How long does a transfer take?
Changing hosts takes minutes to hours depending on TTL. An inter-registrar transfer of a generic domain usually takes five calendar days, because that is the window the policy gives the losing registrar to respond. A change of ownership depends entirely on the registry's own process.
Check this before you start anything
Look up your domain's creation date. If fewer than sixty days have passed since registration or since the last transfer, wait rather than waste an afternoon. If both the owner and the registrar are changing, move the registrar first. And if you would rather hand the whole sequence to someone else, transferring a domain to RGB runs without site or email downtime and is reported back to you at each step. If the site is being rebuilt at the same time, plan the build properly at the outset so you only migrate once.
The ICANN Transfer Policy text and IRNIC's verification notice were both read at source on 19 August 2026.
Comments & Questions
Have a question about this article? Ask, we'll answer.
No comments yet; be the first.