Domain Transfer: Moving to Another Registrar Without Downtime or Lost Email

Short answer. "Domain transfer" hides three different jobs: changing registrar, changing owner, and moving the website to a new host. In a registrar transfer the domain stays yours — what breaks is almost never the domain, it is the DNS zone that lived at the old registrar. Safe order: export every record, build the zone at the new provider, lower TTLs, diff the answers, and only then switch NS.

"Domain transfer" is three different jobs

Before you click anything, work out what you are actually moving. The three scenarios share a name but happen in different control panels, break different things and need different checks.

1. Registrar transfer. The domain stays yours; only the company that holds the registry record changes. Technically this is an operation in the registry of the TLD, not on your server.
2. Owner / registrant change. The domain stays at the same registrar, but the person or organisation it is registered to changes. This is a legal operation, not a technical one.
3. Moving the website to a new host, same domain. The domain is not touched at all — A/AAAA records or NS change. This is not a "domain transfer", even though people search for it that way.

If yours is the third case, start here instead: the website migration checklist, connecting a domain to hosting and changing DNS servers. The rest of this article covers the first two scenarios.

Job	What actually changes	What can break	How to verify
Registrar transfer, gTLD (.com, .net, .org, .io and similar)	The registrar field in the registry; the domain moves under a contract with a new company	The DNS zone, if it was hosted at the old registrar; auto-renew; expiry notifications	whois — new registrar and new statuses; dig NS — delegation unchanged
Registrar transfer, country-code TLDs with national rules	The registrar servicing the domain under the ccTLD registry's own policy	The same, plus loss of verified registrant data if it does not match documents	whois — registry-specific fields such as state, paid-till, nserver
Owner / registrant change	Contact and identity data — who the domain is registered to	A possible transfer lock for a period after the change; loss of control-panel access	whois contact fields; mail to the new registrant address actually arrives
Website move to a new host	A/AAAA records or the whole delegation; the domain itself does not move	Site, email, SSL, cron jobs, IP-based integrations	dig A, dig MX, an HTTPS check and a real test email

gTLD transfer: auth code, registrar lock, email confirmation

For international TLDs — .com, .net, .org, .info, .io and most new gTLDs — the transfer procedure is set by ICANN policy and is the same everywhere. Only the user interfaces differ.

Remove the transfer lock

By default a domain usually carries the clientTransferProhibited status — the registrar lock, an anti-hijacking measure. While it is set, the registry rejects any transfer request. It is removed with one toggle at your current registrar, though the status sometimes takes a while to disappear from whois.

There are also registry-imposed statuses such as serverTransferProhibited. Your registrar cannot remove those — they usually mean a court order or a registry-level hold, and no control panel will help.

Get the authorization code

The authorization code goes by several names: auth code, EPP code, AuthInfo, Transfer Authorization Code (TAC). It is a one-time secret proving to the gaining registrar that the request comes from someone with control over the domain.

The authorization code is the password to your domain. Do not paste it into a group chat, do not read it out over the phone, do not leave it in a support ticket. A leaked code plus an unlocked domain is a ready-made hijacking recipe.

Practical details: the code is normally issued on request and valid for a limited time, after which you request a new one; some registrars mail it to the registrant address instead of showing it in the panel; case matters; and characters like 0/O or l/1 should be copied, never retyped.

Confirm from the registrant email

The transfer is confirmed by the registrant contact — the address visible (or hidden) in whois. If that address is stale, the mailbox is closed, or mail simply does not arrive, the transfer silently fails and you will not know why. Verify access to that mailbox before you start — and if it lives on the domain being moved, make sure email will keep working through the whole migration week.

How long it takes

After you submit the request at the gaining registrar, the losing registrar is notified and gets a window in which it may decline. If nobody acts, the transfer is normally auto-approved once that window closes — in practice a few days. Explicitly approving the transfer in the losing registrar's panel makes it much faster, sometimes hours.

It is just as important to know what a transfer does not do: it does not change your NS records, does not copy the contents of your DNS zone, and does not touch your website. The domain simply starts being serviced by a different company. Everything else is on you. Transfer policy documents are published by ICANN.

Country-code TLDs: a different procedure entirely

ICANN policy does not govern country-code TLDs. Each ccTLD registry writes its own rules, and "get the EPP code" often simply does not apply. The Russian .RU and .РФ zones are a good example of how far the model can diverge; their rules are published by the Coordination Center for TLD RU/РФ.

• No familiar auth code. Instead of a one-time secret, a registrar change is initiated by an application from the registrant, following the procedure described in the registrar's own regulations. Some registrars accept it at the losing side, some at the gaining side.
• Identity is verified. Registrant data in the registry must match the applicant's documents — full name and identity document for individuals, company details for organisations. A single mismatched character is a routine reason for rejection.
• The registration term does not change. A registrar change does not extend the domain: the paid-until date stays as it was. This is the opposite of the gTLD behaviour.
• There are windows when transfers are unavailable. Registry rules restrict registrar changes during certain lifecycle stages — for example when the domain is unpaid, undelegated, or inside a renewal grace period. Read the current edition of the rules rather than memorising numbers: they change.
• Whois looks different. Many ccTLDs do not use EPP statuses like clientTransferProhibited at all, publishing registry-specific fields instead.

Do not apply a .com playbook to a ccTLD. In gTLDs the key to the domain is the authorization code; in many national zones it is verified registrant identity. Different trust models fail in different ways.

What blocks a transfer

Transfer requests get rejected far more often than people expect, and the error message is usually useless. Check this list before you submit.

• The transfer lock is on. clientTransferProhibited in whois. Remove it at the losing registrar.
• Recent registration. A newly registered domain cannot be transferred for a period. The rule exists in gTLDs and in most national zones; the exact length depends on the current policy edition.
• A recent previous transfer. A domain that just changed registrars is locked for a cooling-off period. Moving twice in a month will almost certainly be refused.
• A recent registrant change. In gTLDs, changing registrant data has traditionally triggered a temporary transfer prohibition. The rule and the opt-out mechanics have changed over time — confirm the current behaviour with your registrar.
• Stale or unreachable registrant email. The most common and least visible cause: the confirmation goes nowhere. Especially dangerous when the mailbox lives on the domain being moved.
• Whois privacy hides the contact. Privacy protection replaces the registrant address with a proxy. Some registrars forward the confirmation correctly, some do not. Safer to disable privacy for the duration of the transfer and re-enable it afterwards.
• A dispute or legal claim. A domain under UDRP, litigation or a pre-action claim carries a server-side hold and will not move.
• Outstanding balance. An unpaid domain or a negative balance at the losing registrar blocks the operation.
• The domain is in a redemption period. An expired domain in redemption or pendingDelete cannot be transferred: restore and renew first, transfer later.

If the domain has already expired the order of operations is different — see the guide to expiring and dropping domains.

What happens to the registration term

A common fear is that transferring resets the domain and burns the paid year. It does not, but the details differ by zone.

• gTLDs. A successful transfer normally adds a year to the existing term rather than replacing it. A domain paid until 2028 becomes paid until 2029. There is an upper limit on total registration length: if the domain is already paid to the maximum, the extra year may not be added.
• Many ccTLDs. A registrar change does not renew the domain at all. The paid-until date stays put and renewal is a separate action at the new registrar.
• Transferring an expired domain. Behaviour depends on the zone and the lifecycle stage. Renewing first and transferring second is the rule that always works.

A separate trap: auto-renew belongs to the registrar, not to the domain. If the old registrar had auto-renew and a stored card, the new one has nothing by default. A domain that "always renewed itself" will quietly expire in a year. Check the setting immediately after the move and add external expiry control — see domain expiry monitoring.

The real trap: DNS leaves with the registrar

The domain moves in minutes. DNS is what breaks. The reason is that at most registrars, registration and DNS hosting are the same account. You leave, the account closes, the zone is deleted along with MX, TXT, CNAME and everything else.

The incident usually looks like this: the transfer completes, the "your domain has been transferred" email arrives, the site still works — because resolvers are serving cached records. A few hours later the caches expire and everything drops at once: website, email, webhooks, subdomain-based logins.

The second scenario is faster. The gaining registrar assigns its own default NS with an empty zone on arrival. Delegation now points at live but empty name servers, so instead of the old records the world immediately gets NXDOMAIN. That is not a delayed outage, it is an instant one.

Until the zone exists at the new provider and has been diffed against the old one, do not switch NS. Not "for five minutes", not "just to check".

The architectural conclusion: keep DNS separate from the registrar. A zone hosted at an independent DNS provider — your host, a cloud platform or a dedicated service — makes registrar changes a zero-risk operation: you change the company holding the registry record while delegation and records stay exactly where they are.

How to export the whole zone before you move

The first action in any transfer is a zone snapshot. Not "I looked at the panel", but output saved to a file that you can later run diff against. If your provider can export a BIND-format zone file, use that — it is the most reliable option. If not, build one with dig.

# Dump every important record type in one pass
for t in SOA NS A AAAA MX TXT CAA SRV DS DNSKEY; do
  echo "== $t"
  dig +noall +answer example.com "$t"
done | tee zone-before.txt

# The names people forget most often
for n in www mail smtp imap ftp api cdn static autodiscover autoconfig \
         _dmarc _domainkey default._domainkey selector1._domainkey \
         selector2._domainkey _acme-challenge _sip._tls _autodiscover._tcp; do
  for t in A AAAA CNAME TXT SRV; do
    dig +noall +answer "$n.example.com" "$t"
  done
done | tee -a zone-before.txt

# If the provider allows zone transfers, this is the most complete snapshot
dig AXFR example.com @ns1.old-provider.example

dig AXFR is refused by nearly every public provider, which is correct and expected. That leaves enumeration by type and by name. To catch subdomains you have forgotten about, run the domain through a subdomain finder and compare its list with yours.

The snapshot is not only for the migration. It is your only way to rebuild the configuration if the old provider's panel closes before you remember the SRV record for the phone system.

Record type	What it is for	What breaks if it is lost
A	The IPv4 address a name resolves to	The site is completely unreachable: the browser has no idea where to go
AAAA	The IPv6 address	Silent degradation: some users and your monitoring use IPv4 and notice nothing, everyone else times out
CNAME	An alias from one name to another: www, CDN endpoints, external services	Subdomains stop resolving; ownership verification at external services breaks
MX	Where incoming mail is delivered	Incoming email stops; senders get bounces or lose messages silently
TXT (SPF)	Which servers may send mail as your domain	Outgoing mail is marked as spam or rejected by receivers
TXT (DKIM)	The public key used to verify message signatures, at selector._domainkey	Signatures fail to verify, domain reputation drops, mail lands in spam
TXT (DMARC)	Policy for messages that fail SPF/DKIM, at _dmarc	With p=reject and broken SPF/DKIM, mail is rejected hard and immediately
TXT (verification)	Domain-ownership proof for search engines, mail and cloud providers	Services lose ownership proof and disable features — sometimes weeks later
TXT _acme-challenge	DNS validation when a certificate is issued	Certificate auto-renewal fails; you find out on the expiry date
SRV	Host and port of a service: SIP, XMPP, Autodiscover, game servers	Telephony and enterprise clients cannot find the server
CAA	Restricts which certificate authorities may issue for the domain	Losing it invites rogue issuance; a wrong value blocks your own issuance
NS	Zone delegation: which name servers are authoritative	The domain's entire DNS breaks, email and subdomains included
DS / DNSKEY	The DNSSEC chain of trust	Validating resolvers return SERVFAIL — the domain vanishes for part of the internet

The correct order for switching NS

Changing delegation is the one irreversibly visible step. Everything else can be rolled back; switched NS live on in caches and in the parent zone on their own schedule. The sequence below gives zero downtime.

1. A week out: inventory. Zone snapshot, list of external services holding records in your DNS (mail, CDN, payments, analytics, webhooks), list of subdomains.
2. Two or three days out: build the zone at the new provider. Create every record one to one, but do not switch NS. The zone exists; nobody is asking it yet.
3. Two or three days out: lower TTLs. Drop record TTLs to 300 seconds at the old provider. The subtlety: you must do this early, because the old TTL value is itself cached — with a previous TTL of 86400 your change reaches resolvers up to a day later. Do not forget the negative TTL in the SOA, which controls how long "no such name" is cached.
4. A day out: diff the answers. Query both sets of name servers directly and confirm they answer identically. While the diff is non-empty there is nothing to switch.
5. Cutover: switch NS. Change delegation in the registrar panel. From this moment resolvers gradually start asking the new servers.
6. After: do not delete the old zone. Keep it alive for at least a week, preferably two. You do not control the TTL of NS records in the parent zone — it is typically measured in days, and some resolvers will keep hitting the old servers long after cutover. As long as both sets answer identically, nobody notices the difference.
7. A week later: restore TTLs. Raise them back to normal values (an hour or more), otherwise you are giving away free load on your own DNS servers.

# Compare old and new name server answers, ignoring TTL
OLD=ns1.old-provider.example
NEW=ns1.new-provider.example

norm() { dig +noall +answer @"$1" "$2" "$3" | awk '{$2=""; print}' | sort; }

for t in A AAAA MX TXT CAA SRV NS; do
  echo "== $t"
  if diff <(norm "$OLD" example.com "$t") <(norm "$NEW" example.com "$t"); then
    echo "  identical"
  fi
done

# Same for subdomains
for n in www mail api _dmarc _acme-challenge; do
  diff <(norm "$OLD" "$n.example.com" TXT) <(norm "$NEW" "$n.example.com" TXT)
done

The name-server change itself and its usual failure modes are covered in how to change DNS servers; record syntax and values are in the DNS records guide. Why "propagation" is never instant is explained in DNS propagation.

DNSSEC: how a migration takes the domain down completely

If DNSSEC is enabled, a migration stops being "copy the records". The registry publishes a DS record — a fingerprint of your key. Validating resolvers (every major public resolver and most ISP ones) use it to verify the signatures your zone returns.

Here is what a careless move does. The new DNS provider signs the zone with its keys while the registry still holds the DS of the old ones. The signature does not match the chain of trust, and the resolver does not fall back to an unsigned answer — it returns SERVFAIL. To users the domain has simply vanished, and selectively: where the resolver validates, the site is dead; where it does not, it works. Hence the classic "it opens fine for me, so it must be fine".

DNSSEC does not tolerate a partial migration. The domain either validates as a whole or does not resolve at all. There is no half-working state.

Safe options:

• Simplest: disable DNSSEC at the registrar (remove the DS), wait for the DS record to leave caches — that takes as long as its TTL in the parent zone — then change NS, and only after things settle re-enable DNSSEC with the new provider's keys.
• Correct but harder: a coordinated key rollover where the registry temporarily publishes both DS records and both zones serve both signatures. Not every provider supports it.
• Never do this: switch NS while leaving the old DS in place. That is a guaranteed outage.

# Does the domain use DNSSEC? DS lives in the parent zone
dig +short example.com DS
dig +dnssec +multi example.com DNSKEY

# Validate the whole chain of trust
delv example.com A

# Symptom of a broken chain: SERVFAIL from a validating resolver
dig example.com A @1.1.1.1 +noall +comments

# The same query with validation disabled still returns an answer
dig example.com A @1.1.1.1 +cd +short

If +cd (checking disabled) returns an address while the plain query returns SERVFAIL, the diagnosis is unambiguous: the DNSSEC chain is broken.

Email: why MX and SPF/DKIM/DMARC are lost most often

Email breaks during migrations more often than websites do, for three reasons.

First: email failure is invisible. You open the site every day and would notice an outage within minutes. Missing inbound mail looks like "a quiet day" and gets discovered twenty-four hours later, when a customer calls to ask why nobody replied.

Second: the records are many and scattered. MX sits at the apex, SPF is a TXT at the apex, DKIM lives on names like selector1._domainkey, DMARC on _dmarc, Autodiscover on a CNAME or an SRV. When someone migrates "the main records" by hand, typically only MX survives.

Third: the failure is partial. Lose MX and inbound stops. Lose SPF while DMARC still says p=reject and your outbound mail is rejected by receivers — and you will not notice, because the bounces do not come to you. Meanwhile the domain "works".

# What must be in place after the move
dig +short example.com MX
dig +short example.com TXT | grep -i 'v=spf1'
dig +short _dmarc.example.com TXT
dig +short selector1._domainkey.example.com TXT
dig +short default._domainkey.example.com TXT

# Do not know your DKIM selector? It is in the header of any
# message you sent: DKIM-Signature: ... s=selector1; d=example.com

# Is the MX actually alive? The server must answer with a 220 greeting
openssl s_client -starttls smtp -crlf -quiet -connect mail.example.com:25

# Compare MX between old and new name servers
dig +short @ns1.old-provider.example example.com MX
dig +short @ns1.new-provider.example example.com MX

Check email twice: before the move to capture the reference, and after to compare. And always send a real test message both ways — from the domain to an external mailbox and back. Automated checks do not replace proof of delivery.

SSL: certificates are not tied to the registrar, yet renewal still breaks

A widespread misconception is that changing registrar requires reissuing the certificate. It does not: a certificate is issued for a domain name, not for a contract with a registrar, and stays valid. What breaks is the renewal machinery.

• DNS validation. With DNS-01 (mandatory for wildcards) the CA checks a TXT record at _acme-challenge.example.com, created automatically through the DNS provider's API. After the move the API is different and the old credentials no longer work, so auto-renewal fails silently. You discover it two or three months later, on expiry day.
• HTTP validation. HTTP-01 survives a registrar change without trouble, but breaks if the domain temporarily resolves to a different IP during the NS cutover.
• CAA records. If the old zone had a CAA allowing only one authority and you did not migrate it, a new issuance may be refused — and even more so if you migrated it with a wrong value. Check dig CAA separately.
• Forgotten subdomains. If the certificate covered subdomains you did not migrate, some pages will fail name validation.

# What the server actually serves after the move
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

# CAA — who is allowed to issue certificates for this domain
dig +short example.com CAA

# Is the DNS validation path still working
dig +short _acme-challenge.example.com TXT

# Dry run of renewal without issuing anything
certbot renew --dry-run

A certificate that is "still valid" tells you nothing about whether it will renew. Test the renewal path, not the expiry date — and do it right after the migration, not the day before it expires.

Changing the owner is not a transfer

The second job people call "moving a domain": handing it to a different person or company. Technically the domain does not move anywhere — the registrant data changes.

• In gTLDs a registrant change is processed by the registrar and has traditionally involved confirmation from both parties plus a temporary transfer prohibition afterwards. If you plan both an owner change and a registrar change, do them one after the other, not at once — otherwise the second will hit the lock created by the first.
• In many ccTLDs this is a transfer of administration rights requiring documented identity verification from both parties, following the registrar's published procedure. The new registrant's data is verified exactly as at registration time.
• What to check afterwards: control-panel access really moved; the registrant email in whois is live and belongs to the new party; auto-renew and payment method are attached to the new owner; the previous contractor no longer holds technical access to the DNS zone.

The most common way to lose a domain is not hijacking — it is changing agencies. The domain was registered in the agency's name, the agency is gone, nobody has the credentials. Check in whois who your domain is registered to before it becomes an urgent question.

How to read whois fields is covered in the WHOIS guide; how to pick where to move is in the domain registrar comparison.

Verifying the move

A transfer is done not when the registrar's email arrives, but when four checks agree: registry, DNS, email and HTTPS.

# 1. Registry: who services the domain now
whois example.com | grep -Ei 'registrar|status|expir|name server'

# Machine-readable, for gTLDs
curl -s https://rdap.org/domain/example.com | jq '{status: .status, events: .events}'

# 2. DNS: delegation and answer agreement
dig +short example.com NS
for t in A AAAA MX TXT CAA; do
  echo "== $t"
  dig +short @8.8.8.8 example.com "$t"
  dig +short @1.1.1.1 example.com "$t"
  dig +short @9.9.9.9 example.com "$t"
done

# 3. Any drift against the snapshot.
# Note: dig cannot take several types in one command — you need a loop,
# otherwise the last type simply overrides the previous ones
for t in SOA NS A AAAA MX TXT CAA SRV DS DNSKEY; do
  echo "== $t"
  dig +noall +answer example.com "$t"
done > zone-after.txt

diff zone-before.txt zone-after.txt

Different public resolvers returning different data means propagation is still in progress — wait. Different authoritative servers returning different data is a configuration error; waiting will not fix it.

Common failures, decoded

Symptom	Likely cause	Check	Fix
Site went down hours after a "successful" transfer	The zone was deleted with the old registrar account; caches expired	dig +short example.com A is empty; dig NS shows new, empty servers	Rebuild the zone from the snapshot at any DNS provider and point NS there
Domain does not open at all, but works for some people	Broken DNSSEC chain: the registry DS still matches the old keys	dig @1.1.1.1 example.com A gives SERVFAIL, +cd returns an answer	Remove the DS at the registrar, wait for its TTL, re-enable DNSSEC afterwards
Site works, incoming email stopped	MX not migrated, or still pointing at the old mail platform	dig +short example.com MX compared with the snapshot	Restore MX from the snapshot, check priorities, send a test message
Outgoing mail lands in spam or bounces	SPF and DKIM TXT records lost while a DMARC policy is still enforced	dig +short example.com TXT, dig +short _dmarc.example.com TXT	Restore SPF and every DKIM selector; temporarily relax DMARC to p=none while fixing
The certificate fails two months later	DNS-01 renewal cannot create _acme-challenge at the new provider	certbot renew --dry-run reports a validation error	Issue new API credentials for the new DNS provider in the ACME client config
Some subdomains do not resolve	Subdomain CNAME and A records never made it into the new zone	Walk the snapshot's names through dig	Add the missing records; reconcile against the subdomain list
Domain quietly expired a year after the move	Auto-renew stayed with the old registrar	whois expiry date; settings in the new panel	Enable auto-renew, attach payment, add external expiry monitoring
An external service (mail, analytics, CDN) disabled features	A domain-ownership TXT record was lost	Compare apex TXT records with the snapshot	Restore the TXT record or repeat the ownership verification

When not to transfer

Technically you can start a transfer any time. Practically there are windows where you should not — not because it will fail, but because the cost of a mistake jumps.

• A week before expiry. The worst possible timing: the request may not complete, the domain lapses, and transfers out of an expired state are usually unavailable. Renew first, transfer later.
• Before a sale, a campaign launch or a seasonal peak. Every campaign points at the domain. Downtime then costs budget, not just minutes.
• Friday evening or the day before a holiday. The deployment rule applies here too: registrar support works business hours, and DNS caches do not respect weekends. Tuesday or Wednesday morning is ideal.
• At the same time as a hosting migration. Two changes at once and you cannot tell which one broke. Separate them by days.
• Before you regain access to the registrant mailbox. Without a working inbox there is nothing to confirm from.
• Right after an owner change. You will most likely hit the transfer lock.
• When nobody is on duty. A migration needs a person who will look at the alerts within the next twenty-four hours. If there is no such person, wait until there is.

The on-call rule: transfer a domain only when you have at least a full day to react and working access to all three panels — losing registrar, gaining registrar and DNS provider. Losing access to any one of them turns a small mistake into a multi-hour outage.

Checklist: before, on the day, after

A week before

1. Decide which of the three jobs you are actually doing: registrar, owner or hosting.
2. Check expiry date, statuses and registrant address in whois.
3. Renew the domain if less than a month remains.
4. Confirm the registrant mailbox is reachable and not hosted on the domain being moved.
5. Take a full zone snapshot into a file and eyeball it for completeness.
6. List every external service that keeps records in your DNS.
7. Find out whether DNSSEC is enabled and plan either disabling it or a coordinated key rollover.
8. Check whether certificate auto-renewal works and how it validates.

One to three days before

1. Build the zone at the new DNS provider, record for record.
2. Lower TTLs at the old provider to 300 seconds, including the negative TTL in the SOA.
3. Diff old and new name server answers until the output is empty.
4. Remove the transfer lock and obtain the authorization code (gTLD) or prepare the documents (ccTLD).
5. Temporarily disable whois privacy if it hides the registrant address.
6. Send test messages both ways and keep the headers as a reference.

On the day

1. Submit the request at the gaining registrar and confirm it by email.
2. Explicitly approve the transfer at the losing registrar instead of waiting for auto-approval.
3. Confirm the gaining registrar did not silently assign its own NS.
4. Switch NS to the new DNS provider — only after a clean diff.
5. Check A, AAAA, MX, TXT and CAA through several public resolvers.
6. Open the site over HTTPS, inspect the certificate and send a test email.

After the move

1. Wait until all public resolvers agree.
2. Diff the "after" snapshot against the "before" one and explain every difference.
3. Enable auto-renew at the new registrar and attach a payment method.
4. Run certbot renew --dry-run or its equivalent and confirm renewal works.
5. Re-enable DNSSEC with the new provider's keys if you disabled it.
6. Do not delete the old zone for at least a week.
7. Restore TTLs to normal values.
8. Set up monitoring: domain expiry, DNS record contents, MX, certificate expiry.

How to check

Everything above can be run from a browser, including on machines with no dig installed.

• WHOIS lookup — registrar, statuses, expiry date, contacts. The first thing to check before and after a transfer.
• DNS record checker — every record type in one place: A, AAAA, MX, TXT, NS, CAA, SRV.
• DNS propagation checker — what resolvers around the world return, so you can see whether delegation has converged.
• MX lookup — where the domain's mail is delivered right now and whether the servers respond.
• Email configuration check — SPF, DKIM and DMARC together, with syntax errors explained.
• SSL certificate check — validity period, chain, covered names, match with the domain.
• Website and domain monitoring — continuous tracking of domain expiry, DNS record drift and certificate expiry, with alerts to Telegram, Slack or email.

A one-off check catches migration mistakes. Monitoring catches what breaks months later: auto-renewal that quietly stopped, a record someone edited, a certificate about to expire.

Frequently asked questions

Will I lose the time I already paid for when I transfer?

No. In gTLDs a transfer normally adds a year to the existing term rather than replacing it. In many ccTLDs a registrar change does not touch the term at all — the paid-until date stays as it was. Either way, paid time is not burned.

Will my site go down during the transfer?

The transfer itself does not touch the site: it changes a registry record, not DNS. Outages happen when you lose the DNS zone along with the registrar, or when the gaining registrar assigns its own empty name servers. Build the zone at an independent provider in advance and there is no downtime.

Do I need to reissue the SSL certificate after changing registrar?

No — the certificate is issued for the domain name and stays valid. What you must check is automatic renewal: with DNS validation it depends on the old DNS provider's API and usually stops working after the move.

Why does my ccTLD registrar not ask for an EPP code?

Because many national registries do not use one. There, a registrar change is initiated by a registrant application with documented identity verification, following registry rules and the registrar's regulations. The authorization code is gTLD machinery.

How long does a domain transfer take?

In gTLDs, from a few hours if you explicitly approve it at the losing registrar, to several days under auto-approval. In ccTLDs the timing follows registry rules. Add DNS convergence on top: minutes to hours with a pre-lowered TTL, up to a day or more with a high one.

Can I transfer a domain if I have lost access to the registrant mailbox?

Restore the contact first. In gTLDs you change it at the current registrar, which may then trigger a temporary transfer prohibition. In ccTLDs changing registrant data goes through identity verification. There is no shortcut — and that is correct, otherwise domains would be stolen by swapping the contact.

What do I do if the domain stopped resolving after the transfer?

Check three things in order. One: dig +short example.com NS — which name servers answer. Two: whether they return real records or the zone is empty. Three: dig example.com A @1.1.1.1 — if it returns SERVFAIL while +cd returns an answer, the cause is DNSSEC and a stale DS in the registry. Rebuilding the zone from a snapshot takes minutes — if you took one.

Should the domain and hosting live with the same company?

Convenient, but it raises coupling: one account holds registration, DNS and the site. When you change providers or fall out with one, you lose all three at once. Splitting registrar, DNS provider and hosting across different companies makes every future migration nearly free.

Check the domain before you move it — registrar, statuses and expiry on the WHOIS page, the full record set on the DNS check page — and after the move add monitoring so you do not hear about an expired domain from your customers.