Pro Gineous

Posted on Oct 25 Originally published at blog.progineous.com

How to Prepare a Domain Transfer So DNS and Email Keep Working

#webdev #dns #devops #linux

Moving a domain to a new registrar should be one of the dullest jobs in IT. You switch off the lock, copy a code, pay, and a few days later the renewal invoice comes from somewhere else. The website, the mailboxes and the DNS records don't have to notice anything.

When a transfer does go wrong, it is rarely the transfer itself. It's a lock nobody knew about, an approval email sent to an address that died years ago, or a nameserver change made in the same afternoon on a domain with DNSSEC. Those are all things you can see from a terminal before you start. So this is how we prepare a domain transfer, in the order it happens: two weeks before, the week before, on the day, during the wait, and after the name lands.

What actually moves

A registrar transfer changes one field at the registry: which registrar manages the name. Your nameservers, and therefore every DNS record, stay exactly as they are unless someone changes them. That's the whole reason a careful transfer causes no downtime.

So the plan is simple. Move the registration first. Leave DNS where it is. If you also want to move DNS hosting, do it as a separate change after the transfer is done.

Two weeks before: read the registry record

Start with what the registry says about the name. RDAP gives you that as JSON, no account needed:

curl -s https://rdap.verisign.com/com/v1/domain/example.com \
  | jq '{status, events: ([.events[] | {(.eventAction): .eventDate}] | add),
         dnssec: .secureDNS.delegationSigned}'
dig +short NS example.com
dig +noall +answer DS example.com

That RDAP server is the one for .com and .net. For other endings, the RDAP lookup guide shows how to find the right server from the IANA bootstrap file.

Three things to read in that output:

Status. client transfer prohibited is the normal registrar lock. You turn it off yourself in the registrar panel, and under ICANN's Transfer Policy the registrar has to remove it within five calendar days if it doesn't offer a switch. server transfer prohibited, any kind of hold, redemption period or pending delete are different. Those need a conversation with the current registrar before anything else.

Dates. If the name was registered or transferred in the last 60 days, the current registrar is allowed to refuse the transfer. Some registries also publish a transfer event, which tells you when the last move happened.

Expiry. Leave yourself a margin. If the name expires before the transfer goes through, the request can fail and you end up renewing under pressure anyway. When expiry is close, renew at the current registrar first. For gTLDs a completed transfer still adds a year on top, within the 10-year cap.

The 60-day rules, and what ICANN has changed

Today's rules come from the Transfer Policy updated in February 2024, which registrars had to apply by August 21, 2025. Two 60-day windows matter:

After registration or after a registrar transfer, the registrar may deny a new transfer for 60 days.
After a change of registrant, the registrar must apply a 60-day transfer lock, unless you opted out before the change. A change of registrant means a real change to the registrant name, organization or email address, not a typo fix.

That second one catches people. Fixing an old registrant email the week before a transfer can count as a change of registrant and lock the name for two months. If the email needs fixing, look for the opt-out first.

On June 7, 2026 the ICANN Board adopted the Transfer Policy Review recommendations. When they take effect, the lock after registration and after a transfer becomes a fixed 30 days, the auth code becomes a one-time Transfer Authorization Code (TAC) valid for 14 days, and the 60-day change-of-registrant lock goes away. As of today, ICANN has not published an effective date, so the current 60-day rules still apply. Country-code endings like .uk or .de follow their own registry's rules either way.

One week before: snapshot DNS and look at DNSSEC

Take a snapshot you can rebuild from

Even if you never plan to touch DNS, save what's published now. If a checkout page "helpfully" resets the nameservers, or you later move DNS hosting, this file is how you put everything back:

d=example.com
for t in SOA NS A AAAA MX TXT CAA; do dig +noall +answer "$d" "$t"; done > "$d-dns.txt"
for n in www mail autodiscover _dmarc; do
  for t in A AAAA CNAME MX TXT; do dig +noall +answer "$n.$d" "$t"; done
done >> "$d-dns.txt"

It asks for each type separately because many DNS providers answer ANY with almost nothing. DKIM keys sit under selector names you have to know, such as google._domainkey or selector1._domainkey, and they're easy to forget. If any of the output looks odd, the dig output guide walks through each section.

DNSSEC is where the outages come from

If the DS query returned a record, the domain is signed. The DS record at the registry is a fingerprint of the key your current DNS provider signs with. Validating resolvers check every answer against it.

As long as the nameservers stay the same, the transfer doesn't affect this at all. The trouble starts when the nameservers move to a provider that signs with different keys, or doesn't sign. The old DS no longer matches, and resolvers that validate DNSSEC return SERVFAIL. For those users the website and email simply disappear.

So the rule is: keep the nameservers through the transfer. If you're also moving DNS, do it afterwards in this order:

Remove the DS record at the registrar.
Wait at least the DS TTL (86400 seconds, one day, in the output above) so caches forget it.
Switch the nameservers.
Turn on DNSSEC at the new provider and add its new DS record at the registrar.

There are key rollover methods that keep the zone signed the whole time, but they need both DNS providers to cooperate. For most sites, a day or two unsigned is the simpler and safer trade.

Transfer day: lock off, code, approval email

Turn off the registrar lock, then request the auth code (some registrars call it the EPP code). Most registrars show it straight away, and one that has no self-service option has to send it within five calendar days. Treat it like a password: paste it into the new registrar's order and nowhere else.

Before you submit, check which email address the approval message will go to. Public RDAP usually redacts the registrant contact, so don't rely on it here. Look in the current registrar's account instead. If that inbox is on the same domain, make sure the mail is still working there.

At checkout, read the nameserver options. Some registrars offer to switch the name to their own nameservers. Say no for now.

The five days in between

Once the new registrar sends the request, the registry marks the name pending transfer. The current registrar sends a confirmation message within 24 hours. If it doesn't reject the request within five calendar days, the registry completes the transfer. Many registrars let you approve that message to finish early.

During this window, DNS keeps resolving as normal. Don't edit records, contacts or nameservers while the transfer is pending.

After it lands

Run the same RDAP and dig commands again and compare:

The registrar field shows the new registrar, and the new registrar's lock is on.
NS and DS match your snapshot exactly.
The expiry date moved forward a year.

Then send a test email to and from the domain. If you publish DMARC, the next few aggregate reports will confirm that SPF and DKIM still pass. Only after all of that, if moving DNS is part of the plan, start the DNSSEC steps above.

Doing it in one command

We wrapped all of these checks into a read-only script. It reads the RDAP status and dates, flags locks and holds, reports DS records, and writes a DNS snapshot including the DKIM selectors you pass in:

./domains/transfer-readiness.sh example.com --dkim google,selector1

It changes nothing at the registrar or in DNS, so it's safe to run before and after the move. You can grab transfer-readiness.sh from our server toolkit on GitLab along with the other domain scripts.

The same checks apply whichever registrar the name is heading to, Pro Gineous included. Ten minutes with them up front is a lot cheaper than a week of untangling afterwards.

DEV Community