A Secure Domain Transfer Playbook for Buyers and Sellers

A domain transfer is often described as an administrative handoff: obtain a code, unlock the name, approve a few emails, and wait. That description is technically familiar and operationally dangerous. A domain is a control point for a website, email addresses, password resets, certificates, advertising links, and sometimes a company’s public identity. A mistake during the handoff can expose an account, interrupt mail, or make it difficult to prove who authorized what.

The safest transfer is not the fastest possible transfer. It is a staged change of control with independent identity checks, a written record, a protected payment path, and a rollback-aware plan for DNS and email. This playbook is for founders, operators, domain buyers, and domain investors who want a repeatable process without pretending that every registrar or top-level domain follows the same rules.

Rules vary by registrar, registry, domain extension, account type, privacy service, and the age of a recent registration or transfer. Treat the registrar’s current instructions as the controlling procedure. Where the stakes are high, involve counsel or a qualified domain specialist; this guide is operational guidance, not a substitute for legal advice.

Before anyone sends money or requests an authorization code, create one shared transfer brief. It should identify the asset, the people authorized to act, the sequence of events, and the conditions that stop the process. A simple document prevents the common failure mode in which buyer, seller, broker, escrow provider, and two registrar support teams each hold a different version of the plan.

Record at least:

• The exact domain name, including its extension and correct spelling.
• The current registrant, account holder, and beneficial owner, if they are different.
• The current registrar, target registrar, and any broker or escrow provider.
• The agreed price and currency, payment milestones, fees, and who pays them.
• The intended transfer method: inter-registrar transfer, account push, or another registrar-supported change of ownership.
• The names and contact details of authorized representatives on both sides.
• The target date and a communications channel that is not dependent on the domain being transferred.
• The production website, DNS provider, email provider, certificate manager, and critical third-party services tied to the domain.
• A stop list: suspicious payment instructions, unexpected account changes, mismatched identity, or an unplanned change to DNS.

Use a neutral, dated file and preserve revisions. A transfer worksheet can live alongside the asset record in pdomain or another system with access logging. Do not place passwords, full payment-card data, or a reusable authorization code in the worksheet.

Identity verification should be proportionate to the value and risk of the transaction. A marketplace profile, a social-media account, or a reply from a familiar email address is not, by itself, proof of authority. The goal is to establish that each person is real enough to be accountable and authorized enough to bind the relevant owner.

For the seller, verify:

1. Ownership. Compare registrar records, renewal invoices, account history, corporate records, or other credible evidence. Privacy or proxy registration can obscure public data, so ask how the seller obtained the right to transfer the name.
2. Authority. If the domain belongs to a company, confirm that the representative can sell or transfer it. A founder’s personal control of a company domain may not settle the company’s ownership question.
3. Control of the account. The seller should be able to access the registrar account and its recovery methods without sharing credentials. If a manager, former employee, or agency controls the account, resolve that before closing.
4. No hidden blockers. Check whether the name is subject to a registry lock, dispute, court order, financing arrangement, recent transfer restriction, or an internal registrar hold.

For the buyer, verify:

• The legal name or entity that will own the domain after the transfer.
• The buyer’s authority to make the purchase and receive the asset.
• The destination registrar’s account and recovery contacts.
• The buyer’s ability to operate DNS and email securely once control changes.
• Whether the intended registrant information is accurate and can be maintained.

Both parties should independently validate the other party’s communication details through a known channel. If a broker introduced the deal, call the broker using a number obtained from the established marketplace or engagement letter, not only a number in a newly received message. Be especially cautious when banking instructions change late in the transaction. A convincing email thread can still be a compromised mailbox.

Capture evidence without over-collecting sensitive data. A redacted company record or a confirmation that a verification call occurred is often better than circulating identity documents through ordinary email. If documents are necessary, use a reputable secure portal, restrict access, define retention, and delete copies when the transaction’s requirements are satisfied.

“Transfer” can mean several different actions. An inter-registrar transfer moves the registration from one registrar to another and usually uses an authorization code. An account push moves a domain between accounts at the same registrar and may be faster. A change of registrant updates ownership data and, depending on the extension and registrar, may trigger a separate confirmation process or a temporary transfer lock.

Ask three questions before choosing:

• Does the buyer need a new registrar, or only a new owner and account?
• Will the chosen action change the registrant name, organization, or contact email?
• What lock, approval, and waiting-period rules will the registry and registrars apply afterward?

Write the chosen method into the transfer brief and confirm it with both registrars. Do not infer that an action is complete because a dashboard shows “pending.” The authoritative state may be visible only in a registry lookup, registrar notice, or support response.

Preparation is where most avoidable disruption can be removed. The seller should not improvise account changes while a transfer is in flight, and the buyer should not wait until the domain arrives to discover that the destination account has a weak recovery path.

Seller preparation checklist

• Confirm the domain is at the expected registrar and not already in another pending transfer.
• Review the registrar’s current transfer policy, including eligibility, locks, approval messages, and cancellation windows.
• Enable strong multi-factor authentication, preferably with a hardware security key or authenticator rather than SMS alone.
• Review administrator users, delegates, API tokens, recovery email addresses, and recent login activity.
• Remove former employees, old agencies, and unnecessary integrations, but preserve evidence before deleting access.
• Export or record DNS records, nameservers, DNSSEC status, registrar settings, renewal date, and auto-renewal choice.
• Confirm the registrant and administrative contact data are accurate enough to receive required notices.
• Separate the transfer task from unrelated account changes.

Buyer preparation checklist

• Create the destination registrar account using a company-controlled mailbox and a unique password.
• Set up multi-factor authentication and at least two documented recovery methods.
• Establish role-based access: owner, operator, billing, and read-only roles where available.
• Confirm the account can manage nameservers, DNSSEC, transfer locks, contact data, and renewal settings.
• Decide who will monitor transfer notices and who can approve a DNS change.
• Prepare an inventory record with the domain’s intended owner, business purpose, renewal budget, and dependencies.
• Test the buyer’s DNS and email administration separately, without changing production yet.

Never ask a seller to email a registrar password or give the buyer a shared login “just for the transfer.” A shared credential erases accountability and can survive long after the transaction. Use account transfer features, delegated access, or a registrar-supported handoff instead.

The authorization code—often called an EPP code, transfer code, or auth-info code—is a permission artifact. It is not proof of ownership, and possession of it should not be treated as a harmless formality. Anyone who obtains a valid code may be able to initiate a transfer, subject to registrar and registry checks.

The seller should request the code only when the parties are ready and should obtain it through the registrar’s authenticated dashboard or a verified support process. Do not accept a code copied from an unknown message, and do not send it in a group thread that includes people who do not need it. Use an encrypted, access-controlled channel agreed in advance. Treat the code as single-purpose and time-sensitive even if the registrar does not state an expiration date.

The buyer should enter the code directly at the destination registrar, never into a form reached through an unsolicited link. Verify the browser address, account, domain spelling, and destination registrar before submitting. If the code fails, stop and diagnose the reason—expired code, typo, wrong extension, registry restriction, or an already pending transfer—rather than repeatedly requesting codes and changing multiple settings.

After initiating the transfer, monitor the authenticated registrar dashboards and independent notices. The parties should agree which messages are expected and which require a call. A request to cancel a transfer, change a payout account, or provide a second code is a high-risk event until independently verified.

Once the transfer completes, consider the old code compromised. The buyer should confirm whether the code is invalidated and, if the registrar allows it, rotate any related credentials or tokens. The seller should remove the domain from saved password managers, automation, templates, and support tickets where continued access is no longer appropriate.

Escrow is a transaction control, not a guarantee that a domain is free of every legal or technical risk. A reputable provider can hold funds, define inspection or acceptance steps, and release money when documented conditions are met. It cannot replace identity checks, title review, or an operational continuity plan.

Before sending funds, verify the escrow provider through its official website and established account. Read the release conditions, dispute process, refund rules, fees, supported currencies, and treatment of failed transfers. Confirm the exact domain and buyer and seller identities in the transaction record. Beware of a last-minute request to use a different provider or to pay a person directly because “the escrow link is broken.”

Define objective milestones. For example:

1. The escrow transaction is opened with the exact domain and parties.
2. The buyer funds the transaction through the provider’s approved method.
3. The seller provides the agreed transfer inputs and removes the applicable lock.
4. The buyer initiates the transfer to the named account or completes the agreed account push.
5. The buyer verifies control in the destination registrar, confirms critical DNS and email dependencies, and records any exceptions.
6. The buyer accepts or raises a documented dispute before funds are released.

Do not make “the buyer can log in” the only acceptance test. A login may work while nameservers, DNSSEC, renewal, or recovery contacts remain wrong. Conversely, do not alter production DNS as a condition of proving control unless the transaction specifically requires it. Control of the registration and continuity of the service should be tested independently.

For a business acquisition, escrow may cover only the domain. State separately how hosting, source code, mailboxes, customer data, trademarks, certificates, and third-party subscriptions will be transferred. Avoid assuming that buying a domain transfers rights in a name or brand.

The domain registration and the DNS zone are related but separate layers. A registrar transfer may leave nameservers unchanged, or a registrar’s workflow may make it easy to replace them accidentally. If nameservers change without a complete zone, the website can disappear, mail can bounce, and validation records for other services can fail.

Before the handoff, export a readable copy of the current zone and record its source and date. Include A and AAAA records, CNAMEs, MX, TXT records, verification tokens, SPF, DKIM selectors, DMARC policy, CAA records, redirects, and any special records used by APIs or certificate issuance. Record TTL values and the current DNSSEC state. A zone export is a reference, not automatically a safe import: remove obsolete records and verify provider-specific syntax.

Map the dependencies. Ask which systems send mail, which receive it, where DKIM keys are managed, how DMARC reports are reviewed, and which vendors validate the domain. Document web hosting, CDN, VPN, transactional mail, support desk, identity provider, payment pages, and monitoring endpoints. A founder’s personal inbox or an agency’s account may be an undocumented dependency worth resolving before closing.

A practical continuity sequence is:

• Freeze nonessential DNS edits during the transfer window.
• Confirm nameservers and the authoritative DNS provider before initiating the registrar action.
• Take a final zone snapshot and verify it against the live response from more than one resolver.
• Keep the existing DNS provider active until the buyer has confirmed the registration and the services.
• After completion, inspect nameservers, DNSSEC delegation, MX, SPF, DKIM, DMARC, web endpoints, and certificate coverage.
• Send controlled test messages in both directions and check headers, delivery, and authentication results.
• Watch uptime, mail queues, DMARC reports, and service alerts for at least one normal business cycle.

Do not lower TTLs at the last minute and assume every resolver will update immediately. TTL changes affect future caching and do not create a universal flush. If a nameserver change is necessary, plan it separately with enough overlap and a tested replacement zone.

Transfer locks exist to slow unauthorized movement, but a lock is useful only when the authorized operator understands what it covers. Common controls include a registrar lock, a registry status such as clientTransferProhibited, a lock after recent registration or transfer, and a temporary restriction after certain contact changes. The exact names and exceptions differ.

The seller should remove only the lock required for the agreed action, and only after payment and identity conditions are satisfied. Record the time and the previous state. Do not disable account multi-factor authentication, privacy protections, DNSSEC, or unrelated security controls merely because a support representative suggests a broad reset. Ask what specific status is blocking the transfer and whether there is a narrower remedy.

The buyer should initiate the transfer promptly once the code and conditions are ready. Transfers can require approval by email, automatic approval, or a waiting period. Confirm that approval messages go to an address controlled by the proper party. If the seller receives an unexpected approval request, they should not click through reflexively; they should compare it with the documented plan and verify through the registrar dashboard.

Keep a timeline:

• lock removed;
• code issued and delivered;
• transfer initiated;
• approval sent and accepted;
• status changed at the old registrar;
• status visible at the new registrar;
• acceptance recorded in escrow;
• post-transfer locks and security controls restored.

The timeline matters if support must investigate a failed or unauthorized action. It also reveals when assumptions diverged. A status that says “pending transfer” is not the same as “transfer completed,” and a confirmation email is not a substitute for checking the destination account.

Completion is a verification exercise, not a celebratory click. The buyer should confirm the domain appears in the correct destination account, shows the expected registrant and renewal information, and can be managed without seller credentials. The seller should confirm that access has ended and that no continuing delegate, API token, or recovery method remains attached.

Run a post-transfer review in this order:

Registration and account

• Confirm the exact domain and extension.
• Verify owner, organization, contact email, renewal date, auto-renewal, and billing settings.
• Review transfer status and apply the registrar lock or equivalent protection when policy permits.
• Confirm multi-factor authentication, recovery codes, trusted devices, users, delegates, and API tokens.
• Save an authenticated screenshot or registrar receipt where appropriate, with sensitive information redacted.

DNS and service health

• Compare nameservers and DNSSEC status with the approved plan.
• Resolve the web and mail records from independent networks.
• Check certificate names and expiration dates.
• Test website routes, redirects, login flows, transactional mail, inbound mail, and critical vendor callbacks.
• Confirm SPF, DKIM, and DMARC behavior without weakening an existing policy merely to silence a test.

Access and documentation

• Rotate temporary credentials, codes, shared secrets, and emergency links used during the deal.
• Remove the seller, broker, former staff, and old agency from every relevant system.
• Update the domain inventory, ownership record, renewal owner, escalation contacts, and disaster-recovery notes.
• Store the final agreement, escrow receipt, transfer timeline, zone snapshot, and support case numbers in a restricted repository.
• Set a reminder for renewal and for a later access review; do not rely on one person’s calendar.

Consider enabling registry-level protection or a premium lock for a high-impact domain if the registrar offers it and the organization can operate the associated approval process. A stronger lock can add friction during a legitimate emergency, so document who can authorize its removal and how that decision is verified.

A mature operator turns this process into a small runbook rather than relying on memory. Keep the runbook generic and store transaction-specific secrets outside it. At minimum, assign an owner for each stage: identity, commercial terms, registrar operations, DNS and email, security, and acceptance.

Before funding

• [ ] Domain spelling, extension, ownership, and authority verified.
• [ ] Transfer method and registrar eligibility confirmed.
• [ ] Independent communications channel tested.
• [ ] Destination account and MFA prepared.
• [ ] Escrow terms and release tests accepted.
• [ ] DNS, email, certificate, and third-party dependency inventory captured.

At initiation

• [ ] Payment is visible in the verified escrow transaction.
• [ ] Required lock is removed by the authorized seller.
• [ ] Authorization code is obtained through a trusted registrar path.
• [ ] Buyer enters the code in the verified destination account.
• [ ] Expected approvals are confirmed; unexpected instructions are paused.

At completion

• [ ] Destination account shows control and correct registration data.
• [ ] Nameservers, DNSSEC, website, certificates, and mail are healthy.
• [ ] Escrow acceptance is documented against objective criteria.
• [ ] Old account access, delegates, tokens, and recovery paths are removed.
• [ ] New locks, MFA, renewal ownership, monitoring, and records are in place.

If something goes wrong, preserve evidence before changing settings: timestamps, notices, status codes, DNS responses, support case numbers, and the exact account actions taken. Then contact the registrar and escrow provider through official channels. Avoid repeated lock toggles, mass DNS edits, or urgent payment changes while facts are still unclear.

A secure domain transfer is a controlled change of authority across several systems, not a single code exchange. Buyers protect themselves by verifying ownership, preparing a hardened destination, using objective escrow milestones, and testing real service dependencies. Sellers protect themselves by confirming authority, limiting disclosure, removing only necessary locks, and documenting the moment control changes.

The details will vary by registrar and extension, and some cases will require specialist or legal help. The consistent principle is simpler: separate identity, payment, transfer control, and production continuity into explicit steps, with a person responsible for each one.

Practical takeaway: before the next transfer, create one dated brief containing the domain, verified parties, chosen handoff, escrow milestones, authorization-code channel, DNS and email checklist, lock timeline, and post-transfer acceptance tests. If a step cannot be written clearly, it is not ready to execute.