Domain transfer process from a technical perspective: Complete instructions

I describe the Domain transfer process technically, step by step, from unlocking to final confirmation in the registry. How to plan auth code, EPP processes and the DNS update clean, so that the website and e-mail remain accessible.

Key points

• Unlock and check owner data
• Auth code Request in time
• EPP-Start transfer with new registrar
• DNS update Prepare in advance
• TLD rules and observe deadlines

Preparation: Unlock domain and check data

I start with the transfer lock: I deactivate the Registrar lock in the customer portal so that the change is possible. I then check the WHOIS contact data, especially the E-mail of the holder for confirmations. If the details do not match, the process often stops for an unnecessarily long time. I also document the current setup so that I can make reliable comparisons later on. Finally, I prepare checklists so that I don't forget any technical steps.

DNS strategy before the start

Before productive moves, I plan the DNS update active to avoid failures. I set up an identical DNS zone with the new provider and test A, AAAA, MX and CNAME records. If you use external name servers, you can keep them during the change and thus significantly reduce the risk. I check the time-to-live values (TTL) and lower them in a targeted manner so that changes arrive faster worldwide. This guide helps me to avoid errors in more detail: Avoid mistakes during transfer, which I go through once before the start.

Request Auth-Code (EPP) securely

Without Auth code not a single transfer is running. I request the code from the previous registrar in my account or ask support for it. Many codes remain valid for around 30 days, so I use them promptly. For .de, I can initiate an alternative code (AuthInfo2) via the responsible operator in the event of problems. I store the code in encrypted form and never share it via unsecured E-mail.

Start transfer with new registrar

I initiate the actual change with the new provider, enter the domain and type in the Auth code correctly. In the background, the systems communicate via EPP, the XML-based protocol for registries. The new registrar sends the request, the registry checks and informs the old provider. In the case of gTLDs, there is often a short objection period, after which the registry transfers the domain. If you want to read the complete process in compact form, take a look at this guide: Change registrar: Instructions, which I like to use as a quick reference.

Technical process in the registry

To help you understand the path, I will summarize the technical steps in clear terms and put the Focal points on EPP and confirmations. First, the new registrar sends the transfer request with domain and auth code to the registry. Status checks are then carried out: Ownership, blocking, deadlines and any objections. The old registrar can agree or remain silent; a lack of response after the deadline usually means approval. After approval, the registry assigns the domain to the new registrar and updates contacts, nameservers and Status.

Use EPP status codes in a targeted manner

I read the following for hangers EPP status codes consistently because they clearly indicate where there is a problem and what action is required:

• okEverything ready, no locks active. Transfer can start.
• clientTransferProhibitedRegistrar lock active. I remove the lock in the account.
• serverTransferProhibitedRegistry or policy block (e.g. procedure/UDRP). I will clarify the reason with Support.
• pendingTransferTransfer is in progress. I will wait for the deadline or check confirmation emails.
• redemptionPeriod / pendingDeleteDomain in deletion cycle. Transfers are blocked; first recovery possible, then transfer.
• clientUpdateProhibitedUpdates locked. I remove additional locks (registry lock) before making changes.

I am aware that gTLDs, in addition to the Auth code increasingly from the term TAC (Transfer Authorization Code) - the principle remains the same: a time-limited, sensitive token that legitimizes the transfer.

Locks, 60-day rules and permissible rejections

I plan a time buffer for policies that are often overlooked. After registration or a successful transfer, many registrars set a 60-day lock, during which further transfers are usually rejected. A change of registrant can also trigger a blocking period for gTLDs, unless an opt-out has been set in advance. Permissible NACK reasons of the old registrar include: active blocks, lack of payment, identity conflicts or legal proceedings. If none of these reasons apply, a transfer should not be delayed for no reason. I therefore check in advance: Paid? Unblocked? Contacts correct? Then I avoid unnecessary loops.

DNS update without failures

I keep the site accessible by mirroring the DNS zone in a controlled manner before launching the TTL lower. During global distribution (propagation), there may be brief differences in resolution. I test the target from several networks and check A and MX records with tools such as dig or nslookup. If necessary, I temporarily set up both infrastructures in parallel until all caches have been converted. If you also want to know details about time windows, use my note below on the Duration.

Migrate DNSSEC cleanly

With DNSSEC I take the DS entry in the registry into account. If the name server and therefore the key changes, I have two safe strategies:

• Conversion with a gap: I remove the DS from the registry shortly before the switchover, wait for a global update (low TTL helps), switch to new nameservers and then set the new DS. This avoids SERVFAILs due to incorrect signatures.
• Seamless rollover: I store the new DNSKEY in parallel (KSK rollover), have it signed and then update the DS. Only then do I remove the old key. This reduces validation risks with strictly validating resolvers.

Support registry and provider CDS/CDNSKEY, the DS update can be partially automated. Without automation, I control the sequence manually and log the times so that I can check quickly in the event of faults.

Child nameservers and glue records

If the domain uses its own name servers (e.g. ns1.mydomain.tld), exist Host objects/Glue records in the registry. I am planning separately here:

• Before the transfer, I add additional IPs from the new infrastructure to the host objects (dual stack, dual provider) so that the resolution works reliably during the transition phase.
• After the transfer, I remove old IPs again as soon as all caches point safely to the new path.
• I check whether the new registrar directly supports the administration of the host objects; if not, I coordinate the change closely with both supports.

This prevents domains on my child name servers from unexpectedly becoming unresolvable as a result of the transfer.

TLD special features and deadlines

Deadlines and approvals change depending on the ending, so I take a close look at the TLD. gTLDs such as .com or .net usually use an objection period of a few days before the change takes effect. .de moves almost in real time once the valid code is available. Country-code extensions (ccTLDs) behave differently and follow their own rules. The following overview classifies the most important points and helps with the Planning.

TLD	Transfer process	Special features	Code/confirmation	Nameserver behavior
.com / .net / .org	Request via EPP, short objection phase	Old page remains accessible with correct DNS-Preparation	Auth code mandatory, owner receives mails	Set up new zone beforehand or keep external name servers
.de	Real-time transfer after code entry	Optional alternative code (AuthInfo2) possible	Auth code mandatory, confirmation often directly in the process	Old zone can be dropped, therefore prepare zone with new provider
ccTLDs (various)	Very different, registry-dependent	Partly additional evidence or deadlines	Sometimes code, sometimes other releases	Check beforehand whether external name servers remain

Settlement, terms and expiry phases

I lose the Extension logic not out of sight: For many gTLDs, a successful transfer extends the term by one year (up to the maximum limit). Some ccTLDs - including .de - do not have this automatic extension upon transfer. If a domain is about to expire, I can avoid any nasty surprises:

• I don't start transfers at the last minute. If the domain falls into the Grace- or Redemption phase, transfers are often blocked or only possible after recovery.
• Auto-renewal with the old registrar can lead to interim invoices; after a successful transfer, these are often reversed for gTLDs. I document the dates clearly.
• After the change, I activate the following with the new registrar Auto-Renew again so that there are no gaps.

Scheduling and TTL timetable

For critical projects, I set aside a small Runbook plan right:

• T-7 to T-3 days: Mirror zone, set up monitoring (HTTP, MX, DNS). Reduce TTLs of relevant records to 300-600 seconds.
• T-2 days: Check Auth-Code, remove locks, revalidate contacts.
• T-1 day: Run last zone synchronization, implement DNSSEC plan (remove DS or rollover).
• T (outside peak times): Initiate transfer, monitor logs and status in both portals.
• T to T+1: After successful takeover, repeat tests, finalize DS/records, dismantle old infrastructure in an orderly manner.
• T+2: Gradually increase TTLs, finalize documentation.

Avoid common stumbling blocks

I avoid outdated WHOIS data, because misdirected emails are unnecessarily costly Time. An active transfer lock blocks every start, so I check it first. TTL values that are too high cause long propagation, so I reduce them in advance. Different zone levels with the old and new provider lead to inconsistent resolution. I therefore check the records meticulously before the start and document each Amendment.

Plan mail and hosting move separately

The transfer only affects the registry, not files or mailboxes, and I always keep that in mind. clear. I migrate web content via SFTP or backup restore and test it before going live. I move mailboxes using IMAP sync or export/import so that no messages are missing. I transfer SPF, DKIM and DMARC cleanly to the new zone. Only when everything is in place do I increase the TTL again and back up the Stability.

Mail delivery and parallel operation

I am thinking particularly of E-mail-Flows. During the changeover, incoming mails can sometimes end up at the old MX and sometimes at the new MX, depending on the resolver. This is how I react:

• For high volumes, I plan a short freeze phase for mailbox structure changes so that no shifts are lost.
• If required, I use Dual Delivery (temporarily two MX targets) or a central relay that serves both backends - well-dosed and controlled.
• After the transfer, I verify SPF, DKIM and DMARC again and check the evaluation of the recipients using DMARC reports.

Security checks after the change

After the successful migration, I activate the Transfer ban again. I set up 2-factor authentication in the customer account and secure the auth code history. I check WHOIS details again to ensure that visibility and data protection are correct. I fix errors in DNSSEC, SPF or DKIM immediately, because emails suffer greatly here. Finally, I document all the steps and keep Backups ready.

Rework: Monitoring, Auto-Renew, Audit

I check the Auto-Renew-setting and, if available, set notifications before expiration. I run 24-48 hours of active monitoring for website, API endpoints, MX, SPF/DKIM checks and DNSSEC to catch edge cases in caches. For audits, I archive screenshots, export files, zone states and EPP events (e.g. pendingTransfer → ok) so that any subsequent queries can be clearly documented.

Privacy, RDAP and contact channels

With active Privacy/Proxy I make sure that confirmation emails reach me (forwarding works, ticket system does not filter away). Some registrars now use RDAP-based contact channels instead of WHOIS. I keep the registered emails consistent and avoid spontaneous contact changes shortly before the transfer so that no validation block takes effect.

Internationalized Domains (IDN)

At IDNs I check the spelling and Punycode consistently in all systems. I check certificates (SAN entries), redirects and applications that may only accept ASCII labels. A transfer doesn't change anything, but errors tend to creep in during parallel DNS conversions.

Stack transfers and organization

If I transfer several domains, I bundle them in Stack transfers with identical procedures: uniform TTL strategy, central table for auth codes and deadlines, clear escalation paths. I prioritize critical zones (e.g. SSO provider, MX) and ensure increased monitoring. This allows me to maintain an overview and reduce context changes in the team.

Troubleshooting: When the transfer hangs

If the process gets stuck, I work out a clear List from. I check the lock, code validity, owner emails and name server entries. I then request status logs from the new registrar and ask the old provider to send feedback to the registry. In the case of .de, I request a new code and restart the process. In case of doubt, I pause productive switchovers until the DNS is consistent and trouble-free is running.

Briefly summarized

I hold the Domain transfer process tight: first unblock and check data, then save auth code, then start EPP transfer. At the same time, I set up the DNS zone with the new provider and lower the TTL. During the deadlines, I monitor status messages and test resolution and mail. After the transfer, I activate the transfer lock, set security checks and increase the TTL again. If you stick to this sequence, you can move domains in a controlled manner and preserve Accessibility.