How to manage client domains: ownership, access, renewals, and DNS

Every client relationship arrives with at least one domain attached, and usually more: the apex, the www, a staging subdomain, an email domain, a campaign microsite someone registered in 2019 and forgot about. Domain management is invisible work. Nobody thanks you when it goes well, and everyone remembers the Tuesday a client's email died because a card on file expired.

This is the playbook we wish every agency had on day one. It covers who should actually own a client's domain, how to inventory the sprawl you have already accumulated, how to automate renewals so expiry is never a surprise, how to replace shared registrar logins with real access control, how to run DNS changes without fear, and how to offboard a client without burning a week. At the end, there is a way to skip most of this entirely for the most common case.

The ownership question: the client should own their domain

Start with the decision that shapes everything else. When a new client needs a domain, someone has to register it. It is faster for you to do it in the agency's registrar account, on the agency's card, and plenty of agencies do exactly that during a busy kickoff week. It is also the single most common source of domain grief in this industry.

The registrant on record is the presumptive legal owner of a domain. If that is your agency, your agency owns a core piece of your client's business. That is fine right up until it is not:

• Disputes get ugly fast. If a project goes sideways and the invoice conversation turns tense, a domain held by the agency looks like leverage, whether or not you intend it that way. Clients remember that. So do their lawyers.
• You become a permanent chokepoint. Every DNS change, every email migration, every new SaaS verification record routes through your team forever, including years after the engagement ends.
• Continuity risk cuts both ways. If your agency winds down, merges, or simply loses the one person who knew the login, the client's most valuable digital asset goes down with it.
• Transfers are slow when you need them fast. ICANN rules lock a domain against transfer for 60 days after registration or a previous transfer. A handover you could have done calmly last quarter becomes impossible during the crisis that finally forces it.

The rule is simple: the client registers the domain, in a registrar account they control, under their organization's legal name, paid with their card. Your agency takes delegated access to manage it. If the client is not technical, set the account up together on a kickoff call. It takes twenty minutes, and the asset sits in their name from day one.

If you currently hold domains for clients, plan the handover now, while the relationship is healthy. Update the registrant details, initiate transfers into client accounts, and keep your working access through delegation instead of ownership. Because of the 60 day lock, this is not something to attempt mid crisis.

Inventory the sprawl before it surprises you

Agencies accumulate registrars the way kitchens accumulate mugs. One client came over from another agency with domains at GoDaddy. A founder registered the brand name on Namecheap at 1 a.m. years ago. Someone bought the campaign domain on whatever registrar had a sale. Multiply by every client and you get multi-registrar sprawl: dozens of domains across a dozen providers, none of it written down in one place.

The fix is a domain register: one living document or internal tool that answers every question before it becomes urgent. For each domain, record:

• The domain, and everything that depends on it: website, email, subdomains, API endpoints, and third party verification records
• The registrar, and whose account it sits in
• The DNS host, if different from the registrar, which it often is
• Current nameservers
• Expiry date, auto-renew status, and whose payment method backs the renewal
• Who on your team and the client's team has access, and at what permission level
• TLS certificates in play, who issues them, and how they renew

Gathering this is less painful than it sounds. An RDAP lookup (the modern successor to WHOIS) returns the registrar, status, and expiry for any domain. A quick nameserver query shows where DNS is actually hosted. Export zone files wherever the provider allows it, and file them with the register. An afternoon of focused work covers a surprising number of clients.

Then keep it alive. Review the register quarterly and update it with every change. A stale inventory is worse than none, because people trust it.

Renewals and expiry: the most preventable outage in the business

An expired domain takes down everything at once: the website, email, every subdomain, and every integration verified through DNS. And it decays in stages. Most registrars offer a short grace period after expiry, then a redemption period with a recovery fee, and then the domain is released for anyone to register. Dropped domains with real traffic get picked up quickly, and not by people you want holding your client's brand.

None of this should ever happen, because renewal is entirely automatable:

• Turn on auto-renew everywhere, and understand its one failure mode: it fails silently when the card behind it expires or the account email goes stale. This is one more argument for the client owning the account and the payment method. Their finance team notices a failed charge on their own card far faster than they notice one on yours.
• Add alerts you control. Registrar reminder emails land in spam folders and the inboxes of departed employees. Track expiry dates in your own register and alert at 60, 30, and 7 days out. RDAP data is public, so a small script or an uptime style monitoring service can check every domain daily without credentials.
• Register long for stable clients. Multi year registration is cheap insurance and removes most of the annual ceremony.
• Make renewals a named responsibility. Put domain stewardship on the retainer as a line item. Clients pay it gladly, and it makes the accountability explicit instead of assumed.

Access: stop sharing registrar logins

The default arrangement at most agencies is one shared login per client registrar, stored in a doc or a password manager, with 2FA codes going to the phone of whoever created the account. This fails in every direction. There is no audit trail of who changed what. Offboarding an employee means rotating every shared credential they ever saw. And the 2 a.m. emergency waits on one person's phone.

The better model is role-based access, and it is more available than most teams realize:

• Use delegation where it exists. Most major registrars and DNS hosts support delegated access or team accounts: the client owns the account and grants your agency a scoped role. Every teammate gets their own login and their own 2FA, and revoking one person's access is one click instead of a rotation project.
• Split DNS hosting from the registrar where it does not. If a client's registrar has no delegation feature, move the zone hosting to a DNS provider that has proper multi user access. The registrar login stays with the client for the rare registrar level task, like a renewal setting or a transfer, and your team works in the DNS host day to day.
• Treat shared vaults as the last resort. When a shared credential truly cannot be avoided, keep it in a per client vault in your password manager with the TOTP seed stored alongside, and rotate it on every staff departure, no exceptions.
• Keep an access matrix. Add a column to the domain register: who can touch what, at which provider, at what level. Review it whenever someone leaves either company.

A DNS change workflow that will not bite you

The riskiest moment in client domain management is an ordinary Tuesday. An email arrives saying "can you point shop.acme.com at the new platform," and someone edits the live zone from memory. Most of the time it works. The time it does not, you learn that the TXT record they deleted was the client's email authentication.

A lightweight workflow removes almost all of that risk:

1. Take requests in writing, with exact records. Type, host, value, TTL, and the reason for the change. A short intake form beats a forwarded email thread every time.
2. Snapshot the zone before touching it. Export the zone file or copy the records. This is your rollback plan, and it takes thirty seconds.
3. Lower TTLs before big cutovers. Drop the relevant records to 300 seconds a day ahead of a migration, then restore them after. Mistakes heal in minutes instead of hours.
4. Never delete a record you do not recognize. Unfamiliar TXT and CNAME records are usually verification for services the client depends on. Investigate first, remove second.
5. Know the apex rules before they know you. CNAME records cannot live at the zone apex at most providers, and workarounds vary. If that sentence is not second nature yet, read apex domain vs CNAME before your next migration.
6. Verify from the outside. Query several public resolvers, confirm the change propagated, and confirm the destination service actually sees the domain.
7. Record what changed and tell the requester. Date, records before and after, who made the change. Future you will be grateful.

That is perhaps fifteen minutes of process wrapped around a two minute change. It is far cheaper than the postmortem.

Offboarding a client cleanly

Engagements end. Handled well, offboarding is the last impression you leave and a quiet source of referrals. Handled badly, it is a month of tense emails about who controls what. The clean exit is a checklist:

1. Export a final zone file for every domain, plus a plain language dependency document: which records serve the site, which serve email, which verify third party services. Hand both over.
2. Transfer any domain still held by the agency into the client's account. Start early because of the 60 day transfer lock, and use a same registrar account move where the provider offers one, since those skip the lock.
3. Remove your team's delegated access at every registrar and DNS host, and ask the client to confirm the removal from their side.
4. Purge client credentials from your password vaults once the client confirms handover.
5. Update registrant, admin, and billing contacts so nothing routes to your agency's inboxes.
6. Document any TLS certificates you provisioned, and exactly when they stop renewing.
7. Set and communicate a firm date for anything still passing through infrastructure you operate.

If your register and access matrix are current, this whole list is an afternoon. If they are not, it is archaeology.

Or skip the DNS back-and-forth entirely

Everything above assumes that someone at the agency has to touch the client's DNS. For the highest volume task there is, pointing a client's domain at a site or platform you run, that assumption is now optional.

Custom Domain inverts the workflow. Instead of collecting registrar access, you send the client a connect link, or embed the connect widget in your own portal. The client picks their DNS provider from 63 supported providers and grants access through one-click provider authorization. Custom Domain writes the records, verifies ownership, and issues HTTPS automatically, and where a provider cannot be automated, the client gets an API token option or exact records with a guided flow that verifies itself. The domain is typically live in about 30 seconds, and certificates renew on their own from then on.

For an agency, that changes four things at once:

• You never hold registrar credentials. The client authorizes their own provider from their own logged in session. Ownership stays exactly where this guide says it should: with the client.
• The change request workflow disappears for connections. No intake form, no TTL planning, no resolver checks. You still need the workflow for other DNS work, but the most frequent category of request is simply gone.
• Monitoring is built in. Connected domains are rechecked for DNS drift, and webhooks tell your team the moment a client's records change out from under a live site, instead of the client telling you.
• Offboarding a domain is one call. Disconnect the domain through the dashboard or API and the relationship is over. There was never a shared credential to rotate.

The pieces are all there for agency tooling: an embeddable widget and SDK for client portals, a full REST API covering connections, records, TLS, monitoring, and webhooks, and an MCP server if your internal tools run on AI agents. Agencies running white label platforms can put the entire flow under their own brand: see Custom Domain for agencies.

Pricing starts at $0, so the sensible evaluation is practical: connect one real client domain end to end and time it. You can read how it works first, sign up and try it, or book a walkthrough if you would rather see it against your own client list.