A domain can show its new website perfectly while invoices, password resets and customer replies stop arriving. The mistake is treating a nameserver change as a website setting. This practical worksheet is for a small business moving DNS to a new provider while keeping its existing mailbox service. It is an operational plan, not a promise of uninterrupted delivery. The examples use the reserved name example.com; substitute your own domain and provider-issued values. DEFINE WHAT IS MOVING Write down three separate services: the registrar holding the domain, the provider answering authoritative DNS queries, and the company hosting mailboxes. For this migration, change only the second. Keep the website host, mailbox subscription and outbound sending services unchanged. If a colleague also wants to move mailboxes, give that a separate project and date. Separating these changes makes it possible to identify the cause of a failure instead of investigating several migrations at once. BUILD AN INVENTORY BEFORE TOUCHING NAMESERVERS Export the current zone and keep a readable copy beside the export. Create a worksheet with name, type, value, priority, TTL, purpose, service owner and verification result. Include the root name, www, mail, autodiscover, DKIM selectors, _dmarc and all verification records. Add records belonging to a CRM, invoicing tool or support desk even if nobody remembers setting them up. Ask the person responsible for each tool whether it still sends messages using your domain. MX records identify mail exchangers; TXT records can publish mail policies. SPF, DKIM and DMARC have different roles, so preserving one does not replace the others. Their specifications are linked below. In the worksheet, record the actual existing values rather than copying a generic configuration from a tutorial. Never publish an additional competing SPF policy merely because the new DNS dashboard suggests one. REHEARSE THE NEW ZONE Create the zone at the destination and compare it with the inventory row by row. Automatic discovery is a starting point, not acceptance evidence. For a fictitious example, sales@example.com stays at the same mailbox provider: its MX priorities and destinations should therefore remain the same. The website’s A record can remain the same too. A nameserver migration does not require inventing new mail or web addresses. Query each new authoritative server directly before changing delegation. Save the results for MX, the root TXT record, _dmarc and every active DKIM selector. Use a command such as dig @NEW_NAMESERVER example.com MX, replacing the placeholder with the assigned server. Compare complete values, not just whether a record exists. A missing selector may affect only one sender, which makes a casual test misleading. Choose a quiet change window and designate one person to execute it. Record the previous nameservers and the destination zone identifier in the same change ticket. If you plan to lower TTLs, do so beforehand and allow the previous TTL to elapse; changing a value at the last minute is not an instant cache flush. Set a rollback decision time and specify who can authorize it. HANDLE DNSSEC AS A SEPARATE CHECKPOINT If DNSSEC is enabled, inspect the existing DS information and follow the receiving provider’s migration procedure. Do not leave a parent-side DS record referring to a key the new zone cannot use. Cloudflare’s full-setup documentation discusses this dependency. A signed-zone migration deserves an explicit DNSSEC step in the ticket rather than an assumption that the nameserver form handles everything. TEST THE CUSTOMER JOURNEY, NOT ONLY THE WEBSITE Before and after the change, send a uniquely labelled message from an outside mailbox to a real business address and reply to it. Repeat with a second external provider. Then trigger a password reset, a support notification and a sample invoice from the tools listed in your inventory. Use test customers and non-sensitive content. Write down which message was expected, whether it arrived and whether its headers show the intended authentication results. If the website works but inbound mail fails, start with MX and the receiving mailbox service. If only CRM messages fail, compare that sender’s authentication records and logs. If one network fails while another works, compare DNS answers before changing application settings. This decision tree is a troubleshooting proposal; it narrows the investigation but does not prove the cause on its own. CLOSE THE MIGRATION WITH EVIDENCE Keep both DNS services available during the agreed observation window. Avoid unrelated edits while results are being collected. Close the ticket only when the inventory comparison, outside-mail tests and business-tool checks have named owners and recorded outcomes. Save the final zone export, timestamp and outstanding exceptions. That small record is more useful during the next migration than a screenshot saying the domain is active. Planning a new brand? Compare names in the DomainEvery catalogue: https://domainevery.com/en/domains, then include email and DNS ownership in the launch checklist. PRIMARY SOURCES Cloudflare: changing nameservers: https://developers.cloudflare.com/dns/zone-setups/full-setup/setup/; Cloudflare: email records: https://developers.cloudflare.com/dns/manage-dns-records/how-to/email-records/; DNS record formats, RFC 1035: https://www.rfc-editor.org/rfc/rfc1035.html; SPF, RFC 7208: https://www.rfc-editor.org/rfc/rfc7208; DKIM, RFC 6376: https://www.rfc-editor.org/rfc/rfc6376.html; DMARC, RFC 7489: https://www.rfc-editor.org/rfc/rfc7489.html.