Domain Escrow Secure Transfer Guide 2026
By Mustafa Bilgic | Last reviewed: 2026-05-18
A good domain sale has two moving parts that do not naturally trust each other: money and control of the name. Escrow exists to keep those pieces synchronized. The buyer should not send irreversible funds to a stranger; the seller should not give away a transferable asset before payment is secured. This guide explains the practical 2026 transfer workflow, using Escrow.com, ICANN transfer rules, and registrar documentation as the baseline.
1. What escrow actually protects
Domain escrow is not magic due diligence. It does not tell you whether a name is a trademark problem, whether the backlink profile is clean, or whether the buyer has a good business plan. Its job is narrower and more important: it controls the sequence. In the standard flow described by Escrow.com's domain process, buyer and seller agree to transaction terms, the buyer funds escrow, the seller transfers the domain, the buyer confirms possession during the inspection period, and escrow releases funds to the seller.
That sequence matters because domain control can move faster than bank risk. A seller who sends an EPP code before verified funding may lose leverage immediately. A buyer who wires money directly to a seller may have only a civil claim if the seller disappears. Escrow changes the bargaining position: the buyer proves funds, the seller proves transfer, and the escrow provider only disburses after the agreed condition is met.
For a $400 forum sale between two long-known domainers, a marketplace checkout may be enough. For a $12,000 two-word .com, independent escrow is usually cheap insurance. For a $75,000 asset, I prefer escrow plus a written transfer plan, screenshots of registrar status, and a short closing call if both sides are serious. The larger the transaction, the less tolerance there should be for vague instructions.
2. Escrow.com-style transaction timeline
| Stage | Seller action | Buyer action | Main risk |
|---|---|---|---|
| Terms agreed | Confirms exact domain, price, fee split, inspection period, transfer method | Confirms registrant account, funding method, invoice details | Wrong domain, wrong party, changed terms |
| Buyer funds escrow | Waits for official escrow confirmation inside the platform | Sends funds to escrow, not to seller | Fake payment screenshots or spoofed emails |
| Transfer begins | Pushes the domain or provides an auth code after escrow confirms secured funds | Accepts account push or starts transfer at gaining registrar | Transfer lock, wrong account, invalid EPP code |
| Inspection | Does not change DNS or contact details unless instructed | Verifies control, WHOIS/RDAP, registrar account, name servers | Buyer confirms too early or delays without reason |
| Disbursement | Receives payout from escrow | Keeps renewal, DNS, and lock settings under control | Post-sale support confusion |
A clean transaction starts before anyone clicks a transfer button. I want the escrow notes to say whether the domain will be pushed inside the same registrar account system or transferred to another registrar. I want the fee split written down: buyer pays all escrow fees, seller pays all fees, or split 50/50. I want the inspection period short and specific. If the buyer needs seven days because a corporate registrar team must accept the name, that belongs in the transaction terms, not in a panicked email after the domain has moved.
3. Push versus inter-registrar transfer
A same-registrar push means the domain stays at the current registrar and moves from the seller's account to the buyer's account. It is usually faster, avoids the public transfer queue, and can solve a lock problem when the domain is less than 60 days old. The buyer needs an account at the seller's registrar, and the seller needs the correct destination username, customer ID, or email address. Never guess this field. A typo can become a support case.
An inter-registrar transfer means the buyer moves the domain to a different registrar. For most gTLD names, the seller unlocks the name and obtains an AuthInfo code, also called an authorization code, EPP code, transfer key, or auth code. ICANN explains that an Auth-Code identifies the registrant for transfer purposes and that registrars must provide it within five calendar days of a valid request. Registrar docs from GoDaddy, Namecheap, and Cloudflare all use the same basic language: unlock the domain, get the code, submit it at the gaining registrar, and wait for approval or auto-completion.
The inter-registrar path is more formal, but not always better. If a buyer purchases ExampleBrand.com from a seller who registered it 25 days ago, ICANN-related transfer restrictions may prevent moving it to a new registrar immediately. In that case, a push at the same registrar with escrow inspection can close the sale, while the buyer waits out the later registrar-transfer window. On the other hand, if the buyer's company requires all assets at Cloudflare, Markmonitor, CSC, or another managed registrar, an inter-registrar transfer may be part of their compliance process.
4. The 60-day lock and AuthInfo details investors miss
ICANN's Transfer Policy is the authority for gTLD inter-registrar transfers. The practical rule is simple: transfers can be blocked during the first 60 days after initial registration, during the first 60 days after a previous registrar transfer, and after certain registrant changes. Registrar documentation may add workflow details. GoDaddy's auth-code help page, for example, warns that domains cannot be transferred within 60 days of new registration, transfer, or a contact information change when the registrant applied that lock. Cloudflare's registrar docs also describe a 60-day restriction and the five-day transfer auto-approval window after a successful request.
For investors, the mistake is treating the 60-day rule as a footnote. It can change the whole closing plan. Suppose you win a drop-caught two-word .com for $1,300 on May 1 and sell it to an agency for $6,500 on May 18. If the agency insists on transferring to its preferred registrar immediately, the deal may stall. If the agency can create an account at the current registrar, a same-registrar push can close quickly. That difference should be explained before the buyer funds escrow.
AuthInfo codes should be handled like one-time deal credentials. Do not paste them into casual email threads before funding. Do not send them through a broker who is not part of the written escrow flow. Do not reuse old codes. If the code fails, ask the seller to regenerate it and confirm the domain is unlocked, privacy settings are not interfering with registrar messages, and no registry status such as clientTransferProhibited remains active.
5. Worked example: a $18,500 .com sale
Imagine a buyer agrees to purchase HarborLedger.com for $18,500 from a private seller. The seller holds it at Namecheap. The buyer normally uses GoDaddy. The parties agree that the buyer pays the escrow fee and gets a two-day inspection period. The seller checks the registrar status before opening escrow: the name is older than 60 days, not recently transferred, not in redemption, and not subject to a dispute. The seller also screenshots the expiration date and confirms that no active website or email will be included.
The buyer funds escrow by wire. The seller waits for the official escrow platform to show funds secured. Then the seller unlocks the domain, requests the EPP code, and sends it only through the escrow transaction instructions. The buyer starts the transfer at GoDaddy, pays the transfer/renewal charge, and watches the pending transfer status. If the losing registrar allows manual approval, the seller approves it. If not, the transfer usually completes after the standard waiting period unless the seller rejects it or a policy block applies.
During inspection, the buyer verifies the domain appears in the GoDaddy account, RDAP/WHOIS reflects the new registrar path, the expiration date makes sense after the added transfer year, and DNS can be changed. The buyer accepts the domain in escrow. Escrow releases funds to the seller. The seller sends a short final note: no site files, trademarks, logos, or email accounts were included; only the domain registration transferred. That last note prevents later confusion.
6. Scam patterns and how to shut them down
- Fake escrow site: A buyer proposes a professional-looking escrow service with a slightly odd domain. Type Escrow.com or the chosen provider's URL directly. Do not follow a link from the counterparty.
- Payment screenshot pressure: A screenshot is not cleared funding. Wait for platform confirmation that the escrow provider has secured funds.
- Changed wire instructions: If bank instructions change mid-transaction, stop. Verify through the escrow provider's logged-in dashboard or support channel.
- Early auth-code demand: The seller should not release an EPP code until escrow confirms secured payment.
- Overpayment story: Any request to refund a mistaken overpayment outside escrow is a red flag.
- Broker impersonation: Confirm that the broker's email domain, marketplace profile, and transaction role all match. Serious brokers do not mind verification.
Domain investors sometimes create their own risk by trying to close too fast. A real buyer who is spending $20,000 can wait an hour while you verify the platform. A real seller who owns a six-figure domain can answer basic registrar questions. Urgency is not proof of seriousness. It is often the opposite.
7. Seller and buyer closing checklist
| Seller checklist | Buyer checklist |
|---|---|
| Confirm exact domain spelling, TLD, registrar, expiration date, and lock status | Confirm the counterparty owns or controls the domain through RDAP, landing page, DNS TXT, or marketplace verification |
| Use escrow or marketplace checkout; never rely on screenshots as payment proof | Fund escrow only through the official provider dashboard |
| Do not provide the AuthInfo code before funds are secured | Prepare the destination registrar account before the transfer starts |
| Keep DNS stable unless the written agreement says otherwise | Verify account control before accepting the domain in escrow |
| Document what is not included: website, logo, content, email, social handles | Lock the domain, update contact details carefully, and set renewal reminders after closing |
Related Names.Center guides: Domain Transfer Guide, How to Sell a Domain, Domain Flipping 2026, and Domain Appraisal Guide.
FAQ
Should every domain sale use escrow?
Not every small sale needs full independent escrow, but any direct transaction with an unknown buyer or seller should use either a recognized escrow provider or a marketplace checkout that controls both payment and transfer instructions.
When should a seller release the auth code?
After the escrow provider or marketplace confirms that payment is secured. An AuthInfo or EPP code can enable a registrar transfer, so it should not be sent casually before the payment side is protected.
Can a domain be sold during a 60-day lock?
Often yes, but the method matters. An inter-registrar transfer may be blocked, while a same-registrar push may be available depending on registrar policy. Explain this to the buyer before escrow is funded.
What if the buyer wants DNS changed before closing?
Do not change DNS before escrow terms say to do so. DNS control can give practical use of the asset before legal closing. If temporary DNS access is required, write that into the agreement and keep escrow aware.
Is Escrow.com the only safe option?
No. Some marketplaces provide integrated escrow-like checkout and transfer control. The point is not the brand name alone; the point is a neutral, verifiable process where payment is secured before the domain moves and funds are not released until transfer conditions are met.
Sources: Escrow.com domain transaction process, ICANN Transfer Policy, ICANN Auth-Code guidance, GoDaddy, Namecheap, and Cloudflare registrar transfer documentation.
Last reviewed by Mustafa Bilgic on 2026-05-18.