Transfer a domain to another registrar safely

An inter-registrar transfer changes which registrar sponsors a registration. It does not inherently change the registrant, registry, authoritative nameservers, DNS host, zone records, website, email provider, or certificate service. Preserve those boundaries so the ownership change does not become an unplanned service migration.

This playbook is written for ordinary holder-authorized transfers. TLD rules, court or dispute restrictions, expiry state, and registrar procedures can differ. Confirm the specific policy that applies to the domain before acting.

Blast radius and owners

Control or service	Responsible owner
Transfer approval and registrant authority	Registered name holder
Unlock, AuthInfo, and losing-registrar response	Current registrar account owner
Transfer submission and completion	Gaining registrar account owner
Registry sponsorship and status	Registry through the registrars
Nameservers, zone, and DNSSEC child state	DNS owner
Parent nameservers and DS preservation	Registrar and DNSSEC owners
Web, email, certificates, and monitoring	Respective application owners
Window, evidence, communication, and escalation	Transfer owner and independent verifier

The ICANN Transfer Policy gives the registered name holder authority to approve or deny an eligible transfer and defines registrar requirements, AuthInfo, locks, timing, and permitted denial conditions [1]. It does not make a registrar transfer a DNS migration.

Prerequisites

• authorized, protected accounts at the current and gaining registrars;
• tested recovery for the registrant approval email or phone;
• confirmation that the gaining registrar supports the domain’s TLD;
• sufficient time before expiry, renewal, or another planned ownership change;
• known eligibility, lock, dispute, and pending-transfer state;
• an approved custodian for the private AuthInfo code;
• confirmation that DNS hosting remains active after sponsorship changes;
• a complete evidence archive and named incident contact; and
• separate plans for any later registrant, DNS-provider, or nameserver change.

Treat the AuthInfo code as a short-lived credential. Never place it in a ticket, repository, screenshot, chat transcript, or ClueDNS input.

Inventory and export

Capture before unlocking:

• exact domain, TLD, current registrar, registry, and gaining registrar;
• registry statuses, creation, expiry, and last-transfer dates;
• registered name holder and recovery-contact state without copying secrets;
• current nameservers, glue, parent DS, and child DNSKEY observations;
• complete DNS-zone export and all provider-specific settings;
• web, email, certificate, verification, and delegated-subzone dependencies;
• auto-renew, remaining term, billing, privacy, and registry-lock state;
• current registrar-lock value and documented transfer-eligibility result;
• approval channel and expected registrar notifications; and
• exact prior values and contacts needed for incident response.

Use the Domain Registration Lookup pathway for a timestamped RDAP or registration-data observation. RDAP can report available registrar, status, date, and nameserver data, but it does not prove account control or transfer eligibility. ICANN documents RDAP as the structured registration-data access path [2].

Preflight

1. Confirm the requested operation is an inter-registrar transfer, not a change of registrant or DNS provider.
2. Ask both registrars for the specific TLD procedure, fees, renewal effect, completion path, and cancellation or dispute process.
3. Confirm the registry status does not show an unexplained hold, dispute, or transfer restriction.
4. Confirm the registrant can receive and recognize every approval notice.
5. Verify the gaining registrar will retain the exact existing nameservers, glue, and DS state.
6. Query parent NS and DS, every authority, and named recursive resolvers through the DNS Lookup pathway.
7. Verify web, email, certificates, and monitoring before the transfer so pre-existing failures are not attributed to it.
8. Confirm the DNS provider account and zone remain active independently of the losing registrar.
9. Record the verifier, approved window, maximum pending duration, and incident contacts at both registrars.

If the losing registrar also supplies DNS, obtain written confirmation that the zone will continue after transfer. A registrar-branded DNS panel is not proof that hosting is independent.

Stop conditions

Stop before unlocking or submitting when:

• registrant authority or the approval channel is disputed;
• the domain is expired, in redemption, on hold, in a dispute, or unexpectedly locked;
• the domain may be inside a policy or provider transfer-lock period;
• the gaining registrar cannot preserve nameservers, glue, or DS;
• DNS hosting ends when the losing-registrar account closes;
• the zone export, current delegation, or DNSSEC state is incomplete;
• another registrant, nameserver, DNSSEC, web, or email change is scheduled;
• the AuthInfo code cannot be handled privately;
• renewal outcome or remaining term is unclear; or
• no owner can handle an unauthorized-transfer incident.

During the transfer, stop unrelated changes after any unexplained registry, delegation, DNSSEC, web, or email observation.

Ordered steps

1. Approve the evidence record, scope, owners, window, and escalation contacts.
2. Complete any required renewal or contact correction early enough that it does not create a new lock or collide with the transfer.
3. Obtain a fresh AuthInfo code through the current registrar and store it only in the approved secret channel.
4. Remove only the transfer-prohibited lock needed for the approved request. Do not remove registry-lock protections without a separately reviewed plan.
5. Initiate the request at the gaining registrar and enter the exact domain and AuthInfo code.
6. Review every authorization notice from a known registrar channel. Confirm the domain, gaining registrar, and request time before approving.
7. Leave nameservers, zone data, DS, web, email, and registrant identity unchanged while the transfer is pending.
8. Monitor registrar and registry state without repeatedly restarting the request.
9. When completion is confirmed, secure the gaining account, verify recovery contacts and auto-renew, and re-enable the appropriate transfer lock.
10. Rotate or invalidate the exposed AuthInfo code where the registrar supports it, then archive non-secret completion evidence.

Do not promise a universal completion time. The current ICANN policy describes the gTLD transfer process and specific timing, but the applicable TLD and registrar workflow still control the observed transaction [1].

Verification

Verify and timestamp:

1. the intended registrar is now recorded and the transfer is no longer pending;
2. registrant and recovery data remain under the intended control;
3. renewal, expiry, privacy, and transfer-lock settings are correct;
4. parent nameservers and glue are unchanged;
5. every authoritative server still serves the approved zone;
6. parent DS and child DNSKEY still form the intended secure or insecure state;
7. named recursive resolvers return explainable answers;
8. website, TLS, redirects, email, and delegated subzones still work; and
9. the losing registrar no longer holds an active request or unexpected service dependency.

DNSSEC authenticates DNS data; it does not protect registrar account access or authorize a transfer [3].

Rollback

Registrar transfer rollback is not equivalent to restoring a DNS RRset.

• If the request is still pending, use the documented registrar process to cancel or deny it, then restore the transfer lock and rotate AuthInfo.
• If the request was unauthorized but completed, contact both registrars immediately through their transfer-incident process. Preserve notices, timestamps, account alerts, and registration observations.
• Do not change nameservers or DS merely to make registration data resemble the old state. Preserve working services while the sponsorship issue is handled.
• If DNS hosting unexpectedly ends, restore service through the captured zone and a separately approved DNS recovery plan; do not improvise inside the transfer dispute.
• Verify registration, delegation, DNSSEC, web, and email after any recovery action.

Next step

Keep the registrar and DNS provider unchanged until the transfer is stable. If the actual goal is to move authoritative service, schedule Switch authoritative DNS providers safely as a separate change.