Domain transfer checklist: AuthInfo code and DNS

Quick answer: For a covered gTLD such as .com, .net or .org, check transfer eligibility and contact access, unlock the domain when appropriate, obtain its private AuthInfo/Auth-Code, and start the move with the gaining registrar. Separately, record who hosts the authoritative DNS, website and mail; confirm whether the new registrar requires a DNS move; and check those services before and after any nameserver change. A registrar transfer is not, by itself, a web-hosting migration. Sources: ICANN transfer FAQ, ICANN Transfer Policy.

Important constraint: Keeping the website and email working depends on the DNS and service handoff, not simply on receiving a transfer-complete message. A new DNS provider can miss records, and an incorrect DNSSEC/DS setup can disrupt resolution. Confirm the gaining registrar’s nameserver rules before assuming the old DNS configuration can remain. Cloudflare Registrar, for example, requires its DNS to be active and its assigned nameservers. Sources: Cloudflare DNS setup, Cloudflare transfer guide, Cloudflare Registrar FAQ.

This checklist separates the transfer into two lanes. The registration lane changes which registrar manages the name. The service lane keeps the name pointing to the intended web and mail systems. An owner may complete one lane without changing the other, but a new registrar’s policies can tie them together. The steps below use ICANN’s covered generic-TLD policy as the baseline; country-code and registry-specific rules may differ.

Map the four services before changing an account

A domain can involve four companies even if one dashboard currently hides that complexity. The registrar manages the registration and transfer. The authoritative DNS provider publishes the records that direct traffic. The web host serves the site or app. The mail provider accepts and sends mail for the domain. One vendor may supply several roles, but moving registration does not automatically move all the services. ICANN’s holder FAQ distinguishes changing a registrar from changing the hosting or nameservers.

Before starting, write down the vendor and account owner for each role. Check whether web or mail service is bundled with the current registrar and what happens to that service when registration leaves. Keep paid services active until a replacement is verified. An owner who cancels the old account immediately after transfer can lose a DNS zone, mailbox or hosting plan that was still supplying a live service. The precise cancellation terms belong to the provider contract, so verify them for your account.

Make one person responsible for comparing the pre-move and post-move states. Even for a single-owner business, putting the facts in a private checklist is safer than relying on memory while confirmation emails and registrar interfaces change around you.

Registration lane: check eligibility before paying

For covered gTLD transfers, ICANN’s Transfer Policy lists circumstances in which the current registrar may deny or must deny a transfer. Relevant examples include a domain created within the previous 60 days and one transferred between registrars within the previous 60 days. A recent change of registrant can also trigger a 60-day inter-registrar lock under the policy; an opt-out only helps where it is available and was used before the change. These are policy windows, not a determination that your particular domain is eligible today.

Suppose a .com was registered 40 days ago. The owner should check the creation-date rule before buying a transfer or planning a switch this week. In a different case, suppose the name holder’s details changed yesterday. That change may have started its own lock even though the registration itself is old. Checking only the domain’s original creation date would miss the second issue. Review the current registrar’s status and the gaining registrar’s requirements before changing holder details, particularly if the transfer is time-sensitive.

Confirm that the name holder can access the account and the contact email that will receive notices. Check multifactor access, expiry or renewal status, and any dispute or payment issue shown in the account. Ask the gaining registrar whether it accepts the TLD and what transfer, renewal or expiry treatment it quotes for this domain. ICANN’s baseline does not establish a universal checkout price or how each provider’s dashboard sequences the steps.

The AuthInfo code, also called an Auth-Code or authorization code, is the credential used for a covered inter-registrar transfer. Obtain it through the current registrar’s secure route and enter it only into the gaining registrar’s legitimate flow. Do not paste it into a public ticket, screenshot, analytics note or team chat with broad access. ICANN’s Auth-Code guidance says that if the holder cannot generate the code in the control panel, the registrar must provide it within five calendar days of a request. That is a provision rule, not a promise that every transfer will finish in five days.

When ready, follow the gaining registrar’s instructions and watch the approval notices. The ICANN policy has a default approval path after five calendar days in specified circumstances if the losing registrar does not issue a permitted denial. Account verification, payment, TLD rules and provider processing can add other steps, so schedule around the actual status messages instead of treating five days as a guaranteed end-to-end deadline. Preserve notices and confirmation IDs privately until the new registrar shows the correct name holder and renewal date.

Service lane: inventory records before a nameserver change

Find the authoritative nameservers currently serving the domain and identify where their zone is edited. If the gaining registrar permits those nameservers to remain and the DNS service stays active, a registrar-only move may leave the DNS path largely unchanged. If the gaining registrar requires a DNS-provider change, plan that as its own migration. Cloudflare Registrar is a concrete exception to an “always keep the same nameservers” assumption: its FAQ requires Cloudflare-assigned nameservers, and its transfer guide places DNS setup before the registrar transfer.

Export the current zone if the provider offers an export, then compare its records with the prospective DNS provider’s import by hand. Cloudflare warns that automatic scanning may miss entries. The inventory should include the apex and www, app or shop hostnames, inbound mail and mail-authentication records, third-party verification records, certificate-authority restrictions and DNSSEC state. Document what each record supports so an unfamiliar TXT value does not get discarded as clutter.

The entries are record categories, not values to copy into a real domain. Record your own expected hostname, type and value, who owns the dependency, how you checked it, and when it should be rechecked. A private inventory can include screenshots or exports, but keep transfer credentials out of it. A “site loads” check alone will not reveal a lost MX record or a missing DKIM key that affects mail later.

If DNSSEC is enabled, follow the current and new providers’ specific handoff procedure. A stale DS record can make a correctly populated new zone fail validation. Do not guess the order of disabling, replacing or re-enabling DNSSEC for a particular provider; get its documented sequence and confirm the resulting state. Cloudflare’s transfer instructions explicitly call out DNSSEC as part of the move.

Sequence the handoff and check what users actually receive

Where the providers allow it, avoid making the registrar transfer and nameserver change at the same moment. First establish a working DNS zone and compare all required records. Check the website and mail against the old authoritative setup. Change nameservers when the new provider’s instructions call for it; then confirm that authoritative answers reflect the intended values and that the site, subdomains, inbound mail and outbound mail checks still work. Keep the previous DNS service active until the new authoritative zone and dependent services have been verified. Cloudflare’s required DNS-first sequence is one reason this order must be adapted to the chosen registrar rather than treated as a universal script.

Use a simple validation log. For each check, write the expected result, the observed result, the time, and a contact or rollback route. Test a page that depends on the correct backend rather than only a generic home page. Send mail from and to the domain using accounts you control and confirm the received message belongs to the intended provider. If the owner cannot interpret a DNSSEC failure or a missing record, the log gives a DNS provider or host enough context to help without sharing an AuthInfo code.

If something fails, diagnose by lane. Transfer not starting? Check the current lock, recent creation or transfer, change-of-registrant date, code validity and confirmation mail. Domain resolves but the site is wrong? Compare the authoritative nameservers and web records with the inventory. Site works but mail fails? Recheck MX and relevant TXT records and whether the old mail service is still active. Some resolvers reject the domain? Include DNSSEC/DS in the investigation. These checks narrow the problem; they do not replace provider-specific support when a live service is down.

Close the task only after the service lane is healthy

Confirm that the gaining registrar lists the domain under the intended account and that the holder and renewal details look right. Save the final notices, revisit account security and expiry reminders, and confirm which provider now handles DNS. Repeat the website and mail checks after the move rather than assuming a successful transfer notice covers them. Keep the inventory for the next renewal, host migration or registrar change.

For a covered gTLD, the practical order is eligibility and access → secure AuthInfo code → DNS/service inventory → provider-specific DNS preparation → transfer notices → post-move validation. The exact nameserver and DNSSEC steps depend on the chosen providers. This checklist is designed to expose the dependencies that can interrupt a site or mailbox; it cannot guarantee uninterrupted service for a particular domain. If the decision is instead about ongoing cost, compare renewal terms separately from the transfer’s operational plan. The domains hub covers that broader decision.