Halloween at Nexthosting: 10% off game servers with the code – until November 1
Domain transfer guide: how to request the AuthInfo code, lower your TTL, back up DNS, and check your mail configuration to avoid downtime.
Yes, here's how to transfer your domain safely: request the AuthInfo code, unlock the domain at your current provider, and lower the TTL values in advance. Expect a few days for the complete transfer; DNS changes themselves often take effect within minutes to hours when the TTL is low. Back up your DNS zone file and email configuration beforehand, because that's exactly where most avoidable mistakes happen.
In short:
- Request the AuthInfo code in good time and significantly lower the TTL values at least two days before the transfer to allow fast DNS changes.
- It's important to back up all DNS zone files, email configurations, and Whois data beforehand to avoid mistakes during the move.
- For a domain transfer, the new server environment and all DNS records should already be fully set up to minimize downtime.
- For DNS changes during the move, the TTL value must be low, since otherwise caches will keep serving old records for up to 48 hours.
- The process consists of requesting the AuthInfo code, unlocking the domain, confirming the transfer via the FOA email, and setting up the website and email in parallel.
A domain transfer rarely fails at the transfer itself. It fails because of forgotten details: an outdated Whois address, an MX record that gets lost in the provider switch, or a transfer lock that nobody disabled. This step-by-step guide to switching domains follows exactly the order in which experienced server operators proceed.
Preparation, before you touch anything:
The actual domain transfer:
For game server operators, one point is often overlooked: the new server environment should be in place before the domain moves at all. If you run, for example, a Minecraft server, you don't want to discover only after the transfer that the new server isn't configured yet while the domain already points to it. So plan the technical setup before the actual domain switch, not after.
The term “DNS propagation” is misleading. There is no global delay that simply runs out. What actually happens: DNS resolvers worldwide cache your records for the duration specified by your TTL (Time To Live) value. If the TTL is low, the old record disappears from the caches correspondingly fast, as a technical analysis of DNS propagation explains.
The practical timeline looks like this: lower the TTL values to a very low value, for example a few minutes, at least two days before the planned switch. Make the change. Watch the propagation across several resolvers. Afterward, set the TTL back to a higher value to keep the server load from DNS queries low.
The records mainly affected are A, AAAA, CNAME, MX, TXT, and NS. Changing the nameservers themselves generally takes longer than a simple A record change, because the registry level is also involved. With DNSSEC enabled, the switch requires particular care, since incorrectly signed zones can cause resolution errors.
dig or nslookup to check which value your resolver is currently returning.Pro tip: Don't wait until moving day to lower the TTL. An old, high TTL value of 86,400 seconds stays in other people's caches for a whole day, no matter how quickly you switch afterward.
The AuthInfo code is an alphanumeric security key that the current provider generates at the domain holder's request. It authorizes the transfer and prevents third parties from taking over a domain without permission. Without this code, no reputable destination registrar will start a transfer.
A special rule applies to .de domains: the AuthInfo code is often valid for only 30 days and becomes invalid if contact details change in the meantime. So only request it when you are actually about to carry out the transfer.
The ICANN transfer policy prescribes an FOA (Form of Authorization) procedure for generic top-level domains, along with confirmation obligations for both registrars and a 60-day transfer lock after every change of registrant.
If the old provider doesn't cooperate for a .de domain, there is a way out: the new provider can request the AuthInfo directly from DENIC. DENIC then sends the code by registered mail to the registered domain holder, which effectively prevents blockades by unwilling providers.
The safest migration strategy is overlap: the old and new environments run in parallel until you're sure everything works. Practical guides to DNS migration recommend exactly this order, because most outages are not caused by DNS itself but by an incompletely prepared new environment.
If you set up a VPS for the new environment in parallel, you can run this test completely isolated from live operation.
First check the DNS responses through several public resolvers at once, not just from your own computer. Look at the server logs and watch for SSL errors, faulty redirects, or sudden spikes in 404 or 500 errors.
If the problems persist after 72 hours, it's time for deeper checks: Is the A record correct? Have the nameserver entries at the registrar really been updated? Does the DNSSEC signature match the new zone? Is the VirtualHost configuration on the new server set up cleanly?
If the problem persists, contact the registrar or registry. Have the following ready: the FOA confirmation, the transfer hash or transaction number, and the exact timestamp of the switch.
Pro tip: Note the date and time of every single change during the move. If the registrar has follow-up questions, this saves you several support tickets.
A domain transfer rarely affects the domain alone; usually an entire game server or project depends on it. A hosting provider often supports customers with a staging environment for testing before the actual move, automatic backups of the existing configuration, and help with the DNS and SSL setup during the switch. If you don't want to take on the effort yourself, you can use optional managed support.
If you also want to check how your own hosting setup stands in terms of data protection, the data protection checklist for hosting in Germany is a good starting point, especially for email migrations involving sensitive user data.
The usual guides focus almost exclusively on the formal transfer: AuthInfo, FOA, confirmation emails. That is the easy part. What actually causes outages is the assumption that DNS propagation is a mysterious process you simply have to wait out. That's not true. TTL is a value you control, not a law of nature.
The second blind spot: email. Many guides mention MX records only in passing, yet interrupted mail delivery is often worse for a community admin than a few hours offline. If you run a server for Garry’s Mod and inform your community by newsletter, you often notice a broken SPF record only when complaints about undelivered emails start coming in.
My priority for readers short on time: lower the TTL two days beforehand, fully finish and test the new environment, and only then start the transfer. The order matters more than speed.
— Erik
If you're transferring your domain, you usually also need a suitable new environment for it, and this is exactly where Nexthosting is worth a look. The domain service is suited for new registrations or for managing your domain, while a VPS provides the technical foundation for a website, database, or mail server, independent of the domain's destination registrar. For anyone who also runs a game server, such as a Rust server, the move can be tied directly to the new server environment instead of maintaining two separate projects. Not sure which configuration fits your project? Support can help you assess it before you order anything. If you also need to move a WordPress site, you'll find help with the technical setup of the new website at Adworth. Check out the matching product page and get started with an inquiry instead of going through the move alone.
For binding rules on switching providers for .de domains, DENIC is the authoritative body; for generic TLDs, it is the ICANN transfer policy. For DNS verification after the switch, multi-resolver checks and the technical explanation of TTL-based propagation are useful.
Request the AuthInfo code early, unlock the domain at your current provider, and lower the TTL values at least 48 hours before the switch. Also back up your DNS zone file and email configuration before anything is changed.
You request the AuthInfo code from your current provider, unlock the domain, and start the transfer at the destination registrar using that code. You then confirm the FOA email, after which the transfer usually continues automatically.
For private domain owners, the same process applies as for businesses: request the AuthInfo code, unlock the domain, and start the transfer at the new provider. For .de domains, if you have problems with the old provider, you can, as a last resort, request the AuthInfo directly through DENIC.
The complete transfer usually takes several days, depending on confirmation times and the TLD in question. DNS changes themselves often take effect within minutes to a few hours if the TTL was lowered beforehand.