The DNS records that are not about the website

Open a client's zone and count. Twenty-odd entries, of which an A record, a www CNAME and possibly an AAAA are the website. Everything else is doing something for a system you did not install, and most of it fails in a way that takes weeks to notice.

Which is the useful way to organise the record types: not alphabetically, but by how long the damage stays invisible.

The website rows are the top two. Everything below them is where an agency loses time, precisely because the feedback loop is long enough that the change and the symptom are never in the same conversation.

CAA, the record that makes a renewal fail six weeks later

A CAA record names which certificate authorities are permitted to issue for the domain. Authorities are required to check it before issuing, and to refuse if they are not on the list.

dig +short example.com CAA
0 issue "letsencrypt.org"

That is a useful record and it is also a trap with a delay built in. A previous agency set it for the authority they used. You move the client to a different one. Issuance fails, with an error mentioning CAA that reads like an internal problem at the authority, and it fails at renewal time rather than at the moment anyone changed anything.

Three details worth knowing before you meet one. An empty value, written as a lone semicolon, forbids all issuance. The check walks up the tree, so a record on the parent domain constrains subdomains that have none of their own. And a wildcard certificate is governed by issuewild, which is a separate property from issue, so a domain can permit ordinary certificates and refuse wildcards.

Check it whenever you take over a domain, and again whenever a certificate request fails for a reason that does not obviously make sense.

The TXT records nobody can explain

Every zone that has been alive for a few years contains strings like google-site-verification=, MS=, a random hexadecimal blob, and something with a vendor name in it.

Each one is a service that was proved ownership of this domain at some point. The service checks again periodically, and delete the record and the verification lapses, quietly, on the service's own schedule. What that costs depends on what was verified: a search console losing access is an inconvenience, a mail platform losing domain verification can stop delivery, and a payment or identity provider losing it can disable an integration.

So the operating rule is simple and worth writing into your own process. Do not delete a TXT record you cannot explain. Comment it instead, in whatever documentation you keep, with the date you found it and the fact that its purpose is unknown. If a client insists on tidying the zone, remove one record, wait a month, and see what breaks, rather than clearing five at once and having no way to attribute the failure.

Mail records, which fail without telling the person who owns the domain

The asymmetry here is the whole problem. When a website breaks, its visitors experience the break. When mail authentication breaks, the message is silently sorted into a spam folder at the recipient's provider, and nobody at the sending end is told anything.

Three records, three failure shapes.

SPF lists which servers may send for the domain. It is a single TXT record, and having two of them is a configuration error that causes receivers to fail the check entirely rather than merging them. This is what happens when a new mail provider's setup wizard adds its own record alongside the existing one.

DKIM publishes the key used to sign outgoing mail, at a selector-specific name. Rotating a key at the provider without updating the record breaks signing for everything sent afterwards.

DMARC tells receivers what to do when the other two fail. Setting it to reject before SPF and DKIM are actually correct for every legitimate sender, including the client's newsletter tool, their CRM and the contact form on the site, means valid mail is discarded rather than filtered.

All three are independent of whether the site is up, which is the general point about mail: a perfectly healthy website tells you nothing about whether the domain's mail is arriving, and the two are watched by different checks entirely: the outage that no web check can see.

Taking an inventory before you change anything

The zone transfer that would give you everything in one command is refused by every competently configured nameserver, and rightly so.

dig @ns1.provider.net example.com AXFR   # will almost certainly fail

So the practical route is the provider's export. Every DNS host has one, it is usually a zone file or a CSV, and it takes thirty seconds. Do it before you touch anything, save it with the date, and commit it somewhere. That file is the only artefact that lets you answer "what did this look like before" after a change goes wrong, and it is also the thing that makes a provider migration a comparison rather than a reconstruction.

Where you cannot get an export, because the client's previous agency controls the panel, enumerate what you can:

for t in SOA NS A AAAA MX TXT CAA; do
  printf '\n== %s\n' "$t"; dig +short example.com "$t"
done
for n in www mail smtp imap autodiscover ftp cpanel webmail staging dev api shop; do
  a=$(dig +short "$n.example.com" | tr '\n' ' ')
  [ -n "$a" ] && printf '%-14s %s\n' "$n" "$a"
done

Incomplete by construction, and it finds the common ones. Anything it returns that you did not know about is worth understanding before the migration, particularly names pointing at addresses belonging to a provider the client no longer uses: a record aimed at an address somebody else now owns. Read the header of each answer as well as the data, because a name that exists with no record of the type you asked for produces an empty answer and a perfectly successful status: NOERROR with nothing in it is not an error.

What to write down, per record

Three columns, kept next to the export: who asked for it, roughly when, and what stops working if it is removed.

Most zones cannot be documented that way retroactively, and that is fine. Fill it in going forward, from the day you take the domain over, and within a year the zone stops being an archaeological site. It is the same discipline as commenting a crontab line rather than deleting it, and it exists for the same reason: the cost of the missing explanation is always paid by whoever is there next, at the worst possible moment.