A domain and DNS handoff is complete only when the business retains durable authority over the domain registration, the full production DNS zone is accounted for, authorized operators can make and reverse changes, and the website, email, certificates, verification records, and customer journeys work after the transition.

Moving a website does not automatically require transferring the domain to a new registrar. Moving the registration does not automatically move DNS hosting. Changing authoritative nameservers can affect far more than the website. Treat those as separate decisions.

For a safe handoff, prove five outcomes:

  1. the correct business or authorized person is associated with the registration;
  2. the business can recover the registrar and DNS accounts without depending on a departing vendor;
  3. every required DNS record has an identified purpose and owner;
  4. the cutover and rollback are tested across website, email, security, and integrations; and
  5. the outgoing provider's access is removed only after acceptance evidence is complete.

This guide owns that handoff. The contractor website timeline owns when domain work belongs on the project schedule, ongoing website maintenance owns routine control after the transition, and the SEO redesign and migration checklist owns URL, content, redirect, and search migration decisions.

Separate the systems before changing any of them

The word "domain" is often used for several different systems. Record them separately:

| Layer | What it controls | Typical operator | | --- | --- | --- | | Registry | The top-level domain database and its rules | CIRA for .ca; another registry for another top-level domain | | Registrar | Registration, renewal, registrant information, transfer status, and nameserver delegation | An approved domain registrar | | Registrant | The person or organization associated with the registration | The business or another eligible authorized holder | | DNS host | The authoritative zone containing records for the domain | Registrar, hosting company, CDN, managed DNS provider, or another operator | | Web host or CDN | The website origin, edge delivery, redirects, and sometimes certificates | Website or infrastructure provider | | Email provider | Mail routing, sending authorization, signing, and policy | Business email or transactional-email provider | | Certificate system | HTTPS certificate issuance and renewal | Host, CDN, certificate authority, or automation | | Verification consumers | Domain proof used by search, analytics, email, social, and other services | Each connected platform |

One company may operate several layers, but the responsibilities remain distinct. A registrar transfer can leave the existing nameservers untouched. A hosting move can require only an address or alias change. A nameserver change replaces the source of authoritative DNS answers and therefore demands a complete zone migration.

Do not accept "we moved the domain" as an implementation record. State exactly which layer changed.

Establish the business authority record

Create a control record before requesting access or a transfer. Include:

  • exact domain name and top-level domain;
  • registry and registrar;
  • registrant name and organization, at the level the registry permits you to confirm;
  • administrative and security notification addresses;
  • registration and renewal dates;
  • auto-renew state and payment owner;
  • transfer-lock and registry-lock state;
  • registrar account owners and roles;
  • multi-factor authentication method and recovery path;
  • authoritative nameservers and DNS provider;
  • technical operator and business approver; and
  • evidence date.

For .ca, CIRA's rules govern registration, renewal, transfer, modification, suspension, and deletion. They distinguish a change of registrar from a change of registrant. A handoff document should preserve that distinction: changing the company that manages the registration is not the same as changing the person or organization associated with it.

Do not publish authentication codes, recovery codes, private account details, or personal registration data in a project ticket. Store sensitive access through the business's approved credential process. The handoff record can identify where access is controlled without containing the credential itself.

The Canadian Centre for Cyber Security recommends stronger controls against DNS tampering, including multi-factor authentication where available and registrar or registry lock services appropriate to the risk. A lock is a control, not a substitute for account recovery or current contact information.

Decide whether a registrar transfer is necessary

Use the smallest change that achieves the approved outcome.

Keep the registrar and change only website records

This is often appropriate when the business already controls a suitable registrar and DNS provider. Update the minimum records needed to point the website or CDN at the new infrastructure. Preserve every unrelated service.

Keep the registrar and change authoritative DNS

This may be appropriate when a new DNS provider offers required operational, security, or delivery capabilities. It is a full zone migration even though the registrar stays the same. The new zone must be complete before the nameserver delegation changes.

Transfer the registration and keep the nameservers

This can consolidate billing or return registrar control to the business without changing live DNS. Confirm that the transfer will preserve the current nameserver delegation and that the existing DNS service remains active and paid independently.

Transfer the registration and change DNS or hosting

This combines multiple failure boundaries. Separate the work into controlled stages unless there is a documented reason not to. A website launch is easier to diagnose when registration, nameservers, and web origin are not all changed at once.

For generic top-level domains covered by ICANN policy, an Auth-Code is used in an inter-registrar transfer. ICANN's current transfer policy includes conditions around transfer-prohibited status, AuthInfo codes, and certain transfer locks. For .ca, use CIRA's current rules and the processes of the certified registrars involved. Do not assume the exact process for .com applies to .ca, or vice versa.

Before transferring, confirm eligibility, lock state, authorization path, current contact channels, renewal proximity, DNS continuity, and the new registrar's process. Do not expose the authorization code in screenshots or shared notes.

Inventory the entire live DNS zone

An exported zone or provider import is a starting point, not proof of completeness. Build an inventory from the current authoritative answers, provider configuration, connected-service documentation, and business owners.

Record each entry with:

  • record type;
  • full hostname;
  • value or target;
  • priority where applicable;
  • TTL;
  • proxy or routing mode where the provider has one;
  • purpose;
  • dependent system;
  • business and technical owner;
  • source of truth;
  • whether it must exist before cutover; and
  • acceptance query or transaction.

Common records include:

| Record | Typical responsibility | Handoff question | | --- | --- | --- | | A and AAAA | Point a name to IPv4 or IPv6 addresses | Is the destination still correct and serving the intended host? | | CNAME | Aliases one hostname to another | Is the target controlled, valid, and permitted at that name? | | MX | Routes inbound email | Will every business mailbox continue receiving mail? | | TXT | Holds verification and policy values | Which service created it, and can it be removed safely? | | CAA | Constrains certificate authorities where used | Can the intended certificate system still issue? | | SRV | Locates some communications or application services | Which application depends on its priority, weight, port, and target? | | NS | Delegates authoritative service | Does the registrar delegation match the approved DNS provider? | | DS and DNSKEY | Establish DNSSEC authentication | Is the parent-child chain coordinated for the migration? |

Cloudflare's DNS migration guidance warns that automated scans can miss records and tells operators to review and add missing entries before changing nameservers. The same caution applies regardless of provider. A record with an unfamiliar name may support email, certificate issuance, a CRM, a customer portal, or account verification. Investigate before deleting it.

Capture wildcard records, delegated subdomains, and records created automatically by another platform. Check whether an application relies on provider-specific proxying or flattening behaviour that will not reproduce at another DNS host.

Preserve email and verification dependencies

A website handoff can break email even when the homepage loads correctly.

Protect at least:

  • inbound mail routing through MX records;
  • addresses used by the mail targets;
  • sending authorization such as SPF records;
  • DKIM selectors published by approved senders;
  • DMARC policy and reporting addresses;
  • autodiscovery or client-configuration records;
  • transactional-email provider verification;
  • support, CRM, calendar, and help-desk records; and
  • domain-verification tokens used by search, analytics, advertising, social, and software services.

Google Workspace's DNS guidance illustrates why a zone can contain MX, CNAME, and TXT records for different purposes, including domain verification and email security. Do not rewrite email authentication merely to make the zone look tidy. Have the email administrator confirm the current senders and required records.

An SPF policy should not be split into multiple competing records for the same name. A copied DKIM record is useful only while the corresponding sender and private signing key remain valid. A DMARC policy can affect legitimate delivery if the sending inventory is incomplete. This handoff is about preservation and ownership; changes to mail policy require their own evidence and approval.

Test both incoming and outgoing mail with controlled accounts after a DNS change. A lookup showing an MX value does not prove mailbox receipt, sender authentication, forwarding, or replies.

Treat DNSSEC as a coordinated migration

DNSSEC allows validating resolvers to authenticate DNS data through a chain of trust. RFC 4033 describes the security extensions. A migration must coordinate parent-side DS data with the child zone's signing keys; the responsible providers depend on the domain and its setup.

Before changing authoritative nameservers, determine whether a DS record exists at the parent and whether the current zone is signed. Record:

  • current DNSSEC state;
  • current DS data at the registrar or registry;
  • current DNSKEY data at the authoritative provider;
  • old and new provider capabilities;
  • approved migration method;
  • timing based on relevant TTLs;
  • validation checks; and
  • rollback method.

Do not copy an old DS value blindly to a provider using different signing keys. Cloudflare's DNSSEC migration documentation warns that changing nameservers while cached parent DS data points to unmatched keys can cause validating resolvers to return SERVFAIL.

The correct sequence depends on the providers' capabilities. Some support coordinated multi-signer migration. Others require removal of the old chain, waiting for it to expire, changing delegation, and enabling the new chain afterward. Follow the current provider and registry instructions for the actual domain. Do not improvise a universal sequence from a generic checklist.

Validate with DNSSEC-aware queries before and after the change. A normal lookup from one local network may succeed through a stale cache or a non-validating path while other users receive failures.

Plan TTLs without promising instant propagation

TTL tells caches how long a DNS answer may be reused. Lowering an appropriate record's TTL in advance can shorten the period during which cached old answers remain, but it does not make every resolver update at the same moment.

Google's hosting-move guidance recommends considering a conservative lower TTL before a DNS-based infrastructure move and doing so early enough for existing cached values to expire. Use that as planning guidance, not a guarantee.

For each changed record:

  1. record the current TTL;
  2. decide whether lowering it is useful and operationally acceptable;
  3. make the TTL change early enough for the previous value to age out;
  4. record the intended new value and cutover time;
  5. retain the old service while valid caches may still point to it; and
  6. restore the normal TTL after the new state is stable.

Negative answers and DNS resolution failures can also be cached. RFC 9520 updates requirements for negative caching, including DNSSEC validation failures. If a missing record or broken DNSSEC state is briefly published, correcting it does not force every resolver to forget the failure immediately.

Avoid claiming that a change will "propagate worldwide in exactly 24 hours." Observe authoritative answers, recursive resolvers, service traffic, and the relevant cache windows.

Build a cutover runbook

The runbook should identify the exact change, operator, approver, evidence, timing, communication path, and rollback trigger.

Include:

  • release or change identifier;
  • domain and affected hostnames;
  • systems that are changing and systems that must remain untouched;
  • current and proposed records or nameservers;
  • exported and independently reviewed zone inventory;
  • current TTL and preparation date;
  • DNSSEC state and approved sequence;
  • old and new hosting readiness;
  • certificate readiness for every public hostname;
  • email and third-party dependencies;
  • monitoring views;
  • customer-facing fallback;
  • rollback values and authorized operator;
  • stop conditions; and
  • acceptance owner.

Stage the new DNS zone and infrastructure before changing delegation. Test the new web origin with a temporary controlled hostname or local host mapping where safe. Keep test hosts from becoming unintended search destinations. Confirm that the application knows the final public host and serves the intended canonical, redirects, cookies, and security policies.

Do not schedule the change when the people required for registrar recovery, DNS editing, hosting diagnosis, email administration, or rollback are unavailable.

Verify the website as a complete public system

After the change, test from outside the hosting environment and from more than one network or resolver where practical.

For the website, verify:

  • authoritative nameservers match the approved delegation;
  • apex and www resolve as intended;
  • IPv4 and IPv6 behaviour are both correct when published;
  • HTTP variants redirect directly to the preferred HTTPS host;
  • certificates are valid for every public hostname;
  • canonical pages return the intended statuses;
  • titles, H1s, canonicals, robots directives, and structured data survived;
  • forms, calendars, chat, calls, and CRM handoffs work;
  • static assets and media load without mixed hosts or old origins;
  • unknown routes return a truthful error state; and
  • the old environment is not receiving traffic that still requires service.

Google's hosting-change guidance recommends monitoring old and new server traffic and retaining the old infrastructure until traffic has moved and the new service is working correctly. The same evidence helps distinguish cached DNS traffic from an application fault.

If URLs also changed, this is no longer only a DNS handoff. Use the canonical and redirect decision guide and the full redesign migration plan.

Test email and connected services separately

Run controlled transactions instead of relying only on DNS lookups.

Test:

  • inbound mail from an external provider;
  • outbound mail to an external provider;
  • reply flow;
  • required aliases or forwarding;
  • SPF, DKIM, and DMARC results for authorized senders;
  • transactional confirmations from forms, CRM, and calendars;
  • password-reset and security-notification delivery;
  • vendor domain verification;
  • search-console and analytics verification where DNS records are used;
  • certificate renewal or validation path where applicable; and
  • delegated subdomains and application-specific services.

Record the test identity, time, expected result, actual result, and evidence location without retaining message content or personal data that the acceptance record does not need.

A successful website test cannot substitute for these checks. DNS is a shared control plane for many services.

Define rollback by layer

"Change it back" is not a sufficient rollback plan.

For each layer, record the reversible action:

| Layer | Possible rollback requirement | | --- | --- | | Web record | Restore the old address or alias while the old origin remains healthy | | Nameserver delegation | Restore the previous authoritative nameservers only if the old zone still exists and DNSSEC state is compatible | | DNSSEC | Restore or remove DS data according to the approved provider sequence and cache state | | Registrar transfer | Recognize that policy or registry locks may prevent an immediate transfer back; do not use registrar reversal as an incident response plan | | Email | Restore the approved mail records and verify real delivery | | Certificate | Keep a valid issuance or serving path for every public hostname |

Define stop conditions before cutover. Examples include widespread DNSSEC validation failure, certificate failure on the primary host, material mail interruption, an incomplete authoritative zone, or loss of administrative access.

Rollback can also take time because old and new answers may remain cached. Keep both environments able to handle traffic for the planned transition window when practical.

Create a domain handoff acceptance register

The following Nexxen register is an original operational framework, not a statement that one record or tool proves ownership in every legal or registry context.

| Field | Required evidence | | --- | --- | | Domain identity | Exact domain, registry, registrar, registrant record, and evidence date | | Business authority | Named approver, account role, recovery owner, and secure credential location | | Renewal | Expiry, auto-renew state, payment owner, and notification route | | Security | MFA, lock status, security contacts, and change approval path | | DNS authority | Delegated nameservers, DNS provider, zone owner, and export location | | Zone inventory | Every record, purpose, dependency, TTL, and acceptance check | | DNSSEC | DS/DNSKEY state, migration sequence, validator result, and rollback | | Change scope | Registrar, nameservers, individual records, hosting, or combined move | | Cutover | Change ID, operator, timestamp, values changed, and monitoring | | Website acceptance | Resolution, HTTPS, redirects, content, SEO surfaces, and journeys | | Service acceptance | Email, verification, certificates, integrations, and delegated names | | Residual traffic | Old-provider traffic and retirement decision | | Offboarding | Removed users, retained business access, exports, and completion approval |

Mark unknown facts as unresolved. Do not guess the registrant, mail owner, or purpose of a record from its name.

Complete offboarding only after acceptance

Once the change is stable:

  • restore approved long-term TTLs;
  • confirm renewal and payment ownership;
  • enable or restore appropriate locks;
  • confirm business-held recovery access;
  • export the accepted DNS zone and control register;
  • preserve the cutover and test evidence;
  • remove temporary credentials and access;
  • remove the outgoing provider's users and API tokens when authorized;
  • cancel old DNS or hosting only after residual use is understood;
  • update the maintenance and incident contacts; and
  • schedule a future access and renewal review.

Do not delete the old DNS zone merely because the new nameservers appear in the registrar dashboard. Confirm that caches, delegated subdomains, old infrastructure traffic, certificate processes, and connected services no longer depend on it.

An outgoing provider should not remain the only recovery contact. An incoming provider should not become the registrant by default. The durable outcome is business control with explicitly delegated operational access.

Run the handoff checklist

Authority and access

  • [ ] Registry, registrar, registrant, DNS provider, host, and email provider are identified separately.
  • [ ] The business has durable registrar and DNS recovery access.
  • [ ] Registrant and administrative information has been reviewed through the appropriate private process.
  • [ ] Renewal, payment, notices, MFA, and lock ownership are assigned.
  • [ ] Sensitive codes and personal data are absent from ordinary project records.

Change design

  • [ ] The team decided whether the change is registrar, nameserver, record, hosting, or combined.
  • [ ] A registrar transfer is justified rather than assumed.
  • [ ] Transfer eligibility and current registry rules were checked.
  • [ ] The full authoritative zone was inventoried and reviewed.
  • [ ] Email, verification, certificates, integrations, wildcards, and delegated subdomains are accounted for.
  • [ ] DNSSEC has an approved provider-specific sequence.
  • [ ] TTL changes were planned early enough to be useful.

Cutover and acceptance

  • [ ] New DNS and infrastructure were staged before delegation changed.
  • [ ] Authorized operators and approvers were available.
  • [ ] Rollback values and stop conditions were written.
  • [ ] Authoritative and recursive DNS results were checked.
  • [ ] Website, HTTPS, redirects, SEO surfaces, and customer journeys passed.
  • [ ] Email and connected services passed controlled transaction tests.
  • [ ] Old and new infrastructure traffic was monitored.
  • [ ] Residual uncertainty and follow-up owners were recorded.

Completion

  • [ ] Long-term TTL and lock states were restored as approved.
  • [ ] Final zone and control records were exported.
  • [ ] Business recovery access was retested.
  • [ ] Temporary and outgoing-provider access was removed when authorized.
  • [ ] Old services were retired only after dependency checks.
  • [ ] Renewal and access reviews were scheduled.

Make control testable

The safest domain handoff is not the one with the most accounts under one vendor. It is the one the business can understand, recover, operate, verify, and move again without losing a critical service.

Separate registration from DNS and hosting. Preserve the whole zone. Coordinate DNSSEC. Treat cached answers as part of the change. Test website and email independently. Keep a layer-specific rollback path. Then close the outgoing access only after the business has accepted the evidence.

For Canadian businesses that need domain, DNS, hosting, website, and integration responsibilities designed as one maintainable system, Nexxen's website development services are the commercial owner for this resource.