Why access is collected before the first change
The first reflex of an agency taking over a client is to log in somewhere and fix things. It is also the moment when most damage happens: an MX record deleted by mistake cuts off email, a nameserver change makes a zone nobody exported disappear, a renewal fails because the registrant's email no longer answers.
The client does not always know where their access lives. The domain was bought by a former provider, the DNS is served by a third party, the hosting is a cPanel whose password sleeps in a two-year-old message. The agency learns this real state by touching something, which is the worst moment to learn it.
An onboarding checklist sets a simple order: record the public state, export whatever can be exported, obtain only the permissions required, log everything, and only then change. When the portfolio grows beyond what one person can hold in their head, this ritual becomes the agency's only reliable memory.
What an access inventory saves you from
- Email cut off — an MX, SPF or DKIM record deleted or overwritten without a prior snapshot interrupts the client's mail within the hour.
- The lost zone — changing nameservers without a full zone export makes subdomains nobody remembered disappear.
- The expired domain — the registered holder is a former provider, and renewal notices go to a dead address.
- The blocked transfer — an active lock or an invalid contact email prevents validating a transfer exactly when you need it.
- Access that is too broad — a root password sent by email stays valid for years after the engagement ends.
- The missing file — without an access table, nobody else at the agency can take over the client during an absence.
Who owns what: the client stays the registrant, the agency receives delegated access
The objection comes up at every onboarding: who holds the relationship and who owns the domain? The answer is the same for every client. The client remains the registrant of the domain, and the agency receives delegated access. You manage the relationship and day-to-day operations; the hosting infrastructure is the platform's side; the client keeps ownership of what carries their name.
This split protects both sides. If the engagement ends, the client leaves with their domain without negotiation. If the client changes contact person, the agency is not held responsible for a name it never owned.
That leaves the argument you will hear: asking for access feels heavy. Answer with a minimal list and a template message (below). Ask only for what the engagement needs, layer by layer, with the lowest permission that works. The table below is the starting point.
Permission level to request for each layer
Scroll the table
| Layer | Permission to request | How to transmit |
|---|---|---|
| Registrar | Delegated access or technical contact, read access to status, one-off unlock for a transfer | Invitation from the registrar console, never the client's shared account |
| DNS zone | Record editing and full zone export | Named account at the DNS provider, or zone delegation |
| cPanel / WHM hosting | The site's cPanel account; WHM only if the agency administers the server | Dedicated user, password in the shared manager |
| Email mailboxes | Administrator access to the mail console, without reading mailboxes | Dedicated admin account, never a personal mailbox password |
| Application (CMS) | Named administrator account | Account created in the contributor's name |
| Renewal contact | A contact address read by the agency, payment method left with the client | Group alias rather than an individual address |
| Backups | Access to the latest full backup | Encrypted link or storage with a limited lifetime |
Record the real state before touching anything
Before asking for a single password you can already read a lot publicly. Run these commands from your workstation and keep the output in a dated file: it is your reference state.
dig +short NS example.com returns the nameservers that serve the zone, usually two to four lines. They tell you who runs the DNS, which can differ from the registrar. dig +short A example.com returns the site's IP address: compare it with the hosting the client says they use. dig +short MX example.com returns a priority followed by a server name; an empty answer means no mail is routed through this domain.
dig +short TXT example.com shows the SPF record, which starts with v=spf1, and the verification tokens of third-party services. The DMARC policy is read with dig +short TXT _dmarc.example.com. A DKIM key is read with dig +short TXT selector._domainkey.example.com, but you need to know the selector: it appears in the header of a message the client sent.
Then whois example.com gives the registrar, the expiry date and the statuses. For a .ma extension the public output is more limited: the ANRT documentation is the reference, and you should not assume it follows the rules of a .com.
The onboarding checklist, step by step
Identify the registrant and the registrar
Ask the client for the name of the domain holder and the registrar where it was bought, before any access. Write the answer down even if it is approximate: it will be compared with the whois.
Record the public DNS
Run
dig +short NS,A,MXandTXTon the domain, then_dmarcas TXT. Save the raw output in a file dated today.Record the whois
Run
whois example.comand copy the registrar, the expiry date, the statuses and the contact email. Compare with what the client told you.Export the full zone
From the console of the provider that serves the zone, export it in full. An AXFR zone transfer is almost always refused, so the export goes through the interface. Keep a separate capture of the MX, SPF, DKIM and DMARC records.
Request access per layer, at minimum rights
Take the permissions table and ask only for what the engagement requires: registrar, DNS, hosting, mail, application.
Have access transmitted without plain-text passwords
Create one vault per client in a shared password manager and have the access deposited there. Enable two-factor authentication on every named account.
Test every access read-only
Log in to each layer, confirm access works, then log out without changing anything. Note the test date.
Log it and plan the expiry dates
Fill in the summary table, then carry the expiry dates into your renewal tracking. In the ServOrbit.com Agency space, the portfolio view centralizes these deadlines.
Reading the whois: lock, registrant and contact email
The whois holds four pieces of information that decide what comes next. The first is the registrar, which tells you where the domain really lives. The second is the expiry date: a domain close to expiry comes before everything else.
The third is the status. clientTransferProhibited is the transfer lock: the registry rejects any request to move the domain to another registrar. It is normal and protective, but you must ask the registrar to remove it before a transfer. clientUpdateProhibited blocks changes. clientHold stops DNS resolution, and redemptionPeriod or pendingDelete flag a domain being deleted: that is an emergency, not an onboarding item. The definition of each status is published by ICANN.
The fourth is the registrant and their contact email. If the registrant is a former provider or a departed employee, note it: the client must regularize this. A dead contact email prevents validating a transfer or a renewal, because confirmation messages go to an address nobody reads. The transfer code does not appear in the whois: it is requested from the registrar, and the ICANN transfer policy frames the rules that apply.
Transmitting access
No passwords by email, instant messaging or in a ticket. Use a shared vault, one named account per contributor and two-factor authentication, then revoke each access when the engagement ends. An access without an end date becomes a security debt.
The template message to send the client
The message must be short and predictable. Here is a template to adapt: "Hello, to start the engagement we need five things: the name of the holder of your domain, access to domain management at your registrar, access to the DNS zone, access to the hosting and to the mail console. We only ask for the permission needed on each layer, and we suggest depositing the access in a shared vault we create in your name. You remain the registrant of the domain, and we change nothing before having recorded and exported what exists."
This text says what is requested, why, how to transmit it and what the client keeps. It answers the objection before it is raised. Send it with the link to your vault, not with the access itself.
Access summary table
Scroll the table
| Layer | Owner and permission granted | Date and expiry |
|---|---|---|
| Registrar | Client as registrant; delegated read access and unlock | Granted DD/MM; review at renewal |
| DNS zone | DNS provider; editing and export | Granted DD/MM; named account |
| cPanel hosting | Agency; the site's account, no root access | Granted DD/MM; ends with the engagement |
| Client; admin console, mailboxes not read | Granted DD/MM; ends with the engagement | |
| Application (CMS) | Client; administrator account in the contributor's name | Granted DD/MM; ends with the engagement |
| Renewal contact | Agency; group alias | Updated DD/MM; domain expiry logged |
Troubleshooting: the errors that recur at onboarding
status: NXDOMAIN in the dig output means the name does not exist in public DNS. Check the spelling first, then the whois: an expired domain or one in clientHold answers this way. The fix is at the registrar, not in the zone.
status: SERVFAIL most often points to unreachable nameservers or broken DNSSEC. Rerun with dig +cd example.com: if the answer comes back with that option, DNSSEC validation is the cause, and you must check the DS record at the registrar.
A whois that answers No match for indicates an unregistered name, or an extension your whois client cannot query. Try the whois service of the relevant registry before concluding.
A cPanel login refused while the password is correct often comes from the host's firewall, which blocks the agency's IP address after a few failed attempts, or from a suspended account. Ask the host to lift the block and do not multiply attempts.
Finally, a transfer refused when everything seems ready almost always points to clientTransferProhibited still active, or to a contact email that does not receive the confirmation.
Making the checklist a routine gesture
The value of this list comes from repetition. Keep it in your knowledge base, version it, and apply it identically to every client, including the one that looks simple. After about ten onboardings the steps become reflex and the access table becomes the first page of the client file.
Once the access is logged, deadline tracking takes over: the article on managing client domain renewals describes the alerts to set, and the one on migrating a WordPress site details what follows when the client changes host. To choose between shared hosting and a VPS, the last linked article compares the two by site profile.
Keep the order in mind: record, export, request minimum rights, test read-only, log, then change.
