Agencies building and running client websites usually end up holding the keys to those domains – registrar logins, DNS zones, email authentication records and a long tail of subdomains created during the project. When the contract ends, a sloppy client domain handover can take the site offline, break email delivery, or leave the agency’s old CNAMEs pointing at resources nobody controls anymore. This guide covers a full handover procedure: what to transfer, in what order, and how to check afterward that nothing was left behind.
Why Handovers Go Wrong More Often Than Launches
A launch gets a project manager, a checklist and a QA pass. A handover usually gets an email that says “please send us the logins” and a deadline two weeks out. The agency team is already working on other projects, and whoever set up the DNS in 2021 may have left the company.
Here is a typical case. An agency managed a retail client’s domain for four years. Over that time, the zone grew to 40-60 records: a staging site on Netlify, a Black Friday landing page on Unbounce, a HubSpot DKIM CNAME, Mailgun for transactional mail and a status page subdomain. At handover, the registrar account moves cleanly. Three months later, the agency closes its Netlify team. The client’s staging. subdomain now points at a Netlify hostname that anyone can claim. That’s a dangling DNS record, and it’s ready for a subdomain takeover.
The Myth: Moving the Registrar Moves Everything
The most common misconception is that once the domain sits in the client’s registrar account, the handover is complete. It isn’t. The registrar controls registration and which nameservers are delegated. The DNS zone itself may still be hosted in the agency’s Cloudflare, AWS Route 53 or DNSimple account.
Some clients end up owning the domain while the agency still controls every DNS record. If the agency then deletes the zone during an account cleanup, the domain stops resolving. That’s why the registrar, the DNS hosting and the services the records point to have to be handed over as three separate layers.
A Step-by-Step Client Domain Handover Procedure
An experienced agency DNS lead treats a handover like a migration and works through it in a fixed order. The full process usually takes 2-4 weeks, mostly because of TTLs and registrar transfer windows.
Step 1 – Inventory before touching anything. Export the full zone file and run subdomain discovery against the domain. Certificate Transparency logs and passive DNS often turn up hostnames that aren’t in the current zone but are still referenced somewhere. Write down which service each record points to and which account owns that service.
Step 2 – Lower TTLs. At least 48 hours before any nameserver change, drop TTLs on critical records to 300 seconds. Do the same for the NS records you control. That way, if something breaks after the cutover, a fix reaches users in minutes instead of a day.
Step 3 – Handle DNSSEC first. If the domain is signed, you either remove the DS record at the registrar and wait out the parent TTL, or coordinate a key rollover to the new DNS provider. Switching nameservers while an old DS record is still published causes validation failures on every validating resolver, including Google Public DNS and Cloudflare 1.1.1.1.
Step 4 – Transfer the registrar or change the registrant. If the domain stays at the same registrar, use an account-to-account push, which is usually instant. If it’s moving to a different registrar, unlock the domain, generate the EPP auth code and send it through a secure channel, not plain email. Be aware that some registrars apply a 60-day transfer lock after a change of registrant unless the registrant opts out. Check registrar lock settings before the deadline so this doesn’t catch you out. The guide on registrar lock settings and emergency domain recovery covers the details.
Step 5 – Move the zone, then verify. Recreate the zone at the client’s DNS provider and compare it record by record against the export. Only then update the nameservers at the registrar. Query both the old and the new authoritative servers directly with dig until the answers match.
Step 6 – Hand over the dependent services. This is the step most often skipped. Every CNAME, A record and TXT verification token points somewhere. Either move each target resource to the client’s account, or delete the record before the agency’s resource goes away.
Email Authentication Needs Its Own Pass
Email breaks quietly. If SPF still includes the agency’s Mailgun or SendGrid subaccount, the client keeps authorizing a sender they no longer control. If DKIM selectors point at keys the agency rotates or deletes, signed mail starts failing DMARC alignment, sometimes weeks after the handover.
Check DMARC reporting addresses too. A common leftover is a rua= tag that still sends aggregate reports to the agency’s dmarcian or Postmark mailbox. The client loses visibility into its own mail streams, and the agency keeps receiving data it has no business holding. GDPR-regulated clients in particular should count that as a data-handling issue, not just a technical oversight.
Rebuild the SPF record from scratch rather than editing it, and recount the DNS lookups. Leftover includes are the usual reason a record goes over the ten-lookup limit.
Common Mistakes Agencies Make During Handovers
Deleting agency-side resources before the records are removed. Teams close a Heroku app, an S3 bucket or an Azure App Service as part of offboarding, while the client’s CNAME still points at it. This is exactly how dangling CNAME records are created. Always remove the record first and the resource second.
Trusting the zone file as the complete inventory. Wildcard records, records in a separate delegated subzone and hostnames managed through a CDN dashboard don’t show up in a basic export. External discovery catches what the zone file misses.
Sharing credentials instead of transferring ownership. Giving the client the agency’s Cloudflare login isn’t a handover. It’s shared custody with no audit trail. Transfer the zone into an account the client owns, then revoke agency access and API tokens the same day.
Edge Cases Worth Planning For
Some domains can’t follow the standard path. Country-code TLDs such as .fi, .de and .uk use their own transfer mechanisms. Some have no EPP auth codes and require registry-specific forms. Enterprise clients may use registry lock, where every change requires a manual, out-of-band verification that adds days.
Small clients with fewer than 10 employees often have no one ready to take over DNS administration at all. In that case, a written ownership document plus a managed DNS provider with sensible defaults is more realistic than handing over a complex zone. Agencies that manage dozens of clients should also look at how they monitor DNS across multiple clients, so that offboarding one client doesn’t create gaps for the others.
FAQ
How long does a client domain handover usually take?
Plan for 2-4 weeks. The registrar transfer itself can finish in 5 days or less. The extra time goes to lowering TTLs, the DNSSEC transition, moving dependent services and a monitoring period after the cutover.
Should the agency keep any access after the handover?
Only if a new support contract explicitly covers it. In that case, use a separate delegated user or a scoped API token in the client’s own account, never the agency’s original credentials.
What should be checked after the handover is complete?
Confirm that every subdomain resolves to a resource the client owns. Check that SPF, DKIM and DMARC pass for all sending services, that DMARC reports reach the client and that no record points at a deprovisioned cloud resource. Repeat the check 30 and 90 days later.
Closing the Handover Cleanly
A good client domain handover separates three layers: domain registration, DNS hosting and the services the records point to. Each one is transferred and verified on its own. Start with a full subdomain inventory, sort out DNSSEC before changing nameservers and remove records before deleting the resources behind them. One last practical tip: schedule a DNS health check 90 days after the handover. That’s about when forgotten staging environments and expired agency subscriptions start leaving dangling records behind.