BUY WEBSITES
BUY DOMAINS
LOGIN
SIGNUP
Paperwork for a Private Domain Transfer: The Agreement, the Auth Code, and the Safe Order of Operations in 2026
A private domain transfer, the kind where you buy a name directly from its current owner instead of through a registrar checkout, runs on two separate stacks of paperwork. One binds the buyer and the seller to each other. The other moves the domain through the registrar and registry systems. The typical guide explains one and ignores the other, which is exactly how deals go sideways.
The honest position is this. A direct, off-registrar sale is legitimate and routine, and people complete them every day. The risk is not the sale. The risk is doing it on a handshake, with no signed agreement, no escrow, and no record of who initiated the ownership change. Done with the right documents in the right order, a private transfer is safe. Done on trust alone, it is where a buyer pays and never gets the name, or a seller hands over a domain and eats a chargeback.
This guide walks both stacks: the transfer agreement clause by clause, the registrar paperwork the ICANN system genuinely requires, and the one safe order of operations that ties them together. When you would prefer to skip assembling the documents yourself, SEO Domains operates the curated marketplace where the agreement, escrow, and ICANN-accredited transfer come bundled into a single flow.
What “paperwork” actually means in a private domain transfer
In a private domain transfer, paperwork splits into two separate stacks. The first is the legal agreement that binds the buyer and the seller, recording the price, the asset, and the promises each side makes. The second is the registrar and registry paperwork, the auth code and registrant-change steps, that moves the domain between accounts. The agreement protects you against the other party; the registrar paperwork moves the name.
People search for “domain transfer paperwork” and land on two completely different kinds of page. One set shows contract templates and assignment agreements. The other set shows registrar how-to articles about auth codes and locks. Both are correct, and both are half the answer, because a safe private transfer needs both at once.
Stack one: the agreement between two people
The first stack is the deal itself, written down. When you buy a domain directly from its owner instead of from a registrar storefront, no platform stands between you. The transfer agreement, sometimes called a domain assignment agreement or a domain purchase agreement, is the only document that records what was sold, for how much, and what each party promised. It is your evidence if the seller later claims the name was never sold.
Stack two: the registrar paperwork that moves the name
The second stack is operational. A domain lives inside a registrar account, governed by ICANN policy. Changing who controls it means generating an authorization code, completing a change-of-registrant confirmation where the registrar asks for one, and either pushing the domain to the buyer inside the same registrar or transferring it to the buyer’s registrar. The registrar does not read your contract. It follows its own verification steps that move the name between accounts.
Stack 1: the transfer agreement
A signed contract between buyer and seller. Records the parties, the exact domain, the price, the assignment of rights, and the promises (warranties) each side makes. Protects you against the counterparty. It does not move the domain.
Stack 2: the registrar paperwork
The auth code, the change-of-registrant confirmation, and the push or inter-registrar transfer. Governed by ICANN policy and run by the registrar, which verifies the registered owner, not your sale contract. This is the step that moves the name.
Hold this two-stack distinction in mind for the rest of the guide. The leading reason a private domain purchase goes wrong is treating one stack as if it covered the other: signing a contract and assuming the domain is now yours, or pushing a domain on trust with no contract to fall back on.
The transfer agreement, clause by clause
A domain transfer agreement records the parties, identifies the exact domain, states the consideration, and assigns the seller’s right, title, and interest to the buyer. It then carries the protective clauses that separate a real contract from an email thread: representations and warranties of clean ownership, an indemnification clause, a further-assurances promise, and a governing-law clause. Free competitor pages skip these clauses; lawyer-grade templates put them behind a paywall.
The search results for “domain transfer agreement” are split between two extremes. On one end sit law-firm products like the Thomson Reuters Practical Law pro-seller template, accurate but paywalled and written for lawyers. On the other end sit free template libraries that name no clauses at all. This section gives you the clause architecture in plain English, drawn from the structure visible in real executed assignments filed with the SEC and in registrar agreements such as the one published by no-IP.
The core clauses every domain transfer agreement needs
- Parties. The full legal names and addresses of the seller (the transferor or assignor) and the buyer (the transferee or assignee). For a company, the registered entity, not a brand name.
- The domain identified exactly. The domain name written out in full, lowercase, with its extension. A typo here is a contract about a name nobody owns.
- Consideration. The price and what it buys. State the currency, the amount, and whether the figure covers the domain only or also website content, trademarks, social accounts, or email.
- Assignment of right, title, and interest. The operative clause. The seller assigns and transfers to the buyer all right, title, and interest in the domain. This is the line that legally moves ownership of the asset, distinct from the registrar step that moves the registration.
- Representations and warranties. The seller’s promises: that they own the domain free and clear, that it carries no liens or encumbrances, that they have the authority to sell, and that the name does not knowingly infringe a third party’s trademark.
- Indemnification. Who covers the cost if a promise turns out false. A buyer-protective indemnity has the seller cover losses from a broken warranty, such as a later trademark claim on the name.
- Further assurances. A promise that the seller will sign whatever additional documents and complete whatever registrar steps are needed to finish the transfer. This clause is what compels the seller to actually release the auth code after signing.
- Payment mechanism and escrow. How and when money moves, and whether a third-party escrow service holds funds until the domain lands. For any meaningful sum, this clause should name escrow.
- Governing law and signatures. The jurisdiction whose law applies, the effective date, and a signature block for both parties. An electronic signature is generally sufficient.
| Clause | What it does | Why it protects you |
|---|---|---|
| Parties | Names the legal buyer and seller | An agreement with the wrong entity is unenforceable |
| Domain identified | States the exact name and extension | Removes any ambiguity about what was sold |
| Consideration | Sets the price and what it covers | Prevents later disputes over content, trademarks, or extras |
| Assignment of right, title, interest | Legally transfers ownership of the asset | This, not the registrar push alone, is what makes you the owner |
| Representations and warranties | Seller promises clean, unencumbered ownership | Gives you a claim if the name turns out stolen or contested |
| Indemnification | Allocates the cost of a broken promise | Shifts the bill for a later trademark or ownership claim to the seller |
| Further assurances | Seller agrees to complete the registrar steps | Compels release of the auth code and the actual transfer |
| Escrow and payment | Defines how and when funds move | Ties the seller’s payment to the domain landing in your account |
| Governing law and signatures | Sets jurisdiction and binds both parties | Tells you which court hears a dispute and makes the deal binding |
Why a written agreement matters: the handshake-sale risks
Without a written agreement, a private domain transfer rests entirely on trust, and three failure modes follow: a seller who claims the name was never sold, a payment that gets reversed after the domain moves, and a name that turns out stolen or trademark-contested with no recourse. A registrar will not rescue you here, because registrars verify the registered owner and do not honor third-party purchase agreements.
The temptation in a friendly deal is to skip the contract. The buyer trusts the seller, the price feels small, and writing an agreement feels like overkill. The cases below are why practitioners write one anyway.
There is a hard limit worth stating plainly. The registrar is not your backstop. Network Solutions states the rule that the whole industry follows: “We do not accept third-party purchase agreements.” Your contract binds the seller to you. It does not instruct the registrar, which verifies the registered name holder through its own forms and confirmations. That separation is the entire reason both paperwork stacks exist.
The registrar paperwork: change of registrant versus registrar transfer
The registrar side has two distinct moves that buyers confuse. A change of registrant alters who owns the domain in the registration record. An inter-registrar transfer moves the domain from one registrar to another using an authorization code. A private sale usually needs the first and frequently the second. Both run on registrar verification, not on your sale contract, and both are governed by ICANN’s Transfer Policy.
Network Solutions draws the cleanest version of this distinction. A change of ownership, also called a change of registrant, transfers ownership from one account holder to another and updates the registration record. A registrar transfer moves the domain between registrars and leaves ownership the same. A private purchase frequently involves both: the seller hands you ownership, and you then move the name to your own registrar.
What a change of registrant can require
Depending on the registrar and the situation, a change of registrant can ask for documentation beyond a click. For a straightforward sale the registrar typically sends confirmation emails to the old and new registrant. For higher-friction cases, registrars such as Network Solutions can require a transfer-of-registrant form, a notarized letter naming the current registrar with a handwritten signature, and a valid government-issued photo ID, with a stated review window of two to three business days.
The authorization code, the lock, and the push alternative
Moving a domain between registrars needs an authorization code. ICANN defines it directly: an Auth-Code, also called an Authorization Code, AuthInfo Code, or transfer code, is a code your registrar creates to identify the domain holder and prevent unauthorized transfers, and it is required to move a name from one registrar to another. When the buyer and seller share the same registrar, an account-to-account push can skip the inter-registrar transfer entirely, which is faster and sidesteps the transfer lock.
The registration record itself is worth a note. The public ownership lookup historically ran on WHOIS; since RDAP, the Registration Data Access Protocol, became the standard ICANN lookup on 28 January 2025, the same registrant-of-record data is returned in a structured form. You use that lookup to confirm the seller is the actual registered holder before money moves. The mechanics of the code are covered in EPP code (auth code) explained, and the choice between moving registrars and pushing in place is set out in Buying a domain through a broker.
This sourcing-and-verification step is the point where a curated marketplace removes the guesswork. Instead of chasing an auth code from an unfamiliar seller and verifying the record yourself, the SEO Domains marketplace lists names whose ownership is already established, with the transfer handled through ICANN-accredited rails. For a peer-to-peer deal you assemble the verification yourself; for a marketplace purchase it is built in.
The safe order of operations, step by step
The single thing that matters about private-transfer paperwork above all else is the order. Sign the agreement before money or codes move. Open escrow before the domain moves. Verify the seller owns the name of record before funding escrow. Release funds only after the domain lands in your account. Run those steps out of order and you create exactly the gap a bad actor needs.
The sequence below is the order practitioners use to keep both stacks aligned. Each step pairs the right move with the mistake that opens a door.
-
Agree the terms and sign the transfer agreement
Put the price, the exact domain, the assignment of rights, the warranties, and the escrow provider in writing, and both parties sign and date it before anything else moves. Read the clause set in the agreement section above and align it with the Negotiation tactics for private sales you settled on.
The mistake: starting the registrar steps on a verbal deal. With no signed assignment, you have nothing to enforce if the other side reverses course.
-
Verify the seller is the registrant of record
Run an RDAP or WHOIS lookup and confirm the seller is the registered name holder, or can prove authority to act for the registered entity. Cross-check the name, organization, and email against who you are negotiating with. The valuation work in Valuation for a private domain purchase means little if the seller cannot deliver the name.
The mistake: paying a seller who is not the registrant. A name sold by someone who does not control it is the classic hijacked-domain trap.
-
Open escrow and fund it
Use a recognized escrow service so funds are held, not handed over. The buyer funds escrow; the service confirms it holds the money. The escrow flow is detailed in Why use escrow for domain transactions and walked through in Escrow.com walkthrough.
The mistake: paying the seller directly by a reversible method. That exposes the seller to a chargeback and the buyer to a vanished payment with no name.
-
Seller initiates the transfer: push or auth code
If you share a registrar, the seller pushes the domain into your account. If not, the seller unlocks the domain, disables privacy if needed, and provides the auth code so you can start the inter-registrar transfer at your registrar. The further-assurances clause in the agreement is what obliges the seller to do this.
The mistake: a seller who goes quiet after escrow is funded. Without a further-assurances clause, you have weaker leverage to compel the registrar steps.
-
Complete the registrant-change confirmations
Respond to the confirmation emails the registrar sends to the old and new registrant within the window it sets. For higher-friction registrars, supply the transfer-of-registrant form, notarized letter, or photo ID it requests. This is the step that updates the ownership record to your name.
The mistake: ignoring a confirmation email. ICANN policy lets the registrar cancel the change if the confirmation is not returned in time.
-
Confirm the domain is in your account, then release funds
Verify the domain appears in your registrar account and the registrant record shows you. Only then authorize escrow to release the funds to the seller. Finish with the Post-transfer checklist for aged domains to lock the name, set privacy, and confirm renewal.
The mistake: releasing escrow on the seller’s word before the name lands. Funds released early defeat the entire purpose of using escrow.
The ICANN rules that shape your timeline
Three ICANN rules govern how fast a private transfer can complete. Your registrar must provide the auth code within five calendar days. A change of registrant can trigger a 60-day lock against an inter-registrar transfer. A domain cannot be transferred to a new registrar within 60 days of its initial registration or of a previous transfer. Knowing these in advance keeps the deal sequence realistic.
These are not registrar quirks. They are ICANN policy, stated in ICANN’s own registrant FAQ, and every accredited registrar follows them. They decide whether your transfer takes days or weeks.
The five-day auth-code rule
ICANN is explicit: your registrar must provide the AuthInfo code within five calendar days of your request. A large share of registrars expose a self-service button that returns it instantly; others require a support ticket. Build the slower case into your timeline so a quiet registrar does not look like a stalling seller.
The 60-day change-of-registrant lock
ICANN policy allows a domain to be locked against an inter-registrar transfer for 60 days after a change to the registrant name, organization, or email. If the seller changes the registrant details to your information first and then you try to move registrars, the lock can stop you. The cleaner path is to complete the registrar transfer first and change registrant details after, or to use a same-registrar push. The detail is laid out in ICANN’s 60-day transfer rule.
The 60-day rules on registration and prior transfers
A registrar can deny a transfer to a new registrar if the domain is within 60 days of its initial registration or within 60 days of a previous inter-registrar transfer. A recently registered or recently moved name cannot change registrars yet. ICANN also lists the circumstances where a registrar can deny a transfer, including evidence of fraud, a dispute over who authorized it, payment owed, a written objection from the holder, or a lock status, and where it must deny one, including an active UDRP proceeding or a court order.
| ICANN rule | What it means for your deal | Source |
|---|---|---|
| Auth code within 5 calendar days | Allow up to five days to receive the code if the registrar has no instant button | ICANN registrant FAQ |
| 60-day change-of-registrant lock | Changing owner details can block a registrar transfer for 60 days | ICANN Transfer Policy |
| 60 days from initial registration | A newly registered name cannot move registrars yet | ICANN registrant FAQ |
| 60 days from previous transfer | A recently moved name cannot move again yet | ICANN registrant FAQ |
| Form of Authorization change, 25 May 2018 | A gaining registrar that cannot access registration data is not required to obtain the authorization form | ICANN registrant FAQ |
| Mandatory denial: UDRP or court order | A disputed or court-ordered name will not transfer at all | ICANN registrant FAQ |
ccTLDs and special cases: deceased owners, company mergers, country domains
The standard process assumes a living individual selling a generic top-level domain such as a .com. Country-code domains, a deceased registrant, and a company sale each change the paperwork. Country domains run on registry-specific forms, an estate transfer needs a death certificate and proof of authority, and a corporate sale needs evidence of the merger or name change. Plan for these before you negotiate, not after.
The bulk of private transfers are clean. The ones that stall almost always hit one of the cases below, where the generic auth-code path does not apply.
| Case | What changes | Extra paperwork |
|---|---|---|
| Country-code domains (.uk, .de, .au) | Some ccTLDs change ownership through a registry process, not a generic auth-code transfer | Registry-specific transfer or change-of-registrant form; eligibility checks for restricted extensions |
| Deceased registrant | The registered holder cannot authorize the transfer | Death certificate plus power of attorney, executor, or administrator documentation proving authority |
| Company sale or merger | The registrant entity changes name or owner | Legal documentation of the merger, acquisition, or name change validated by the relevant agency |
| Privacy-protected registrant | The public record hides the real owner behind a proxy | Disable privacy or have the seller confirm identity through the registrar before transfer |
For a country-code extension, confirm the registry’s exact process before you sign, because a portion of them run change of ownership entirely through their own portal and ignore the auth-code model. For an estate or corporate transfer, gather the supporting documents up front: a registrar reviewing a notarized letter and an ID, on the two-to-three-business-day window Network Solutions cites, will not wait on missing paperwork.
The consolidated paperwork checklist and common mistakes
Every document a private domain transfer can need fits on one list, paired with who provides it and the mistake that document prevents. The recurring lesson runs down the right column: a signed agreement plus escrow plus verified ownership of record, completed in the safe order, closes every gap a handshake leaves open.
Use the table below as the scannable reference. The left column is the document, the centre column is who supplies it, and the right column is the mistake it exists to prevent. Read top to bottom, it is the full paper trail of a transfer that holds up.
| Document or step | Who provides it | The mistake it prevents |
|---|---|---|
| Signed transfer agreement | Buyer and seller | A “I never sold it” reversal with no enforceable record |
| Representations and warranties clause | Drafted into the agreement | Buying a stolen or trademark-contested name with no recourse |
| Further-assurances clause | Drafted into the agreement | A seller who goes quiet before completing the registrar steps |
| RDAP or WHOIS ownership check | Buyer | Paying a seller who does not actually control the name |
| Escrow service | Buyer funds, service holds | A chargeback or a vanished payment with no domain delivered |
| Authorization (auth) code | Seller, from the losing registrar | An inter-registrar transfer that cannot start |
| Registrant-change confirmations | Old and new registrant, via registrar email | A cancelled change because a confirmation lapsed |
| Transfer-of-registrant form, notarized letter, photo ID | As required by the registrar | A stalled high-friction change of registrant |
| Death certificate or merger evidence | Estate or company, when applicable | An estate or corporate transfer the registrar will reject |
| Post-transfer lock and renewal check | Buyer | A newly acquired name left unlocked or about to expire |
One theme runs through the whole table. The paperwork is not bureaucracy for its own sake. Each item closes a specific way a private sale can fail, and the items only work when they run in sequence: the agreement before the money, the verification before escrow, the registrar move before the release. A document signed after the gap it was meant to close is no protection at all.
Private domain transfer paperwork: frequently asked questions
The five questions buyers and sellers raise when they search for the paperwork behind a private domain transfer, answered against ICANN policy and the two-stack framing this guide draws.
Q1Do I really need a written agreement for a small private domain sale?
Yes, and the amount is not the deciding factor. A written transfer agreement is your only evidence of what was sold, for how much, and on what promises. Without it, a later “I never sold it” claim or a payment reversal leaves you with an email thread against a denial. The agreement protects you against the other party; a registrar will not, because registrars verify the registered owner and do not honor third-party purchase agreements.
Q2What is an authorization code and where does the seller get it?
An auth code, also called an authorization code, AuthInfo code, or transfer code, is the string a registrar generates to identify the domain holder and authorize a move to a new registrar. The seller gets it from the losing registrar, typically through a self-service button. ICANN requires the registrar to provide it within five calendar days of the request. If buyer and seller share a registrar, an account push can replace the code entirely.
Q3Can the registrar reverse a private domain transfer after it completes?
A registrar can deny or reverse a transfer in the limited circumstances ICANN names, such as evidence of fraud, a dispute over who authorized it, a written objection from the holder, or a court order. It will not unwind a completed, properly authorized sale just because one party regrets it. That is why escrow and a signed agreement matter: they resolve the buyer-seller dispute, which the registrar will not adjudicate for you.
Q4Will my registrar accept the purchase agreement as proof of ownership?
No. Registrars verify the registered name holder through their own forms, confirmation emails, and identity checks, not through a contract between two private parties. Network Solutions states the industry rule directly: it does not accept third-party purchase agreements. The agreement governs your relationship with the seller; the registrar paperwork, the auth code and registrant-change confirmations, is what updates the ownership record.
Q5How is the paperwork different for a country-code domain like a .uk or .de?
Country-code domains frequently change ownership through a registry-specific process instead of the generic auth-code transfer, and certain extensions carry eligibility rules on who can hold them. Confirm the registry’s exact change-of-ownership procedure before you sign, because the steps, forms, and any eligibility checks vary by extension. The transfer agreement still applies; it is the registrar and registry mechanics that differ.
Skip the paperwork scramble: buy through a curated marketplace
Assembling private-transfer paperwork yourself means drafting the agreement, arranging escrow, verifying the registrant of record, and chasing the auth code from an unfamiliar seller. A curated marketplace bundles the agreement, escrow, and ICANN-accredited transfer into one flow, with the ownership of the aged or expired domain already established. SEO Domains operates that marketplace.
Everything in this guide is the work a peer-to-peer buyer does by hand. For a one-off purchase from a known counterparty, doing it yourself is reasonable, as long as you keep the two stacks aligned and run the safe order. The friction is real, though, and it scales with every deal.
What the marketplace removes from the paper trail
A marketplace transaction collapses the two stacks into a single, governed flow. The contract terms are standardized, the funds run through escrow by default, the seller’s ownership is established before the listing goes live, and the transfer moves over ICANN-accredited rails. You are not drafting a warranties clause or wondering whether the seller is the registrant of record, because the platform has already verified it.
Why the aged-domain context matters here
Private transfers cluster around aged and expired domains, the names that carry inherited authority and so command a direct sale instead of a registration fee. That is precisely the inventory where the paperwork carries the highest stakes, because the value is real and the counterparty is frequently a stranger. Sourcing an aged domain from a screened catalogue means the ownership record, the clean history, and the transfer rails are settled before you ever discuss price.
