Define what is actually moving
Transferring a domain to a new registrar, changing authoritative nameservers, moving the website and changing mail providers are different jobs. Write down which ones are in scope. A website hosting migration does not automatically require moving email.
Our recommended handover starts with four lines: domain administration, DNS, website and email. Each needs the previous provider, the new provider, a responsible person and the required access. This turns “we are moving the domain” into a specific set of changes. It also helps the incoming supplier distinguish what they own from what must remain untouched.
Capture the inventory
Record names, values, TTLs, services and responsible owners.
Switch the targets
Make the agreed changes and verify the operational services.
Close the old setup
Clean up references and access before releasing old resources.
A verifiable new state
New targets are confirmed, required mail services remain intact and retired services leave no unintended references.
A working model for a controlled change. Approve the inventory, cutover and decommissioning separately.
Preserve mail and other dependencies explicitly
Reconcile any automatic DNS import with the existing inventory. Cloudflare advises reviewing records for the services in use and confirming mail values with the relevant provider.
Save the old zone before changing it and assign unexplained records to someone for investigation. A new agency should not have to guess whether an opaque TXT value is still required. Ask the responsible person for an evidenced decision. “Unknown” is not sufficient justification for deleting a record. [1]
Swipe or scroll sideways to read the table.
| Record or area | Question before the move | Acceptance check |
|---|---|---|
| Website A, AAAA and CNAME | Which names should point to the new website? | Check the main address, www and agreed subdomains. |
| MX and mail target names | Will the existing mail provider remain? | Confirm receiving and sending with authorised tests. |
| SPF, DKIM and DMARC | Which active sending services require these values? | Review domain authentication for each sending route. |
| Service and verification values | Which service and account owns each value? | Retain, replace or remove with a documented reason. |
| DNSSEC and delegation | Are nameservers or signing keys changing? | Check resolution and the chain of trust separately. |
A short TTL is not a migration plan
TTL describes how long a DNS answer may be cached. Lowering it later does not retrospectively clear answers that have already been stored.
Planning example, not a universal waiting period: a record previously uses 3,600 seconds and will use 300 seconds. Lowering it at the instant of cutover has not removed the previous hour of possible caching. Schedule the reduction in advance and keep the old service available for an agreed overlap. Other cache layers, nameserver delegation and DNSSEC can have their own timing considerations. Record the actual values instead of assuming one waiting period applies to everything. [2]
Do not leave old subdomains pointing at released services
A DNS reference to a retired resource that someone else can claim may enable subdomain takeover. A target that fails to resolve is not, by itself, proof that takeover is possible.
For each retiring service, record the name, target, previous account, owner and decommissioning decision. Change or remove the reference in a controlled way, account for remaining cache lifetimes, then release the old resource. Check links in applications and documents afterwards. Take care not to disable a replacement service that legitimately uses the same name. [3]
Include DNSSEC in the change plan
When nameservers change, the parent zone’s DS record must remain consistent with the DNSSEC keys. An outdated chain of trust can cause validating resolvers to return SERVFAIL.
Ask the DNS owner to plan the specific migration. Some providers support coordinated moves with signing active. Otherwise, time any disabling and re-enabling as part of the same change. Leaving DNSSEC permanently disabled is not a satisfactory completion step. If only the website host changes, with no DNS operator or signing-key change, first establish whether the chain of trust needs changing at all. [4] [5]
Close the migration after acceptance
A screenshot of the new homepage is only one part of acceptance. Agree a review time, an owner and a rollback route. The record should say what was checked and what remains unresolved. An email test that has not been carried out must remain open.
- Compare the DNS inventory before and after the change.
- Open the website, www, redirects and agreed subdomains.
- Document authorised mail tests and sender authentication.
- Check DNSSEC and delegation where affected.
- Remove old references, then release unused resources in a controlled sequence.
- Revoke unnecessary agency access and API keys.
- Record the new owners and a follow-up review date.
DNS migration handover worksheet
Keep a shared record of the migration. The CSV worksheet covers the website, email, verification records and DNSSEC. Add a separate row for every DNS record actually in use. The worksheet contains no test results and does not run queries or change settings.
Take current and planned values from the relevant provider accounts. Record approval, the expected result and the evidence actually obtained. A test that has not been carried out remains open; a short TTL or a working homepage does not replace acceptance of the whole change.
Keep the completed file in your own protected storage. Do not enter passwords, API keys or other credentials. Infrastructure details should not be submitted through the public contact form. [1] [2] [3] [5]
Swipe or scroll sideways to read the table.
| Area | Record before the change | Evidence after the change |
|---|---|---|
| Website and www | Names, old and planned targets, responsible owners | Availability and agreed redirects |
| MX and SPF, DKIM and DMARC for each sending route | Authorised receiving and sending tests; sender authentication | |
| Other services | Purpose and responsible account for each verification record | Confirmed decision to retain, change or remove |
| DNSSEC and retired services | Delegation, affected keys, retirement and rollback plan | Consistent resolution; controlled cleanup of old references |
Email stopped arriving after a nameserver change?
First establish whether receiving, sending or only one sending service is affected. Record the time and exact error. Compare the new authoritative DNS zone with the saved inventory and your mail provider’s requirements.
Avoid changing several protections on suspicion. Delivery problems are not a reason to disable DMARC broadly or delete unexplained records. Record the cause, targeted correction and observed outcome separately. [1] [2] [4] [5]
Swipe or scroll sideways to read the table.
| Observation | Check first | Then establish |
|---|---|---|
| Website loads, incoming mail is missing | Are MX records and their target names correct in the active zone? | Check an authorised receiving test and provider status. |
| Mail arrives but authentication fails | Do SPF and DKIM match the affected sending service? | Inspect original headers for SPF, DKIM and DMARC alignment. |
| DNS returns SERVFAIL | Do delegation, DS records and DNSSEC signatures agree? | Check the chain of trust; waiting for caches is not a diagnosis. |
| Only some networks see old values | Distinguish authoritative answers from cached answers. | Record the TTL, query time and resolver. |