Prepare a domain transfer by validating contacts, status codes, authorization, DNS independence, and renewal timing.
What matters first
- A registrar transfer changes sponsorship, not necessarily DNS or hosting.
- Eligibility depends on current status, policy, contact and timing.
- The authorization code is sensitive account material.
- Record configuration before the transfer so unintended changes are detectable.
Separate the moving parts
Registrar, registry, DNS operator, web host, and mail provider can be different organizations. Capture this map before a transfer so an unrelated DNS change is not introduced accidentally.
Confirm the current sponsoring party using the registrar verification workflow before requesting an authorization code.
Pre-transfer checks
Verify account recovery, registrant contact reachability, transfer eligibility, domain status, authorization-code handling, renewal date, and any recent registration or transfer restrictions. Save current delegation and DNS records.
Use the transfer-status interpretation guide to distinguish transfer locks from lifecycle or server-side restrictions before changing a status.
Acceptance criteria
The receiving account shows the domain, the public record identifies the expected sponsoring registrar, registry expiry is understood, nameserver delegation is unchanged, DNSSEC still validates, and web and mail checks pass.
Place the transfer beside renewal and deletion states using the domain events reference.
Evidence-to-decision table
| Evidence | What it means | Responsible next step |
|---|---|---|
| Sponsoring registrar | Current registration provider | Confirm in authoritative RDAP |
| Transfer status | Whether a lock blocks transfer | Identify client versus server control |
| Registrant contact | Where required notices may go | Update through approved account workflow |
| Delegation snapshot | Nameservers before transfer | Compare immediately after completion |
Illustrative low-risk transfer
This is an illustrative example, not a claimed real-world test.
Verify eligibility, unlock only when ready, secure the authorization code and confirm the receiving registrar account.
Export DNS and record nameservers, DNSSEC, renewal date and contact routes before approving the transfer.
After completion, verify sponsorship, delegation, DNSSEC, auto-renew and account recovery; then restore an appropriate lock.
Defensible outcome: The transfer is complete only when registration control and operational settings have been checked, not when an email says the request was submitted.
Action checklist
- Confirm authoritative registrar
- Check policy and transfer lock
- Secure account with MFA
- Verify contact access
- Record renewal and expiry
- Export DNS
- Document DNSSEC
- Protect authorization code
- Verify after completion
Edge cases that change the answer
Recent registration or transfer
A policy waiting period may apply. Check the specific reason and governing TLD policy before changing contacts or retrying.
Expired name
Renewal, expiration state and transfer eligibility interact; use both registrars' documented process instead of assuming transfer will rescue it.
Registry lock
High-security registry-lock services require an out-of-band workflow beyond an ordinary client transfer lock.
Registrant details changed
A recent material contact change can affect transfer eligibility or confirmation routes. Verify the current policy and access to every required approval channel before requesting the authorization code.
Questions this guide should settle
Will a transfer cause downtime?
Not inherently if nameservers and DNSSEC remain unchanged, but providers can apply defaults, so verify the configuration.
Does transfer add a year?
Rules and exceptions vary by TLD and timing; confirm the registry and receiving registrar terms.
Who should receive the auth code?
Only the trusted person or receiving registrar workflow carrying out the transfer. Treat it like a credential.