How to Verify a Domain Is Clean, Transferable and Free of Restrictions
The 60-day lock that strands your money, the status codes that say a domain cannot move, and how to confirm the seller can actually hand over what they are selling — before you pay.
Checklist item 006: Verify the domain is clean, transferable and free from contractual restrictions
Open checklist →Everything else in due diligence asks whether the site is worth buying. This item asks a blunter question: can the seller actually give it to you?
The failure mode is specific and it is expensive. You agree a price, money moves, and then the domain cannot be transferred for sixty days — or the registrar will not release it, or the person selling is not the registrant of record, or the name is sitting in a redemption period you were never told about. The asset is fine. The handover is not.
Why This Item Strands Money
A website acquisition is really two transfers: the content and hosting, which are easy, and the domain, which is governed by registrar, registry and ICANN rules that neither you nor the seller can waive.
Three reasons to check this before you agree a timeline rather than after:
- Locks are time-based, not negotiable. No amount of goodwill shortens a 60-day transfer lock.
- The seller frequently does not know. Most people selling a content site have never transferred a domain between registrars. "Of course it's transferable" is usually a guess.
- It changes the deal structure. If the domain cannot move for two months, who controls it in the meantime becomes the most important term in the contract.
Step 1: Establish Who Actually Holds the Domain
Start with a registration lookup. Verifying the domain's age already puts you in this record; now read it for a different purpose.
Modern lookups use RDAP rather than classic WHOIS, and most registrars redact registrant details. Redaction is normal, not a red flag. What you are establishing is:
- The registrar of record. Which company actually controls the name.
- The creation, updated and expiry dates. The updated date matters here: a recent change can mean a recent Change of Registrant, which has consequences in Step 3.
- Whether the registrant is a person or a company. If the domain is held by a limited company, the person negotiating with you may not have authority to transfer it, and the company may be the thing being sold rather than the domain.
The verification that actually settles it: ask the seller to make a small, specific change inside the registrar account while you watch — add a DNS TXT record with a string you choose. Anyone can show you a screenshot of a control panel; only the account holder can change a record on demand. Same principle as refusing screenshots of revenue and analytics: verify in the live account or not at all.
Step 2: Read the Domain Status Codes
Every domain carries EPP status codes, visible in any public lookup. They are the registry's own statement of what the domain can and cannot do, and they are not editable by the seller.
ICANN documents each one. These are the ones that matter when you are buying:
| Status code | What it means for your purchase |
|---|---|
clientTransferProhibited | Set by the registrar. Normal and usually good — it is anti-hijacking protection. The seller removes it on request before transfer. Not a problem; just confirm they know how. |
serverTransferProhibited | Set by the registry, not the registrar. Often tied to a dispute or a redemption period. Takes longer to clear and the registrar must go through the registry. Ask why it is there. |
clientHold / serverHold | The domain is not activated in DNS — it will not resolve. Uncommon, and usually linked to legal disputes, non-payment or pending deletion. On a site being sold as a going concern, this demands an explanation. |
redemptionPeriod | The registrar has asked the registry to delete the domain. ICANN states the domain is held in this status for 30 days before being purged. The name is on a countdown to deletion. |
pendingDelete | Appearing alone, the 30-day redemption window has already passed. The domain will be purged and released for anyone to register. |
pendingTransfer | A transfer is already in progress — to someone. Find out who, before anything else. |
clientDeleteProhibited / serverDeleteProhibited | Protective. Fine. |
addPeriod / autoRenewPeriod / transferPeriod | Informational grace periods. transferPeriod tells you the domain changed registrars recently, which matters for Step 3. |
A domain showing redemptionPeriod, pendingDelete, clientHold or serverHold is not a domain you complete a purchase on. Resolve it first or walk.
Step 3: The 60-Day Trap, Explained Properly
This is where most buyers get hurt, and where most guidance is imprecise. There are two different 60-day rules in ICANN's Transfer Policy and they work differently.
The one that is mandatory: Change of Registrant. Section II.C.2 states the registrar must impose a 60-day inter-registrar transfer lock following a Change of Registrant. A registrar may offer the registrant an opt-out, but only prior to the Change of Registrant request — not afterwards, and not by you.
This is the trap, because changing the registrant is exactly what a website sale does. If the seller updates the registrant details to your name at their registrar — the "push" method many sellers suggest because it feels simpler than a transfer — the clock starts, and the domain is stuck at their registrar for 60 days.
ICANN's own policy anticipates this: Section II.C.1.3 advises a registrant planning an inter-registrar transfer to request the transfer before the Change of Registrant. In practice that means: transfer the domain to your registrar first, then update the registrant details. Doing it in the other order costs you two months of control.
The one that is discretionary: recent registration or transfer. Sections I.A.3.7.5 and I.A.3.7.6 let a registrar deny a transfer requested within 60 days of the creation date, or within 60 days of a previous transfer. Note the wording — the registrar may deny; this is a permitted refusal, not an automatic lock. Registrars vary in how strictly they apply it. If the lookup shows a recent creation or transferPeriod status, ask the registrar directly what their policy is rather than assuming.
What to ask the seller, in writing:
- Has the registrant been changed in the last 60 days?
- Has the domain been transferred between registrars in the last 60 days?
- Did you opt out of the Change of Registrant lock at your registrar?
- Will you transfer the domain to my registrar before any registrant details are updated?
A note on policy drift: the Transfer Policy in force is the version ICANN updated on 21 February 2024, which contracted parties had to implement by 21 August 2025. An overhaul from the Transfer Policy Review is working through implementation — proposals include replacing AuthInfo with a time-limited, single-use Transfer Authorization Code. Treat the specifics above as current but verify at transaction time: this is one area where the rules are actively moving.
Step 4: Confirm the Registrar Will Actually Release It
The policy gives the registrant rights the seller may not know they have.
The seller needs to obtain the AuthInfo code (the authorisation code the registry checks before accepting a transfer). Under Section I.A.5.2, where a registrar does not provide self-service tools, it must supply the code and remove clientTransferProhibited within five calendar days of the holder's request. Section I.A.5.5 requires the code to be unique per domain — a registrar handing out one code for a whole portfolio is not complying.
Two things worth knowing:
- A payment dispute is not a valid reason to withhold the code. Section I.A.5.4 says registrars must not refuse to release a domain solely over a payment dispute.
- The code alone does not complete a transfer. Section I.A.5.6 is explicit that the AuthInfo code identifies the holder; a Form of Authorization is still part of the process. So "they gave me the code" is not the same as "the transfer is done".
Ask the seller to request the code during due diligence, not after signing. If the registrar stalls, you want to know while you can still walk away.
Step 5: Check the Expiry and Renewal Clock
Pull the expiry date and compare it against your intended completion date.
- Expiring within 30–60 days — have the seller renew before transfer. A transfer near expiry can fail outright.
- Auto-renew status — confirm whether it is on and whose card is attached. A seller who cancels their card after the sale, while the domain still sits in their account, is a predictable disaster.
Step 6: Trademark and Dispute Exposure
A transferable domain can still be a domain you lose later.
- Search the exact name in trademark registers for your main markets — the USPTO and EUIPO both have free public search. A domain that reads as a registered brand is exposed to a UDRP complaint regardless of who owns it now.
- Search the domain alongside "UDRP" and "WIPO" on Google. Past complaints are published and permanent. A domain with a dispute history is one somebody has already tried to take.
- Check for an unexplained
serverTransferProhibited, which can indicate an active dispute.
This is adjacent to checking whether the domain was ever used for spam: both ask what liabilities arrive attached to the name.
Step 7: Map What Else Lives on the Domain
A domain is rarely just a website. Before you take it over, inventory what breaks when it moves.
- Email. Check the MX records. If the business runs mailboxes on the domain, moving DNS carelessly means losing mail, and the mailboxes may be tied to the seller's Google Workspace or Microsoft 365 tenant, which is a separate migration entirely.
- Subdomains and third-party services. CNAMEs pointing at a help desk, a mailing list, a CDN or an app platform are all accounts you now need credentials for, or the subdomains go dark.
- Verification records. TXT records for Search Console, payment processors, affiliate networks and ad platforms. Removing the wrong one costs you a verified property.
- Who holds the DNS. The domain can transfer while DNS stays at a provider controlled by the seller. Establish where authoritative DNS lives and who pays for it.
Export the full DNS zone before anything changes.
Step 8: Sequence the Transfer and the Money
Order matters more than paperwork here.
- Seller confirms no Change of Registrant in the last 60 days, and does not make one.
- Seller obtains the AuthInfo code and unlocks the domain.
- Funds go into escrow — never a direct transfer, and never before the two steps above.
- Transfer to your registrar first, while the registrant details are unchanged.
- Once the domain is at your registrar and in your account, update the registrant details.
- Escrow releases to the seller.
Doing step 5 before step 4 is the mistake that triggers the mandatory 60-day lock. The sequence above is specifically designed to avoid it, and it costs nothing to follow.
What to Do With What You Find
| Finding | Action |
|---|---|
| Clean status codes, expiry comfortably away, registrant matches the seller | ✅ Proceed |
clientTransferProhibited present, seller knows how to remove it | ✅ Normal protective lock — proceed |
| Expiry within 60 days | ⚠️ Require renewal before transfer as a condition |
| Domain created or transferred within the last 60 days | ⚠️ Confirm the registrar's denial policy before agreeing a completion date |
| Registrant is a company, not the individual selling | ⚠️ Establish authority to transfer in writing before paying |
| Email, verification records or subdomain services on the domain | ⚠️ Inventory and plan the migration; budget the downtime |
| Change of Registrant already made in the last 60 days | ⛔ The domain cannot move between registrars yet — do not pay now |
redemptionPeriod or pendingDelete | ⛔ The domain is on a countdown to deletion |
clientHold or serverHold | ⛔ The domain does not resolve; find out why before anything else |
Unexplained serverTransferProhibited, or a UDRP history | ⛔ Likely a dispute; walk away |
| Seller will not perform a live change in the registrar account | ⛔ You have not established that they control the domain |
Quick Reference Checklist
Before signing off on this item:
- Registration record pulled; registrar of record, creation, updated and expiry dates recorded
- Seller proved account control with a live, requested change, not a screenshot
- Registrant established as the seller, or written authority obtained if it is a company
- All EPP status codes read and each one explained
- Confirmed in writing: no Change of Registrant in the last 60 days
- Confirmed in writing: no inter-registrar transfer in the last 60 days
- AuthInfo code requested during due diligence, not after signing
- Expiry date checked against the completion date; renewal required if close
- Trademark registers and UDRP history searched for the exact name
- Full DNS zone exported, with MX, CNAME and verification TXT records inventoried
- Transfer sequenced before any registrant change, with funds in escrow
This takes under an hour and it is the only item on the due diligence checklist that can leave you having paid for something you cannot take possession of. Everything else affects what the asset is worth. This one affects whether you get it at all.