Do DNS records transfer when you transfer a domain?

A domain registration and a DNS zone are separate objects. A registrar records who controls the domain and submits delegation data to the registry. A DNS host answers A, AAAA, MX, TXT, CAA, and the other records in the zone. One company may perform both jobs, which is why a transfer can look as if it moved DNS even when the registration and authority followed different paths.

Do DNS records transfer with domain registration?#

A registrar-to-registrar transfer normally moves the registration. Whether users keep reaching the same DNS data depends on the nameservers delegated at the parent and on whether the old DNS service remains available.

Start with two checks:

# Current delegated authorities
dig +short NS example.com

# Current registrar and domain status
whois example.com

The NS result tells you where resolvers are sent. The registrar result tells you who manages the registration. They do not have to name the same provider. If a transfer workflow requires a nameserver change, treat that as a separate DNS migration even if the UI presents both together.

The three domain-transfer DNS cases#

1. DNS is hosted somewhere other than the losing registrar#

Suppose the registration is at GoDaddy, while the delegation points to Cloudflare, Route 53, or an independent authoritative service. If the transfer leaves that NS set unchanged, DNS resolution continues through the same provider and no zone copy is needed for the registration move.

Confirm rather than assume:

dig +trace example.com NS
dig +norecurse +noall +answer @ns1.dns-host.example example.com MX

Keep the DNS account funded and the zone active. The safe statement is “the same delegated service still answers,” not “the records moved.” Review registrar connections and DNS roles before combining accounts.

2. DNS is hosted by the losing registrar#

This is the dangerous case. The parent can keep delegating to the old registrar’s nameservers while the zone exists there, so the site may work throughout the transfer. That does not guarantee the DNS service survives account closure, product cancellation, a nameserver reset, or a registrar-specific transfer policy.

Ask the losing registrar in writing whether its authoritative DNS remains active after transfer-out and for how long. If the answer is unclear, move DNS first. Export the full control-plane zone, including inactive verification TXT and DKIM selectors; public lookups cannot discover an arbitrary complete zone.

Do not cancel the old account merely because WHOIS shows the gaining registrar. Resolvers may still depend on the delegated old authorities, and the old DNS product may have its own lifecycle.

3. You want to use the gaining registrar’s DNS#

The transfer request does not generally make the gaining registrar’s default nameservers serve an exact copy of the old zone. Create or review the destination zone, recreate every record the import missed, query its assigned nameservers directly, and only then delegate to them.

dig +norecurse +noall +answer @ns1.old.example example.com MX
dig +norecurse +noall +answer @ns1.new.example example.com MX
dig +norecurse +noall +answer @ns1.old.example _dmarc.example.com TXT
dig +norecurse +noall +answer @ns1.new.example _dmarc.example.com TXT

Compare complete RRsets, priorities, alias semantics, CAA, SPF, every DKIM selector, and verification TXT records. The interactive DNS migration checklist covers the full inventory and waiting periods.

What GoDaddy, Namecheap, Cloudflare, and Squarespace document#

Registrar behavior is not interchangeable. These are narrow claims from each provider’s current official help, verified September 27, 2026.

GoDaddy: the registration is not your website or email#

GoDaddy’s transfer-to-GoDaddy guide says only the domain transfers; website and email products do not. Its nameserver guide says changing nameservers also changes where DNS is managed. Together, those statements are a reason not to expect a registration transfer to copy an unrelated DNS zone.

GoDaddy has a specific DNS Hosting workflow: you can create a GoDaddy-hosted zone before changing delegation, and GoDaddy says it will apply that prepared zone if the domain is later transferred to GoDaddy. That is a separately created zone, not proof that arbitrary DNS records accompany every transfer. If GoDaddy is either authority, use the internal GoDaddy DNS setup reference and query the assigned nameservers.

Namecheap: nameservers stay, with a FreeDNS exception#

Namecheap’s official answer to whether nameservers transfer says they remain the same during transfer unless the domain uses Namecheap FreeDNS. For registrar-default DNS, Namecheap advises switching to FreeDNS before transfer; after an inbound transfer, it changes that FreeDNS service to its default nameservers.

Namecheap also warns in its domain transfer procedure that nameservers cannot be updated once a transfer has started, until it completes. Make an urgent DNS-host change before initiating the transfer, or deliberately retain the existing authority. See the Namecheap provider setup reference for DNS access, not transfer assumptions.

Cloudflare Registrar: DNS moves before registration#

Cloudflare documents a different order. Its transfer-in procedure requires you to add the domain to Cloudflare, disable the old DNSSEC delegation, update nameservers to Cloudflare, and wait for the zone to become Active before entering the authorization code. It also states that Cloudflare Registrar domains must use Cloudflare authoritative DNS.

Cloudflare’s scan adds common records but its own guide says the scan is not guaranteed to find every existing record. Review the zone, especially mail and verification data, before delegation. If you later want non-Cloudflare nameservers, Cloudflare’s nameserver documentation says you must transfer the registration out. The Cloudflare DNS connection guide covers scoped source access.

This is a concrete example of registration transfer and DNS migration being separate operations even though Cloudflare requires them in a particular order.

Squarespace and former Google Domains: a documented subset is imported#

Squarespace’s current inbound transfer guide says its pending-transfer DNS panel can display imported MX, TXT, A, CNAME, and SRV records. It tells users to note current settings, compare them, and add missing records after transfer. It specifically says MX records transfer, while its five-type list excludes record types such as CAA, AAAA, NS delegations, and service-specific types. Treat the import as a draft to audit, not a complete zone guarantee. The same guide requires removing DNSSEC before starting an inbound transfer.

The Google Domains event was not a normal customer-initiated registrar transfer. Squarespace’s Google Domains migration notice says it acquired the registrations and associated customer accounts. It also documents a nonportable feature: Google Dynamic DNS stopped updating, while the last supplied addresses remained as static A or AAAA records. If you manage a former Google Domain, check current records and nameservers in Squarespace rather than relying on what the old Google UI showed.

The safe order to transfer a domain and keep DNS records#

There are two safe patterns. Choose one before unlocking the registration.

Keep the current DNS host#

1. Confirm the current NS set at the parent and query every authority.
2. Confirm the DNS contract and account continue after registration transfer.
3. Leave nameservers unchanged during transfer.
4. Verify parent delegation, web, mail, and DNSSEC after completion.
5. Keep monitoring; no records were copied because none needed to move.

This is the smallest change when DNS is independent of the registrar. Namecheap’s documented nameserver continuity supports it, subject to its FreeDNS exception. Do not use this pattern where the gaining registrar mandates its own DNS, as Cloudflare does.

Move DNS before the registrar transfer#

1. Export the complete zone from the losing DNS host.
2. Create the destination zone and translate provider-only behavior.
3. Compare old and new authorities record by record.
4. Handle DNSSEC in the correct order.
5. Change nameservers and keep both providers serving for the parent NS TTL.
6. Verify recursive, web, mail, and certificate behavior.
7. Start the registration transfer only when the new DNS path is stable.

This sequence isolates failures. If the zone comparison is wrong, you can fix DNS before adding registrar status, transfer locks, authorization emails, and billing to the incident. Read how to migrate DNS without downtime and use the DNS record diff tool during preparation.

DNSSEC during a domain transfer#

If nameservers and the DNS operator remain unchanged, the child can keep publishing the same DNSKEY and signatures. But the DS lives in the parent and is managed through the registrar, so you must verify that the gaining registrar and TLD preserve or accept the required DS data. Do not assume the DNSSEC control state follows merely because the NS set did.

If the DNS operator changes, use a coordinated multi-signer transition or an intentionally insecure transition. For a normal non-coordinated move: remove the old DS while the old signed zone still answers, confirm removal at the parent, wait the old DS TTL, change nameservers, then sign at the destination and publish its DS. RFC 6781 section 4.3.5 describes DNS-operator changes, and the DNSSEC migration checker inspects the live chain.

Provider transfer rules still apply. Cloudflare and Squarespace explicitly instruct inbound-transfer users to disable or remove old DNSSEC first. Follow the actual gaining registrar’s current procedure rather than a generic registrar checklist.

How DNSMigrator helps before the transfer#

DNSMigrator treats DNS movement as zone data and behavior, not as a side effect of registration:

• It reads a source through a provider connection or BIND zone file, normalizes RRsets, translates them for the chosen destination, reads an existing destination zone, and previews create, update, and delete operations.
• After a preview, it can export the translated desired state as a BIND zone file. The export header notes that unsupported records are omitted and directs you to the migration report, so the file is not presented as silent lossless conversion.
• Before apply, it reads and snapshots the live destination and recalculates the create, update, and delete plan. If the operation keys differ from the preview, the timeline records that the destination changed; apply then writes the fresh plan.
• After apply, it queries the destination’s own authoritative nameservers and compares the intended RRsets. Verification failure leaves the migration applied for review; it does not claim that registrar state fixed the records.
• Rollback reverses only applied values that still match what the migration wrote. A record edited afterward is left in place rather than overwritten.

Those behaviors are implemented in the migration preview, apply, verify, export, and rollback handlers. You can also run the public DNS migration checker before providing credentials.

Verify after both changes#

After the DNS move, confirm the parent NS set, direct authoritative answers, recursive observations, HTTPS, incoming and outgoing email, CAA, certificate renewal, and DNSSEC. After the registrar transfer, repeat the parent NS and DS checks in case the gaining workflow changed either one.

Keep timestamped exports from both sides. “The website loads” does not verify MX priorities, DKIM selectors, _dmarc, _acme-challenge, or delegated subdomains, and it does not prove that a resolver with an older delegation has a working authority.