Changing your registrar or DNS provider (without breaking anything)

A registrar transfer, a DNS-provider change, and a record edit are three different moves — and most domain breakage comes from making one while thinking you're making another. The registrar is the company responsible for your registration at the registry (though you may buy through a reseller); the DNS provider runs the authoritative nameservers that publish your records; the records direct the individual services. In principle you can change any one of the three without touching the other two — but bundled services create dependencies, and that's exactly where the breakage hides.

The three moves, and what each one changes

• Transferring the domain means changing registrars: who manages the registration, where you log in, who talks to the registry for you. The existing nameserver delegation normally stays unchanged, so the same DNS provider keeps answering — the records are not copied to the new registrar; they stay where they always were.
• Changing DNS providers means changing the nameserver delegation (the NS records at the registry): who publishes your zone. The registrar relationship stays as it was.
• Editing records means re-pointing individual services — website, mail — at your existing DNS provider. This is the everyday case, covered in connect your domain to an external service.

Rule of thumb: a new website builder or mail provider needs records. It almost never needs new nameservers, and it never needs a registrar transfer. Do the smallest move that solves your problem.

Transferring to a new registrar

The sequence is standard: confirm your business is the registered holder with current contact details (see who controls your accounts), switch off the transfer lock, and obtain the transfer code using the procedure for your extension — for generic domains usually from the current registrar's control panel or support; for .be, DNS Belgium emails it to the current holder's registered address. Then start the transfer at the new registrar.

Worth knowing before you schedule it:

• Generic domains under ICANN's transfer policy normally can't be transferred in the first 60 days after registration or after a previous transfer, and a change of holder can trigger a further 60-day lock (some registrars let you opt out before making the change). A successful generic-domain transfer normally adds a year to the registration, up to the applicable maximum. Country-code registries follow their own rules — a .be transfer with a valid code completes within hours.
• The classic trap: bundled DNS. The domain stays live during a transfer because the delegation doesn't change — unless the old registrar was also your DNS provider and cancels the zone when you leave. Ask the old registrar explicitly whether its DNS keeps answering after a transfer away, and for how long; don't assume "free DNS" survives the registration leaving. If it's bundled, set the zone up elsewhere and re-delegate before transferring.
• One move at a time. Don't transfer registrars and change DNS providers on the same day. Complete and verify one change before starting the other — then a failure has one possible cause instead of two.

Changing DNS providers: copy everything first

Re-delegating to a provider whose zone is empty takes everything down at once, so the zone comes first:

1. Export or document the complete zone at the old provider — every A/AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC, verifications), CAA and subdomain record. The ones people forget are the invisible ones: DKIM selector records, verification TXTs, the one subdomain the booking system uses.
2. Don't assume the export holds everything. Provider-specific features — apex aliases (ALIAS/flattening), URL forwarding, geo-routing or failover rules, provider-managed DKIM, dynamically generated records, wildcard behavior — may not appear as ordinary records at all. Reproduce their behavior at the new provider, not merely the visible record text; this is how a side-by-side comparison can look identical and still behave differently.
3. Re-delegate — change the NS records at the registrar — and then leave the old provider's zone running unchanged. Cached delegations are governed by TTLs in the parent zone, often hours or longer, and you can't lower those from your DNS panel — dropping the TTL on your website or MX records does nothing to speed up a nameserver change. Keep the old nameservers serving the same zone until lookups consistently show the new delegation; several days of overlap is cheap insurance.

Using nameservers inside your own domain (such as ns1.yourdomain.tld)? The registry then holds separate host ("glue") records with their IP addresses, and those may need updating during the move too — changing the zone's A/AAAA records alone isn't enough.

DNSSEC needs its own plan

If your domain is signed, the registry holds a DS record that points at your current provider's keys. Re-delegate without dealing with it and validating resolvers will reject the entire domain as forged — the stale-DS trap from tip 2. The safe small-business sequence is unsign, move, re-sign — in this order:

1. Remove the DS record at the registry (through your registrar) while the old signed zone keeps serving.
2. Wait until the parent no longer publishes the DS and validators' caches have let it expire (at least its TTL).
3. Re-delegate to the new provider while the old one still answers.
4. Enable signing at the new provider and confirm its nameservers serve valid DNSKEY and signature records.
5. Only then publish the new DS record — a DS that appears before the matching keys are reliably served breaks the domain just like a stale one.

Coordinated handovers that keep DNSSEC unbroken throughout do exist (multi-signer setups), but they need both providers' active cooperation. When in doubt: unsign, move, re-sign.

Verify, then decommission

Query every old and new authoritative nameserver directly and compare answers: the apex and www (A and AAAA), MX records and priorities, SPF, DKIM selectors, DMARC, CAA, verification records, wildcards and your important subdomains — and confirm the new servers answer authoritatively and consistently. If the domain is signed, confirm validation passes. Check HTTPS still works on the apex and www.

For mail: test inbound and outbound with an external mailbox — including the website contact form and other automated senders — and read the received headers for aligned SPF or DKIM and a DMARC pass. Give it a few days of normal operation; then, and only then, cancel the old service and remove leftover records.

Three different moves, one shared rule: keep the old setup working until the new one has been tested and proven — never dismantle the bridge before you've crossed it.

What to do

1. Name the move you're making — transfer, re-delegation, or record edit — and pick the smallest one that solves the problem.
2. Before a transfer: confirm the holder and current contact details, unlock, and get the transfer code via your extension's procedure.
3. Check whether your DNS is bundled with the old registrar — ask explicitly what happens to it after a transfer — and never combine a transfer and a DNS move in one step.
4. Before re-delegating: reproduce the complete zone and the provider-specific behavior, then compare against the old setup.
5. If the domain is signed: unsign first, and publish the new DS only after the new provider's keys are demonstrably live.
6. Keep the old provider answering until lookups consistently show the new setup and every check passes; clean up afterwards.