DNS records hold the website, email delivery and service verifications together, and a host or nameserver change can silently drop them. Export the records, note why each exists, and test mail and the site after every change.

A page of records nobody reads

Somewhere, at your registrar, your host or a separate DNS service, there is a list of records for your domain: twenty or thirty lines of letters, numbers and server names.

Each line was added by somebody, for a reason: the developer who pointed the domain at the website, the contractor who set up Office 365, the agency that verified Search Console, the booking system on a subdomain.

Almost nobody wrote down which line was whose, or why. It all works, so nobody looks.

Until the domain moves, or the website moves to a new host, and the new list contains only the lines somebody thought to copy.

What the records hold together

The fourth is the one most often lost, because nothing breaks the day it goes. A verification record looks like a random string, and some services only check for it again weeks later.

How records go missing

Your DNS is answered by whichever service your domain's nameservers point to. Change the nameservers, and a different list takes over.

That happens more often than people realise. A move to a new host often includes pointing the nameservers at it, and the new host creates a fresh list holding its own website and mail settings, and nothing else.

Every record nobody re-creates there simply stops existing. Nothing warns anybody, because from the new host's side the list looks complete.

Records also disappear in smaller ways: a registrar transfer that left the DNS behind, a developer deleting lines that looked unused, or a DNS service that lapsed on an expired card.

Where your DNS actually lives

The registrar is where the domain is registered and renewed. The DNS may be there, at the host, or with a separate provider, and those are often three different logins.

A web company can tell you in a minute where the nameservers point, and therefore where the records live. The login for that place is the one that matters whenever anything changes.

Export the whole list

Most DNS services and hosting control panels can export every record as a single text file, known as a zone file. Where there is no export, a full screenshot of the records page will do.

Save it with the date in the file name, and keep it somewhere other than the server it describes, alongside the domain's renewal details.

Do it now, while everything works. A copy taken after a problem starts only records the problem.

Write down why each record exists

An export says what the records are. It does not say what they are for, and that is the part that gets lost.

Beside each line, add a few words: the service it supports, who added it and roughly when. Mail delivery for Office 365, added by the IT contractor in 2016. Search Console verification, added by the agency last year.

Records nobody can explain go on a short list of questions for previous suppliers. Leave them in place until somebody knows what they do.

A worked example

A structural engineering firm with two offices changed web hosts in the spring. The developer copied the site, pointed the nameservers at the new host and checked that the pages loaded.

The new host's list held the website and the host's own mail settings. The records for the firm's Office 365 email, set up years earlier by a contractor who had since retired, were not there.

From that afternoon, mail from outside was delivered to a mailbox on the new hosting account that nobody knew existed. Staff noticed the next day, when a contractor phoned about unanswered questions on a set of drawings.

The mail records took minutes to restore once somebody knew what they had been, pieced together from Microsoft's setup pages because the old account had already closed.

The missing SPF and DKIM records took longer to notice. For several weeks, invoices and drawing revisions landed in clients' junk folders.

The firm now keeps an exported copy of its records, with a line beside each saying what it is for, and its web company tests mail after every change.

Check after every change

After any change that touches DNS, whether a new host, a new email provider or a new service, run the same short test.

Load the site with and without www. Send email in from an outside address and out to one, then check the message details: Gmail's show original option says whether SPF, DKIM and DMARC passed.

Confirm that Search Console and any other verified service still show you as verified, and compare the live records with the saved copy, line by line.

Records that point at nothing

The opposite problem is common too: records for services the business stopped using years ago, still pointing at them.

A subdomain left pointing at a cancelled landing page or help desk service can, on some platforms, be claimed by a stranger, who can then publish whatever they like at an address on your domain.

Remove records for services you have definitely cancelled, and note the removal and its date in the same document.

The counter-case

Some domains have little to lose. A simple site with email at the same host may have a handful of records, all created by the host, and a move recreates most of them.

Some DNS services keep a history of changes, which makes recovery easier, and where a web company already documents the records, the owner's part is asking for a copy.

For everyone else: export the records, note why each one exists, and test after every change.

Before the next change

  1. Find where your DNS is actually hosted.
  2. Export every record to a dated file.
  3. Write one line beside each saying why.
  4. Ask previous suppliers about unexplained records.
  5. Remove records for cancelled services.
  6. Keep the copy away from the server.
  7. Test mail and the site after every change.

Step three is what turns a list into documentation. Anybody can export records; only a note saying why each exists lets the next person move the domain without guessing.

The other domains sitting beside your main one, often with records of their own, are covered in domains you own and forgot about.


Frequently asked questions

What do DNS records actually do?

They point your domain at your website, say where your email is delivered, vouch for your outgoing mail, and prove ownership to services such as Google and Microsoft.

Why do DNS records go missing in a move?

Changing nameservers hands your DNS to a new provider, which starts with a fresh list. Any record nobody re-creates there stops existing, usually without any warning.

How do I keep a copy of my DNS records?

Export the zone file from your DNS provider, or screenshot every record on its settings page, and store the dated copy somewhere other than the server.

Should I delete records I do not recognise?

Not until somebody knows what they do. Ask previous suppliers first. Records for services you have definitely cancelled should be removed, and the removal noted.

What should I check after a DNS change?

That the site loads at every version of the address, that mail arrives and sends with SPF and DKIM passing, and that verified services still show as verified.

Who should keep the DNS documentation?

The business, with a copy for whoever maintains the site. Keep it with the domain's renewal details and update it every time a record changes.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Moving host or email soon?

Export your DNS records first. We will document what each one does and check everything still works afterwards.

Start a Conversation