Separate ownership from access
The client should usually own the domain. Your request should ask for delegated access, a guided DNS change, or a temporary collaborator role, not an unnecessary transfer.
Collect DNS context
Ask for registrar name, DNS host, nameserver setup, email provider, CDN provider, current records, and who approves changes.
Confirm launch approval
DNS changes can affect websites, email, tracking, and SSL. Confirm the launch window and rollback owner before changing records.
Use a portal
Kicklayer keeps domain access, hosting access, launch approvals, and technical constraints together so the project is not blocked by one missing registrar detail.
Plain-language access request
Use this as the human version of the ask before you turn it into a structured portal.
Registrar access should be requested carefully because domain, DNS, email, SSL, and launch changes can all intersect.
Fields worth separating
Separate fields help the client understand what you need and help your team see exactly what is still missing.
Registrar
Required access
Identify where the domain is registered and who can approve DNS changes.
Hosting
Required access
Request hosting panel, SFTP, database, staging, or collaborator access as needed.
DNS records
Required text
Collect important records for website, email, verification, CDN, and redirects.
Backups
Required text
Ask how backups work, where they are stored, and who can restore them.
Launch approval
Required approval
Name the person authorized to approve DNS, SSL, CDN, and go-live changes.
Safe access checklist
Use these checks before asking a client to grant access or share sensitive account details.
Domain
Confirm registrar, domain owner, and DNS manager.
Registrar, DNS, and hosting may be three different services.
Hosting
Share hosting panel, SFTP, database, staging, and backup details.
Launch and troubleshooting often need more than CMS access.
Identify email records and services that must not be disrupted.
DNS mistakes can break client email.
Security
Confirm SSL, CDN, firewall, and access restrictions.
Security layers can block deployment or verification.
Launch
Set launch window, rollback plan, and approval owner.
DNS changes should have timing and accountability.
Access request wording
The right wording protects the client relationship and reduces back-and-forth.
Do
- Ask who owns DNS before requesting changes.
- Document email-related records before launch work.
- Confirm backups and rollback process.
- Separate registrar access from hosting access.
Avoid
- Assume the hosting provider controls DNS.
- Change records without knowing email dependencies.
- Request shared owner passwords when collaborator access exists.
- Launch without a named approver and rollback path.
Why move access requests into a portal?
The same request becomes more reliable when every field has an owner, a status, and a place to submit it.
Domain, hosting, DNS, backup, and launch approval requests stay connected.
Clients can see which access details are still missing before go-live.
Your team has one place to review launch-critical infrastructure details.
Practical questions
What is the difference between domain and hosting access?
Domain access controls registration and often DNS. Hosting access controls website files, database, backups, and server settings. They may be separate accounts.
Should I ask for DNS records?
Yes, especially before launch or migration. Email, verification, CDN, and app records can be easy to break accidentally.
What should be confirmed before launch?
Confirm DNS owner, hosting access, backups, SSL, CDN, email records, launch window, rollback process, and final approval owner.