nameserver change checklist: what to record first

A nameserver change tells the internet which servers may answer for your domain. It does not copy the records those servers hold. Before anyone switches them, write down the mail, verification, and vendor records that are not the website, note who can edit DNS, and run one outside test that mail still arrives. That nameserver change checklist is the pre-work, not a launch-day review of the homepage.

What the nameserver change actually moves

Registry operators publish nameserver information for registered domains in the top-level zone. The records on those nameservers are a separate layer. Web-hosting companies manage those DNS resource records, many registrars include that hosting, and the records connect the name to the website and to email. [1]

Pointing the registrar at new nameservers does not move that layer. If the new set is empty, or only has the website address, mail and vendor tools fail for resolvers that have already learned the new delegation. Google says adding new name server records can cause Gmail and other Google Workspace services to fail, and the remedy is to copy the TXT, SPF, MX, and CNAME records onto the new DNS host. [2] A separate Google guide says you must copy all DNS records or the domain will not stay fully functional. MX records are what route the email. [3]

Google also says the domain might redirect to the website immediately, but it can take up to 72 hours, depending on the domain host. [2] While that overlap lasts, some networks still ask the old nameservers. Both sets need the same mail and vendor answers.

NIST's March 2026 DNS deployment guide treats an attack on enterprise DNS as a threat to every network operation, and it frames the job as reducing misuse and misconfiguration. [4] A half-copied zone is that kind of miss.

Who can edit DNS

The registrar is where the domain is registered and where the nameserver hostnames are set. After registration, the registrant manages those settings through the registrar. [5] A reseller can sell the registration, but the registrar remains the accountable party. [1] If a developer or former agency registered the name, write down the registrar of record and confirm the owner can still sign in.

The DNS host is where the zone is edited, and it is often a different company. Google notes that records are typically hosted where the domain was purchased, and that you can move them to another DNS host if you cannot edit them there. Once the nameservers point elsewhere, the old panel no longer changes what the public sees. [3]

Write down the registrar, who can log in, the current nameserver hostnames, and the DNS panel login. If the only person who can export the zone is not answering, stop. We ask for that access list before we ask for the new nameserver names. The owner should still reach both logins.

Mail records to write down

Copy each of these from the live zone, character for character. None of them show up as a page on the site.

MX records. When someone sends you mail, the sender looks up the MX records to decide where to deliver it. [6] Write every MX hostname and its priority. "We use Google" is not a record.

For Google Workspace, the MX value Google documents now is smtp.google.com. If the company started before 2023, the zone may still show older values that begin with aspmx, and Google says those legacy values remain supported when mail is already working. [6] Copy what is published. Do not swap a working aspmx set for the newer record on the same day you change delegation. Incorrect MX records can keep mail from working, and new MX records can take up to 72 hours to be recognized. [6]

For Microsoft 365, copy the tenant-specific MX target the admin center shows. It looks like a token followed by .mail.protection.outlook.com. Microsoft notes that more than one MX can cause delivery problems. When the MX changes so mail goes to Microsoft 365, all email sent to that domain starts coming to Microsoft 365. [7] Also copy Autodiscover if it is present: a CNAME named autodiscover, target autodiscover.outlook.com. [7]

SPF. RFC 7208 (April 2014) says a domain publishes SPF as a DNS TXT record naming the hosts allowed to use that domain in MAIL FROM and HELO. More than one record beginning with v=spf1 is a permanent error. [8] Copy the whole string, including every include and the ending (~all, -all, or whatever is published). If two such TXT records already exist, note them, and do not publish both on the new nameservers.

When Google Workspace is the only sender, Google's current example is v=spf1 include:_spf.google.com ~all. Any other sender belongs in that same record. A sender left out of SPF can have its mail marked as spam. SPF can take up to 48 hours to start working, and each subdomain you send from needs its own SPF record. [9] Microsoft's Exchange Online example is v=spf1 include:spf.protection.outlook.com -all. You can have only one SPF record, the lookups it causes cannot be more than 10, and an existing SPF record should be updated rather than replaced with a second one. [7] [10] Use the string that is live today, not a sample from a help page.

When SPF changes, RFC 7208 says the old policy should stay valid until legitimate mail can reasonably have been checked. [8] During a nameserver overlap, that is why both zones should carry the same SPF text. The same standard says one TXT record can be stored as several strings joined with no added space, so a stray space in a long key becomes part of the record. [8]

DKIM. The 2011 DKIM standard, RFC 6376, says a receiver checks a signature by querying the signer's domain for the public key. Selectors let one domain publish more than one key, and the DNS name is the selector, then ._domainkey, then the domain. [11]

On Google Workspace that public key is a TXT record. The usual name is google._domainkey, and the value looks like v=DKIM1; k=rsa; p= followed by a long key. Copy all of it. DKIM can take up to 48 hours to start working after the key is added, and some hosts limit TXT length. [12] Microsoft 365 often uses CNAMEs instead: selector1._domainkey and selector2._domainkey, with targets from the admin center. [10] An inventory that only grabs TXT records will leave those names behind.

DMARC. RFC 9989 (May 2026) publishes DMARC policy as a DNS TXT record at _dmarc plus the domain. Receivers use it when authentication fails, and the owner can request reports. [13] Google's actions are reject, quarantine, or deliver, and you need SPF, DKIM, or both first or delivery will probably suffer. [14] Copy the existing _dmarc TXT, including the report address. Do not tighten the policy on move day.

Mail to personal Gmail accounts needs SPF or DKIM. Senders of more than 5,000 messages a day also need DMARC. [9] The site can look fine while that mail fails.

Verification records and vendor names

Proof of ownership and vendor tools sit in the same zone, usually as TXT, CNAME, and SRV records that do not point at the website.

Google's verification TXT starts with google-site-verification=. Copy it so the domain stays verified for Workspace, and copy CNAME records for custom addresses such as mail.your-company.com. [2] [15] Copy the value already published. A newly generated token does not replace the one the admin console is checking.

Microsoft requires a TXT record to prove you own the domain, for every customer. The value is generated for that organization. [7] Copy the published text.

Copy TXT records you do not recognize too. A bank, ad account, help desk, certificate vendor, or marketing tool may be proving you control the domain. Label what you know, and keep the rest.

CNAME and SRV records finish the vendor list. Besides Autodiscover and the DKIM names, Microsoft 365 documents CNAMEs named enterpriseregistration and enterpriseenrollment, and a Teams SRV for _sipfederationtls over TCP pointing at sipfed.online.lync.com, with priority, weight, and port. [10] Record those fields as published. Keep the website address records in the export too, but they are not this list.

Copy the zone, then test mail from outside

Keep a spreadsheet outside the DNS panel: host, type, value, priority, purpose, and which company asked for it. Google's move steps say to copy every record type, including A, AAAA, MX, TXT, and CNAME, before you change NS records. [3] Build the new zone first. Read it back and match MX, the single SPF string, every DKIM name, _dmarc, verification TXT records, and vendor CNAME and SRV records. Change the nameservers only after that match.

Before the switch, send one message from a mailbox that is not on this domain to a real company address. Confirm it arrived in the inbox, not only in an unwatched spam folder, and that a reply came back. That round trip is the baseline. It does not prove the new nameservers are right, because public DNS still asks the old servers. To check the copy, query the new nameserver directly for MX, the domain TXT records, _dmarc, and the DKIM name. If MX or SPF is missing there, do not change nameservers.

After the registrar update, repeat that same outside message once. You are checking that mail still arrives, not reviewing the website. Leave the old nameservers up, still serving those mail records, while the change spreads. Google says a nameserver change can take up to 72 hours to redirect the website, and new MX records can take up to 72 hours to be recognized. [2] [6] The SPF transition warning is the same idea for the policy text. [8] If the repeat message does not arrive, the spreadsheet is what you hand back.

Practical takeaways

• A nameserver change moves authority. It does not move the zone. Copy mail, verification, and vendor records before you edit nameservers at the registrar.
• Write down two logins: the registrar that sets the nameservers, and the DNS host that edits the records. They are often different people.
• Record every MX with its priority, one SPF TXT exactly as published, every DKIM name, and the _dmarc TXT. Two records that both start with v=spf1 are an error, not a spare.
• Copy verification TXT records and vendor CNAME and SRV records even when you are not sure which tool they serve.
• Before the switch, send one message from an outside mailbox and confirm the reply. Ask the new nameservers directly and match them to the sheet. Repeat that one outside message after delegation changes, and keep the old nameservers answering through the overlap.

How we can help

Have more questions or want to get in touch? Our team at IDFS AI can sit with you before a host or platform change and turn the live zone into a record inventory a vendor can follow, including the mail and verification names that sit beside the website. Start with our contact page.

Citations

1. ICANN, "FAQs for Registrants: About ICANN" (2019-02-25)
2. Google Workspace Help, "Connect your website to a domain registered through Google" (2026-10-20)
3. Google Workspace Help, "Set up Google Workspace with a third-party DNS host" (2026-10-20)
4. NIST CSRC, "SP 800-81 Rev. 3, Secure Domain Name System (DNS) Deployment Guide" (2026-03-19)
5. ICANN, "Information for Domain Name Registrants" (n.d.)
6. Google Workspace Help, "Set up MX records for Google Workspace" (2026-10-20)
7. Microsoft Learn, "External Domain Name System records for Microsoft 365" (2026-06-26)
8. RFC Editor, "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1" (2014-04)
9. Google Workspace Help, "Set up SPF" (2026-10-20)
10. Microsoft Learn, "Connect your domain by adding DNS records" (2026-08-20)
11. RFC Editor, "DomainKeys Identified Mail (DKIM) Signatures" (2011-09)
12. Google Workspace Help, "Set up DKIM" (2026-10-20)
13. RFC Editor, "Domain-Based Message Authentication, Reporting, and Conformance (DMARC)" (2026-05)
14. Google Workspace Help, "Set up DMARC" (2026-10-20)
15. Google Workspace Help, "TXT record values" (2026-10-20)