Domain Transfer Auth Code: Unlock, 60-Day Rule and Timing

Moving a domain to a new registrar is routine, until you discover who was really running the DNS, or that the client changed its company name last month. Generic TLDs (.com, .net, .org and newer gTLDs) follow ICANN's Transfer Policy; country-code domains set their own rules. If you look after Italian clients, the .it section is where the surprises are.

What an auth code (EPP code) is

The auth code, also called EPP code, AuthInfo or transfer key, is a password tied to a single domain and stored by the registry. EPP is the protocol registrars use to talk to registries, and RFC 5731 defines this authorization information as the mechanism that enables transfers: the new registrar submits it with the request, and if it does not match what the registry holds, the request is rejected.

Whoever holds the code can start a transfer, so treat it like a password; RFC 5731 warns that inadvertent disclosure can lead to unauthorised transfers. The code belongs to the registrant, not to the agency managing the domain. For gTLDs, if your control panel will not generate it, the registrar must provide it within five calendar days of your request, and cannot withhold it over a payment dispute alone.

Transfer lock and the 60-day rules

Many registrars switch on a transfer lock (registrar lock) by default. It shows in registry data as clientTransferProhibited, and while it is set every transfer request is refused. You remove it in the control panel or ask the registrar, which for gTLDs has the same five days. Then come the time-based restrictions. Under ICANN's Transfer Policy currently in force (version of 21 February 2024):

• the registrar may deny a transfer requested within 60 days of the domain's creation date;
• it may deny a transfer within 60 days of a previous inter-registrar transfer;
• after a change of registrant, meaning a material change to the registrant's name or organisation or any change to their email, it must apply a 60-day transfer lock, unless the registrant opted out before the change. Offering that opt-out is at the registrar's discretion.

The losing registrar can also deny for fraud, a reasonable dispute over the registrant's identity or unpaid previous periods, and it must deny while a UDRP proceeding is pending. It cannot refuse because the domain is close to expiry, or because the registrant ignored its email.

How a .com transfer works, step by step

1. Unlock the domain and get the auth code from your current registrar.
2. Start the transfer at the new registrar and enter the code. The price usually includes a one-year renewal.
3. The registry passes the request to the losing registrar, which must email the registrant a transfer confirmation within 24 hours.
4. The losing registrar can approve straight away, deny on a permitted ground or do nothing. If it does not respond within five calendar days, the transfer is approved by default.
5. Once the transfer completes, one year is added to the existing expiry date, capped at ten years of total remaining term.

In practice a .com moves in anything from a few hours to five calendar days, and many losing registrars put an approve-now link in the confirmation email. That email goes to the registrant address on file, so check it first, especially if it is a mailbox on the domain being moved, hosted by the old provider. If the domain has already expired, ask the new registrar how the new expiry will be calculated, since registry-specific rules apply.

Transferring a .it domain: the Italian registry's rules

The .it registry is not bound by ICANN's Transfer Policy. Its Regulation and Technical Guidelines call the process a change of registrar, and several things work differently:

• The registrar gives the registrant the AuthInfo code at registration and whenever it changes. Lost it? Ask your current registrar; the registry steps in only if the registrar cannot be reached or refuses.
• The Technical Guidelines set no 60-day restrictions. The registry checks the AuthInfo and that the domain is not in a blocking status such as clientTransferProhibited, pendingUpdate, pendingDelete, redemptionPeriod, clientHold, serverHold or revoked.
• The domain then sits in pendingTransfer for at most one day; unless cancelled or rejected, the registry approves it automatically.
• The losing registrar can only block the transfer if it has been served a formal order from the competent authorities about that domain. Commercial reasons do not count.
• Registrar and registrant can be changed in one operation; the old registrant hands the AuthInfo to the new one.
• When the transfer completes, the new registrar confirms it and gives you a new AuthInfo code.

What happens to the expiry date of a .it

This is where answers online contradict each other. According to the nic.it FAQ, .it domains run for one year from registration or from the latest change, such as a transfer. The registry's own example: registered on 30 June 2013, transferred on 1 February 2014, expires on 1 February 2015. So unlike a .com, the expiry is not extended by a year; it resets to one year from the transfer date, and months left with the old registrar are not carried over.

The registry also advises checking the term of your contract with the registrar, a separate commercial agreement, which is why providers answer differently. To avoid paying twice, schedule the transfer in the weeks before expiry and check whether the old registrar has already billed you for the next year.

Generic TLDs vs .it at a glance

What happens to DNS and email during a transfer

A transfer changes the registrar, not the nameservers. The delegation at the registry stays as it was, so the website and email keep resolving. If your DNS is hosted elsewhere, for example in your cPanel hosting's zone editor, nothing changes.

The real risk is when the domain uses the old registrar's bundled nameservers. Once the domain has left, that zone can be deleted along with your A, MX, SPF and DKIM records, taking site and email down. To keep disruption to a minimum:

• copy the full zone first: A, AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC, verification records), SRV and CAA;
• recreate it at the new DNS provider and compare answers record by record against the new servers;
• move the nameservers as a separate step, before or after the transfer, never at the same time;
• if the old registrar supplies your mailboxes or forwarding, migrate mail first: that service ends with the contract;
• with DNSSEC enabled and a change of DNS operator, coordinate the DS record: if it does not match the new operator's keys, validating resolvers return SERVFAIL and, for their users, the domain stops resolving.

# Status, registrar and expiry (field names vary by registry)
whois example.com | grep -iE 'status|registrar|expir'

# Delegation and records to keep
dig NS example.com +short
dig MX example.com +short
dig DS example.com +short

# Ask the new DNS servers the same question before moving the delegation
dig @ns1.new-dns.example MX example.com +short

Domain transfer checklist

1. Confirm who the registrant is, and that the registrant email is live and actually read.
2. For a gTLD, check the creation date, the last transfer and any registrant changes in the past 60 days.
3. Check the expiry date: for a .it, plan the transfer in the weeks before it; for a gTLD, avoid the last few days.
4. Copy the DNS zone and decide where it will live afterwards.
5. If you are changing DNS provider, move the nameservers as a separate step and wait for it to complete (for a .it, until the registry's DNS check has passed).
6. Remove the transfer lock (clientTransferProhibited).
7. Get the auth code and store it like a password.
8. Start the transfer at the new registrar and approve the confirmation email if you receive one.
9. Check the new registrar, status and expiry date in whois.
10. Re-enable the transfer lock on gTLDs and, for a .it, keep the new AuthInfo code safe.
11. A few hours later, test website, email, SPF, DKIM and DMARC; cancel leftover services at the old provider only once everything works.

If the code is rejected, it has usually been regenerated or pasted with extra spaces; if the transfer is refused, whois normally shows why: a lock still in place, the 60-day rules or, on a .it, a pendingUpdate. And if you manage dozens of client domains and would rather someone else tracked codes, confirmations and DNS, lubemy can handle the transfer, starting with a status check on every domain before anything is touched.