Escrow & Safe Domain Transactions

What Is Domain Escrow?

Domain escrow is a settlement arrangement in which a third party holds the buyer’s funds while the seller transfers an agreed domain. The provider releases funds when the documented conditions are satisfied or handles a dispute under its terms.

Without escrow, the buyer may be asked to send difficult-to-recover funds before receiving control, while the seller may be asked to surrender the domain before payment is secured. Escrow reduces that sequencing problem. It does not eliminate fraud, legal defects, compromised accounts, transfer restrictions, bad due diligence, or unclear contracts.

How a Domain Escrow Transaction Works

1. Agree the transaction: Identify the parties, exact domain, price, currency, fees, taxes, included assets, transfer route, deadlines, inspection period, and acceptance conditions.
2. Open escrow: Create the transaction through a provider independently verified by both parties.
3. Review the provider record: Both parties confirm that the authenticated dashboard matches the signed agreement.
4. Fund escrow: The buyer sends funds using instructions displayed by the verified service.
5. Confirm funding: The seller relies on the provider dashboard—not an email, screenshot, or buyer message.
6. Transfer the domain: The seller performs an internal account push, registrant change, or inter-registrar transfer as agreed.
7. Inspect and accept: The buyer verifies control and any other objective delivery conditions.
8. Release and close: Funds are released under the terms, and both parties preserve the transaction record.

What Escrow Protects—and What It Does Not

How to Verify an Escrow Provider

Do not use a service merely because the counterparty supplies a convincing link. Begin from an independently found official source and verify:

• Exact domain spelling, certificate, corporate identity, contact details, and established public history
• Countries served, currencies, payment methods, prohibited transactions, and identity requirements
• Fee schedule, minimums, refund handling, currency conversion, and who pays each charge
• Inspection, cancellation, dispute, arbitration, governing-law, privacy, and record-retention terms
• Whether it supports domain transactions and the proposed transfer and payment methods
• How official payment instructions and funding confirmations appear inside the authenticated account

The US Federal Trade Commission warns about fake online escrow services that imitate legitimate businesses and direct victims to send money. A polished site, a search advertisement, an email signature, or a registration certificate shown by the counterparty is not sufficient verification.

Terms to Agree Before Funding

• Asset: Exact domain spelling and extension; list any content, code, media, trademarks, social accounts, analytics, email, customer data, or other assets separately.
• Parties: Legal names, representatives, authority, addresses, and required identity verification.
• Economics: Price, currency, taxes, escrow fee, payment fee, transfer/renewal charge, conversion basis, and allocation.
• Delivery route: Internal push, change of registrant, or inter-registrar transfer; losing and gaining accounts; responsible party.
• Preconditions: Funding state, registrar status, unlock, AuthInfo code, dispute status, expiry, and account readiness.
• Timing: Funding deadline, transfer window, inspection period, time zone, business-day definition, and extension process.
• Acceptance: Objective evidence of control and any included-asset delivery.
• Failure: Cure periods, cancellation, refunds, fees, dispute escalation, and treatment of partial performance.

For a material acquisition, have counsel adapt the agreement to the parties, jurisdiction, asset bundle, warranties, indemnities, taxes, and dispute process. Escrow-provider fields are not necessarily a complete asset-purchase agreement.

Verify Seller Control Before Funding

Public registration data may be redacted or protected by privacy services, so it often cannot identify the beneficial owner. Ask for evidence tied to a fresh challenge, such as:

• A temporary DNS TXT record containing a buyer-provided random value
• A temporary file or page served from the domain over HTTPS
• A supervised view of the registrar account showing the exact domain and relevant status
• A registrar-mediated ownership or transfer process where available

Control evidence shows that someone can modify the domain; it does not prove lawful title, absence of theft, authority to sell on behalf of an entity, or clean trademark status. Complete the domain-vetting process and investigate inconsistencies.

Choose the Transfer Route Before Payment

ICANN’s Transfer Policy establishes baseline rules for many generic top-level domains, but registry and registrar procedures can add requirements. Transfers may be affected by initial-registration, prior-transfer, change-of-registrant, dispute, court, or other policy conditions. Country-code domains may follow different rules.

Review the current registrar instructions and our domain-transfer guide. Do not promise a completion date until the exact domain status and route are verified.

Buyer Acceptance Checklist

Before accepting delivery or allowing automatic release, confirm:

1. The exact domain appears in the agreed buyer-controlled account.
2. The buyer can sign in independently and manage the domain without seller access.
3. Registrant and administrative data are correct where applicable.
4. Status codes, expiry date, renewal settings, transfer locks, and renewal price are understood.
5. Nameservers and DNS can be changed; DNSSEC state is known and handled safely.
6. Two-factor authentication, recovery methods, account contacts, and registrar lock are secured.
7. Any promised content, code, media, accounts, or documents were delivered and rights are documented.
8. No unexpected financing, lease, dispute, marketplace, or registrar restriction appears.

Take dated screenshots or exports inside the buyer-controlled account. A changed public WHOIS/RDAP display alone is not sufficient acceptance evidence.

Seller Checklist

1. Confirm the exact transaction and cleared funding state inside the provider dashboard.
2. Verify the receiving account or gaining registrar information through the agreed channel.
3. Do not disclose AuthInfo codes or transfer control before the funding condition is met.
4. Record the push, authorization, transfer messages, status, and buyer acceptance.
5. After completion, remove the domain from DNS services, certificates, email, hosting, monitoring, auto-renewal, and connected accounts.
6. Retain payment, fee, accounting, tax, contract, and transfer evidence.

Common Escrow and Domain-Transaction Scams

• Fake escrow service: The counterparty controls a lookalike website and fabricated dashboard.
• Forged funding email: A message claims funds cleared, but the authenticated provider account shows nothing.
• Changed payment instructions: A compromised mailbox redirects funds to a new bank or wallet address.
• False seller control: Screenshots or public data are used without a fresh control challenge.
• Transfer-before-funding pressure: A supposed buyer requests an AuthInfo code or account push before verified funding.
• Required appraisal scam: A buyer insists the seller purchase a report or certificate from a specific site.
• Wrong-name substitution: Terms or checkout quietly identify a different spelling, extension, or account.
• Off-platform amendment: Important promises or payment changes are made in chat but never added to the transaction record.

Plan for Delays, Failure, and Disputes

Agree what happens when funds are delayed, a domain is locked, authorization fails, the buyer cannot receive the domain, the seller misses a deadline, an included asset is absent, or a third party asserts rights. Preserve all communications in the provider’s official channel and follow its dispute procedure.

Do not improvise a refund directly with the counterparty while escrow remains active. Confirm how the provider handles refunds, fees, chargebacks, crypto-price changes, currency conversion, and partial transactions before funding.

Large or Complex Transactions

For a portfolio, staged transfer, lease-to-own arrangement, installment sale, financed purchase, or deal containing a website and intellectual property, consider:

• A schedule listing every domain and asset
• Per-asset or milestone-based release conditions
• A test transfer before the main batch
• Representations about control, disputes, liens, contracts, and authority to sell
• Transition services, credentials, data handling, employee/vendor access, and deletion obligations
• Independent legal, tax, security, and accounting review

Post-Closing Security

• Change account password and recovery methods; enable strong multi-factor authentication.
• Apply registrar lock and any registry-level protection appropriate to the value.
• Review registrant data, expiry, renewal funding, nameservers, DNSSEC, and delegated access.
• Rotate DNS, hosting, CMS, CDN, analytics, email, and API credentials included in the deal.
• Review active certificates, subdomains, mail records, forwarding rules, and external integrations.
• Store the purchase agreement, escrow record, invoice, transfer evidence, and renewal owner.

Use the domain-registration security checklist immediately after acceptance.

Minimum Transaction Record

• Signed agreement, exact asset schedule, amendments, and authorized representatives
• Independent provider-verification evidence and applicable terms
• Seller-control challenge and due-diligence record
• Escrow transaction ID, funding evidence, fees, dates, and official messages
• Registrar status, transfer route, AuthInfo handling, and transfer evidence
• Buyer acceptance checklist and delivered-asset inventory
• Release, invoice, accounting, tax, dispute, and post-closing security records

Primary Sources

• US Federal Trade Commission: Online escrow scams
• ICANN: Transfer Policy
• ICANN: FAQs for registrants transferring a domain
• ICANN: Locked domain status