After You Buy a Domain: Transfer, Registrar Lock and the Rules
The payment has gone through and you have a confirmation email. The domain is technically yours, but it is not yet doing anything: it may not be in your registrar account, it does not point at your website, and nothing stops a careless click from sending it somewhere else. This guide covers the stretch between "purchase complete" and "the name is safely in my account and serving my site", including the ICANN transfer rules that decide when a domain is allowed to move.
What happens right after an Atom purchase
Every domain Rovaryn sells completes on Atom.com, with an escrow-backed, guided transfer that is typically done in 1 to 3 days. Atom's How It Works page describes the first steps from its side: its transfer specialists reach out after the purchase, typically on the same business day, and once they have confirmed the transfer details with you, transfers are typically initiated to your account within one business day.
The detail they will ask for first is where the domain should go. Have two things ready before you buy:
The registrar you want to use, and an account there in the name of the person or company that should own the domain.
The registrant details you want on the record. Decide now whether the name belongs to you or your company. Changing it later is another change of registrant, with its own rules (covered below).
If you are on a lease-to-own or payment plan, the order is different. Atom says it holds the domain in escrow until it is fully paid off, but its team can help with changes such as nameservers so you can start using the name after the first installment. The registrar transfer described here happens at the end of the plan.
Two ways a domain reaches you
There are two routes from the seller to you, and the rules differ.
A push within the same registrar. If the domain already sits at the registrar you use, it can be moved from the seller's account into yours. The domain never leaves that registrar, so no inter-registrar transfer takes place.
A transfer between registrars. If you want the domain somewhere else, it moves from one ICANN-accredited registrar to another. That is the process ICANN's Transfer Policy governs, and it relies on two things: an authorization code and an unlocked domain.
Some buyers do both. They take the domain into an account wherever it currently is, then move it to their preferred registrar later. That is fine, but it is the case where the timing rules below matter most.
The auth code
ICANN defines the Auth-Code (also called an authorization code, AuthInfo code or transfer code) as a code created by a registrar to help identify the domain name holder and prevent unauthorised transfers. The gaining registrar asks for it when you start a transfer in; without it, the transfer does not go through.
Under the current Transfer Policy, registrars must give the registered name holder the AuthInfo code within five calendar days of the holder's initial request. Most registrars show it in the control panel or email it straight away.
Treat the code like a password. Anyone who has it, plus an unlocked domain, can start a transfer. Do not paste it into a chat with someone you do not know, and if you no longer need an old code, ask your registrar to reset it.
Registrar lock
Registrar lock is the switch most registrars show as "transfer lock" or "domain lock". Under the hood it sets an EPP status code called clientTransferProhibited. ICANN's EPP status code guide says this status "tells your domain's registry to reject requests to transfer the domain from your current registrar to another."
The practical rules:
To transfer out, the lock must be off. ICANN's name-holder FAQ says registrars must provide a readily accessible and reasonable means for name holders to remove the lock status.
Once the domain has arrived, turn the lock back on. It is the simplest protection against an unauthorised transfer.
Some locks are not yours to remove. A serverTransferProhibited status is set at the registry level, and ICANN's guide says it prevents a transfer from your current registrar to another. If you see it, ask your registrar why it is there.
You can check a domain's status codes yourself through a lookup tool or your registrar's website, as ICANN's guide suggests. A status of pendingTransfer means a transfer request has been received and is being processed.
ICANN's transfer rules: what applies now, and what is changing
The current Transfer Policy has three timing rules that catch new owners out.
After an inter-registrar transfer. A registrar may deny a transfer request if the domain was transferred to another registrar within the previous 60 days.
After registration. A registrar may deny a transfer requested within 60 days of the domain's creation date. Premium names are usually much older than that, so this rarely applies to a purchase.
After a change of registrant. The registrar must impose a 60-day inter-registrar transfer lock after a change of registrant. The policy lets the registrar allow the name holder to opt out of that lock before the change is requested.
A purchase almost always involves a change of registrant, because the domain moves from the seller's name to yours. Depending on how your transfer is done and whether an opt-out was offered, that can mean the domain cannot leave its new registrar for 60 days. If you know you want the domain at a particular registrar, say so at the start, so it lands there first time.
The other timing rule in the current policy works in your favour: if the losing registrar does not respond within five calendar days to the registry's notice of a transfer request, the transfer is approved by default.
These rules are changing. ICANN's Transfer Policy Review produced a final report with 47 policy recommendations. It removes the change-of-registrant lock and shortens the other locks to 30 days. The recommendations are approved but implementation is still pending, so the 60-day rules above remain the ones registrars apply until the new policy takes effect. Before any transfer, ask your registrar which version it is applying.
Pointing the domain at your site
Owning the name and using it are separate steps. Once the domain is in your account, you connect it to wherever your site, email or app is hosted. There are two common setups:
Change the nameservers to your DNS provider or host. This hands the whole zone to them.
Keep the registrar's DNS and add records yourself: typically A or CNAME records for the website and MX records for email.
Changes do not reach everyone instantly. Cloudflare's TTL reference explains that a record's Time to Live controls how long it is cached, and so how long updates take to reach end users. A useful habit is to lower the TTL on records you plan to change a day ahead, then raise it again once things are stable.
If you are moving an existing site to the new name
Many buyers already have a site on a weaker domain. Google's site move guide recommends server-side permanent redirects, such as 301 or 308, from old URLs to new ones. It also says that when you change domain names you should submit a Change of Address in Search Console for the old site. It advises keeping the redirects for as long as possible, generally at least one year, so Google can transfer signals to the new URLs.
A worked example (illustration only)
Say you buy BuiltTracker.com, listed at $5,488, for a construction-tracking tool you currently run on a longer, hyphenated name. A sensible sequence looks like this:
Before you check out, open an account at your chosen registrar under your company's name.
Tell the Atom transfer specialist that registrar when they get in touch.
When the domain arrives, check that your company is listed as registrant, turn the registrar lock on and switch on auto-renew.
Lower the TTL, point DNS at your host, and set up email records.
Put 301 redirects on the old domain and file a Change of Address in Search Console.
Keep the old domain registered and redirecting for at least a year.
The domain is real and so is its price; the business and the sequence are an illustration, not a record of a real purchase.
A day-one checklist
Once the domain is in your account, these take about fifteen minutes and head off the most common domain problems:
Registrant is correct. The owner of record is you or your company, not the seller and not an employee's personal name.
Registrar lock is on. Check that clientTransferProhibited shows in a status lookup.
Auto-renew is on, with a payment card that will not expire soon. An expired premium name is an expensive mistake.
The account is secure. Turn on two-factor authentication and use an account email on a domain other than the one you just bought, so a DNS mistake cannot lock you out of your own recovery email.
The auth code is not lying around. If one was shared during the transfer, reset it.
Records are written down. Keep the purchase confirmation and the date the transfer completed. If you move registrars later, you will want to know whether a 60-day (or, under the new rules, 30-day) window still applies.
A domain transfer moves the domain, not any trademark rights. If you are building a brand on the name, a trademark search in your markets is worth doing; this is general information, not legal advice.
Where to go from here
If you are still choosing a name, the full list is at /domains, or you can browse a single category such as SaaS and productivity names. For why the prices are what they are, see Why Premium Domains Cost What They Do. If you have a question about a specific domain before you buy, contact us.
The short version: decide your registrar and registrant before you buy, let the guided transfer put the domain there, lock it as soon as it lands, and expect a lock window if you move it again. The 60-day locks are the current rule, and ICANN's change to 30 days is coming.