Domain & DNS handover checklist: what the next person needs to know
The domain is the part of a handover that costs the most when it is wrong, and it is nearly always the part written down least carefully. This is what to record, in the order someone will need it.
The short answer
A domain and DNS handover should record five things: who the domain is registered to, who can sign into the registrar account, when it expires and whether auto-renew is on, where DNS is actually managed, and what was changed during the project. The registered owner and the person who can log in are often different people. Document both.
Everything else on this page is detail underneath those five. The goal is not to teach the client DNS — it is to make sure that whoever has to touch it next, which may be a stranger in three years, can find the right control panel without guessing.
Who owns it, and who can actually sign in
The person or organisation a domain is legally registered to and the person who can log into the registrar account are two separate facts, and they are frequently different. A handover that records only one of them is the reason domain disputes take weeks instead of an afternoon.
The registration — the registrant record — is the legal claim. The registrar account is the practical control. You need both written down, because each one fails differently:
- Right owner, no access. The domain is registered to the client’s company, but the only login belongs to a developer who left two years ago. The client owns something they cannot renew.
- Access, wrong owner. The agency registered it during the build, in good faith, in the agency account. The client believes they own it because they were invoiced for it. Nobody finds out until the relationship ends.
WHOIS privacy makes this worse rather than better. It is sensible to have on, and it means nobody can verify ownership from outside. If privacy is enabled, the handover document is the only place the real answer is written down — which raises the stakes on writing it down accurately.
Write both lines, even when they are the same. “Registered to Client Ltd; registrar account held by Client Ltd” takes five seconds and removes an entire category of argument. A blank second line reads as an oversight, and a reader cannot tell the difference.
If the agency is holding the domain for convenience, say so explicitly and say why. That is a conversation worth having on a good day rather than a bad one.
Expiry, auto-renew, and the card it renews on
Record the expiry date, whether auto-renew is switched on, and which payment method it renews against. A lapsed domain takes the website and the email down at the same time, and recovering one after it has been released is expensive and sometimes impossible.
Auto-renew is not the guarantee it looks like. It fails quietly in three ways: the card on file expires, the account’s billing email is an address nobody reads any more, or the domain sits in an agency account whose payment method stops when the relationship does. All three produce the same outcome and all three are invisible until the day it happens.
So the useful record is three lines, not one: the date, the auto-renew state, and whose payment method. Then put the renewal in the maintenance schedule as an annual task with a named owner, so it is somebody’s job rather than somebody’s assumption.
Where DNS is actually managed
DNS is often not managed at the registrar. The nameservers on the domain say where it really is — whichever service they point to is the one holding the records that matter, and it is the only place an edit will have any effect.
This is the single most common wasted hour in a handover. Someone logs into the registrar, finds a DNS panel, edits an A record, and nothing changes, because the domain’s nameservers delegate to a host, a CDN or a DNS provider and the registrar’s panel has not been authoritative for years. The records they edited are real. Nothing is reading them.
So the document records two things that sound like one:
- The registrar — where the domain is bought and renewed.
- The DNS provider — where the records live, identified by the nameservers currently set on the domain.
Write the nameservers out in full. They are the pointer that makes the rest of the section verifiable by anyone, at any time, without an account.
The records worth recording, and what each one does
A handover document does not need a full zone export. It needs the record types a person is likely to have to reason about: A, AAAA, CNAME, MX, and the TXT records that carry SPF, DKIM and DMARC. One line each on what it points at and why.
The purpose here is documentation, not education. Someone reading this in two years needs to know which records exist and what depends on them — enough to know what they are about to break.
| Record | What it does | What to write down |
|---|---|---|
| A | Points a name at an IPv4 address — usually the web server or a proxy. | The host, the address, and what is at the other end. |
| AAAA | The same thing for IPv6. Present on some hosts, absent on plenty. | Only if one exists. Do not invent one. |
| CNAME | Points one name at another name. Common for www and for third-party services. | Which name, and which service required it. |
| MX | Says where the domain’s email is delivered. Nothing to do with the website. | The mail provider by name. This is the row that matters most. |
| TXT — SPF | Lists which servers are allowed to send mail as this domain. | That one exists, and which services are named in it. |
| TXT — DKIM | Publishes the key that signs outgoing mail so it can be verified. | That it exists and which provider issued it. |
| TXT — DMARC | Tells receiving servers what to do with mail that fails the two above. | That it exists, and the policy it is set to. |
| TXT — verification | Proves domain ownership to search tools, mail providers and others. | Which service each one belongs to, so nobody deletes a mystery record. |
| NS | Delegates the domain to its DNS provider. | The full nameserver list, verbatim. |
The last column of the verification row is not a small point. Unlabelled TXT records look like debris, and debris gets tidied. A one-line note saying which service put it there is what stops a future cleanup taking a mail domain out of verification.
Why changing nameservers can stop the client’s email the same day
Moving a domain’s nameservers moves every record at once, not only the website ones. If email is hosted somewhere other than the new DNS provider, the MX, SPF, DKIM and DMARC records do not travel with it — and mail stops arriving as soon as the change propagates.
This is the most damaging mistake in a website handover, and it is easy to make because the two things feel unrelated. The website is moving to a new host. The host says “point your nameservers here”. Someone does. The site comes up on the new host and looks perfect. Meanwhile the domain is now answering from a fresh DNS zone that was created for a web host and knows nothing about the client’s mail provider, so the MX records are gone. The site works; the business stops receiving enquiries.
It is worse than a site outage in two ways. Nobody notices immediately — inbound mail simply thins out — and the mail that bounced during the gap is not waiting somewhere to be recovered.
Before any nameserver change, write down the existing MX, SPF, DKIM and DMARC records and confirm the new zone has them. If the client’s email is with Google Workspace, Microsoft 365, their old host or anyone else that is not the new DNS provider, treat the nameserver move as a mail change as well as a web change.
The alternative is frequently better: leave the nameservers where they are and change only the records that need to change. A handover that does not touch nameservers is a perfectly good handover, and it carries none of this risk.
Recording all this in a document per client?
Handover has a Domain & DNS section built for exactly these fields — registrar, registered owner, registrar access, where DNS is managed, nameservers, and a list of DNS records — and it puts a warning on the client’s page when their email is hosted elsewhere.
Create your first manual freeWhat changed at handover
Record which of three things happened during the project: the nameservers were moved to a new provider, individual records were changed but the nameservers stayed put, or DNS was not touched at all. All three are normal, and the next person needs to know which one they are looking at.
This is the field most handover templates leave out, and it is the one that answers the question people actually arrive with: what did you change, and when? A year later, when something is behaving oddly, the difference between “we moved the whole zone in March” and “we added one CNAME and left everything else alone” is the difference between an hour of investigation and a five-minute answer.
- Full nameserver move — note the old provider as well as the new one, and confirm in writing that mail records were carried across.
- Records only — list which ones, and what they were before.
- Nothing changed — say so explicitly. “We did not touch DNS” is useful information, and a blank section is not.
Subdomains, CDNs and proxies
Record every subdomain that resolves, what serves it, and whether traffic passes through a CDN or proxy before reaching the origin. A proxy layer changes what the DNS records appear to say, and someone who does not know it is there will read them wrongly.
Subdomains
Staging sites, a shop on a subdomain, a booking system, a help centre, a mail-tracking subdomain issued by an email platform. Each one is a name that resolves somewhere, and each one can break independently of the main site. List them with what serves them. Include the ones you consider temporary — a staging subdomain that outlives the project is both a maintenance item and, if it is indexable, an SEO one.
CDNs and proxying
When a service such as a CDN sits in front of the site in proxy mode, the A record points at the proxy rather than the origin server, and the origin address is not visible in DNS at all. That is the intended design, and it means two things for the document: say that the proxy is there and where its account lives, and record the origin separately, because a future developer will need it and DNS will not tell them.
Also note the SSL arrangement. Certificates issued by a proxy, by the host, or by a certificate authority on a renewal schedule all fail in different ways, and a manual certificate that lapses is a very public failure.
The checklist
Everything above, as lines to fill in. If a line does not apply, strike it out rather than leaving it blank.
Domain
- The domain, and any others that redirect to itIncluding defensive registrations and old brand names.
- Registered ownerThe organisation on the registration, not the person who paid.
- RegistrarWhere it is bought and renewed.
- Who can sign into the registrarName and organisation, plus the account’s contact address.
- Expiry dateAnd a matching annual row in the maintenance schedule.
- Auto-renew on or off, and whose payment methodThree separate failures live in this one line.
- Transfer lock and WHOIS privacyWhether each is on, so nobody is surprised mid-transfer.
DNS
- Where DNS is managedOften not the registrar.
- Nameservers, written out in fullThe pointer anyone can verify without an account.
- Who can sign into the DNS providerAgain, ownership and access as two lines.
- A and AAAA recordsWhat they point at, and whether that is an origin or a proxy.
- CNAMEs, and which service required each oneUnattributed CNAMEs get deleted.
- MX records and the mail provider by nameThe row that decides whether a nameserver move is safe.
- SPF, DKIM and DMARCThat they exist, which services they name, and the DMARC policy.
- Verification TXT records, each labelledSo a future tidy-up does not remove one.
- Subdomains and what serves themStaging included.
- CDN or proxy in front, and the origin addressThe origin is invisible in DNS when a proxy is on.
- SSL certificate: who issues it and how it renewsAutomatic for most, manual for some.
At handover
- What changed: nameservers, records only, or nothingSay which, in those words.
- If nameservers moved: mail records confirmed present in the new zoneConfirmed by checking, not by assuming.
- Is email hosted somewhere other than the DNS provider?If yes, flag it prominently for whoever touches this next.
- Registrar and DNS access transferred and acceptedAccepted, not invited.
Print this page for a paper copy. Navigation, sidebar and calls to action drop out.
None of the lines above is a password. This section records where things live and who controls them; the credentials move separately. That distinction is covered in how to hand over website passwords.
Hand over your next website properly
One form in. A client-ready manual out — live link, printable PDF, your branding, English or Spanish.
Start free — 1 active manual, no card
Drafts are unlimited on every plan. Archived manuals stay online and don’t count.