Document every DNS record that currently resolves for the domain, not just the ones you think matter: the A and AAAA records pointing at the web host, CNAMEs for www and any subdomains, MX records for mail, and the TXT records carrying SPF, DKIM and DMARC. Add the NS records and the registrar login path, because a next developer who can read the zone but not edit it is still stuck. A DNS record is a line in the domain's zone file telling the internet where to send traffic of a given type. A handover that covers the CMS — WordPress, Drupal, or anything else — but skips DNS leaves the next person guessing which of three hosting accounts actually serves the site, and guessing tends to end with an outage.
Official resources:
- Look up a domain's registrar, nameservers and expiry in ICANN Lookup — Confirm the authoritative nameservers, registrar of record and expiry date for the domain before handing it over.
- Check record types against IANA's DNS Parameters registry — Verify that every record type documented in the handover (A, CNAME, MX, TXT, CAA, SRV) is a real assigned type and what it is defined by.
Table of Contents
- The records that must appear in the document
- Why the zone file alone is not the handover
- Proxies, CDNs, and records that lie about the real server
- How to capture the current state before you hand it over
- What to hand over alongside the records
- Frequently Asked Questions
The records that must appear in the document
Start with the records that answer "where does this traffic go?" The apex A record (and AAAA, if IPv6 is configured) points the bare domain at a server IP. The `www` record is usually a CNAME aliasing the apex, but not always — some setups duplicate the A record instead, and knowing which one you have changes how a host migration behaves. Mail is the part most often forgotten, and the most damaging to break. MX records route inbound mail, and they frequently point somewhere entirely unrelated to the web host — Google Workspace and Microsoft 365 are common. Beneath them sit the authentication TXT records: SPF (a list of servers allowed to send as your domain), DKIM (a public key used to sign outgoing mail, usually on a selector subdomain), and DMARC (a policy at `_dmarc` telling receivers what to do when SPF or DKIM fails).
Then the records that exist for a reason nobody remembers. Verification TXT records for Search Console, a payment processor, or a CDN. CNAMEs for a helpdesk, a status page, a mailing-list provider, a staging subdomain. Each one should carry a note saying what it serves and who owns that service. A record with no owner is a record someone will eventually delete.
Why the zone file alone is not the handover
Exporting the zone gives the next developer the values. It does not tell them where to change those values, which is the thing they will actually need at 9pm on a launch night. Three things sit above the zone and all three need writing down. The registrar is where the domain is bought and renewed.
The nameservers, set at the registrar, decide which service answers DNS queries — often the registrar itself, often Cloudflare, sometimes the hosting panel. The DNS provider is where records are edited. These are frequently three different companies with three different logins, and the zone export names none of them. Add the expiry date and whether auto-renew is on. A domain that lapses takes the site and the mail with it, and recovery can involve redemption fees and delay depending on the registrar and TLD.
Proxies, CDNs, and records that lie about the real server
If the domain runs through Cloudflare or a similar reverse proxy, the A record you see in the dashboard is not the address the public resolves. Proxied records resolve to the provider's edge IPs, which means a `dig` from outside will never reveal the origin server. Document the origin IP separately and mark it clearly, or the next developer will chase a DNS answer that was never pointing at your host. Note the proxy status per record, because it is usually mixed.
A proxied web record alongside an unproxied mail or FTP subdomain is standard, and flipping one by accident breaks something quietly. Also document where TLS certificates come from. A certificate issued by the host, by Let's Encrypt on the server, or by the CDN edge each renews differently, and some validation methods depend on a DNS record (typically a TXT under `_acme-challenge`) staying in place. Deleting an unexplained TXT record is an easy way to break a renewal months later.
How to capture the current state before you hand it over
Do not transcribe from memory or from an old spreadsheet. Read the live zone and the live resolution, then reconcile the two — a record that exists in the panel but does not resolve, or vice versa, is exactly the kind of surprise a handover is supposed to remove.
Save the result as a dated plain-text or Markdown file in the project repository or client documentation, not as a screenshot. Screenshots cannot be searched, diffed, or copy-pasted into a new provider's import field.
- Export the full zone file from the DNS provider if the export feature exists; most offer one.
- Query the public view yourself for each type: A, AAAA, CNAME, MX, TXT, NS, and any SRV or CAA records. Command-line tools like `dig` or `nslookup` work, as do browser-based lookup services.
- Query the apex and `www` separately, plus every subdomain you know about — wildcard and subdomain records will not show up in an apex query.
- Record the TTL on each record. A long TTL means a change takes longer to propagate, which matters when planning a migration window.
- Confirm the nameservers at the registrar match the DNS provider you have been editing. A mismatch means your edits were doing nothing.
What to hand over alongside the records
Access is the other half. The next developer needs a route to the registrar and DNS accounts in their own name — an invited user, not your password. Shared credentials break the moment you change yours, and they make it impossible to tell who made a change.
Write down who is authorised to approve a DNS change. On a client site this is often not the developer, and a change made without that approval, however technically correct, is the kind of thing that ends an engagement. Finally, state plainly which records you do not understand. A handover note that says "TXT record `abc123…` at apex — unknown purpose, present since before my involvement, do not delete without investigating" is more useful than a clean-looking list that silently omits it.
Frequently Asked Questions
Should I include the DNS records in the same document as the CMS admin credentials?
Keep the record values and the account access separate. The zone details are safe to store in project documentation; logins belong in a password manager with shared access, so revoking one person does not require rewriting the other document.
What if the client's DNS is managed by a third party I have no access to?
Document that explicitly — name the party if you know it, note the nameservers as evidence, and say what you could and could not read. An honest gap is actionable; an omission looks like the records do not exist.
How long should the documentation stay accurate after handover?
Treat it as a snapshot with the capture date on it. Any DNS change invalidates part of it, so the receiving developer should re-query the live zone before relying on it for a migration.
