How to Ask Clients for Domain, DNS, Hosting, and CMS Access Safely

Quick answer

To ask clients for website access safely, do not ask them to paste passwords into email, chat, or a launch checklist. Request the specific access path you need instead: invite the agency as a user, create a temporary account, assign the minimum required role, ask the client's admin to complete the action, or use a secure password manager when credentials truly must be shared.

Best for

Website agencies that need domain, DNS, hosting, CMS, analytics, Search Console, ecommerce, or launch-day access without creating risky credential habits.

What to do next

1. List every system needed for launch and the exact task it supports.
2. Choose the safest access method for each system before asking the client.
3. Assign one client owner or Client Lead to route access requests internally.
4. Track access as a launch readiness item, not a vague "send logins" task.

Shipperly workflow: Use client launch checklist software to request access-related actions without collecting secrets. Shipperly can track who owns the request, what system is blocked, when it is due, and whether the client confirmed completion.

Why access requests become launch blockers

Website launches often stall because the agency does not have the right access at the right time.

The problem usually starts with a casual request:

Can you send over the website logins?

That sounds efficient, but it creates three problems.

First, the client may not know which login is needed. Domain registrar, DNS provider, hosting, CMS, ecommerce, analytics, Search Console, form tool, booking tool, and email routing can all feel like "website access" to a non-technical stakeholder.

Second, the client may forward sensitive credentials through an unsafe channel. A launch checklist, email thread, chat message, or project comment is not where passwords, API keys, private tokens, recovery codes, SSH keys, payment credentials, or backup codes belong.

Third, the agency still may not get usable access. A password might trigger two-factor authentication, belong to a former employee, lack permission to change DNS, or expose more systems than the agency needs.

Safe access requests are more specific. They ask for an action, a permission level, an owner, and a deadline. The goal is not to collect secrets. The goal is to get the launch task unblocked with the least risky path.

If access is one part of your broader go-live process, add it to your website launch checklist for agencies and review it before the final week.

What website access do agencies usually need before launch?

Website access means the permissions, accounts, invitations, confirmations, and admin actions needed to prepare, test, approve, and launch a website.

For most agency launches, access may include:

• Domain registrar access for nameserver or DNS ownership checks
• DNS provider access for A, CNAME, TXT, MX, SPF, DKIM, and verification records
• Hosting access for deployment, SSL, backups, redirects, and environment settings
• CMS access for content entry, QA, plugins, themes, permissions, and launch updates
• Ecommerce access for store settings, checkout, tax, shipping, and test orders
• Analytics access for GA4, Search Console, Tag Manager, pixels, or reporting tools
• Form, booking, CRM, or email marketing access for lead routing tests
• CDN, firewall, or security platform access for caching, SSL, WAF, or performance settings
• Client admin confirmation when the agency should not receive direct access

Not every agency needs every permission. The safer question is:

What is the minimum access or client action needed to complete this launch task?

That question keeps the request tied to launch readiness instead of turning into a loose credential hunt.

How to ask clients for website access safely

Use this workflow when requesting domain, DNS, hosting, CMS, analytics, or third-party platform access from a client.

1. Replace "send logins" with a task-specific request

Do not ask for "all website logins." Ask for the system, action, permission, and reason.

Weak request:

Please send domain and hosting logins.

Better request:

Please invite our launch admin to your DNS provider with permission to add and edit DNS records for the launch domain. We need this by Tuesday at noon to verify SSL and prepare the go-live records.

The better version tells the client what to do and why it matters. It also avoids asking them to paste a password into the wrong place.

2. Pick the safest access path

Most launch access requests should use one of these paths:

When a platform supports roles, use roles. When it supports collaborator accounts, use collaborator accounts. When the client has an IT team, let the right admin complete high-risk actions directly.

3. Use least privilege by default

Least privilege means giving someone only the access needed to complete the assigned task.

For a website launch, that might mean:

• DNS edit access without billing access
• CMS administrator access only until launch is complete
• Analytics read or edit access only where needed
• Search Console full user access instead of owner access when ownership is not required
• A temporary user account that can be removed after launch
• A client admin completing sensitive actions without handing over credentials

Least privilege is not about making the client's life harder. It makes the access request easier to approve because the ask is smaller, clearer, and safer.

4. Give the client a safe alternative when they cannot invite you

Sometimes the client cannot add users. Their plan may not support additional staff accounts. Their IT policy may block outside users. Their admin may be unavailable. Their platform may require the account owner to act.

In that case, do not lower the safety standard by asking them to paste credentials into the project thread.

Use one of these alternatives:

• Ask the client's IT or admin contact to complete the exact step.
• Schedule a short screen-share where the client stays logged in and performs the action.
• Ask for a temporary account that is deleted after launch.
• Use a secure password manager link with expiration and recipient restrictions.
• Move the task to launch-day client action if the agency should not touch the system directly.

The key is to keep secrets out of the launch checklist. Shipperly can track the request, the owner, the blocker, the due date, and the confirmation, but it should not be used as a credential vault.

5. Ask for confirmations, not secrets

Many access-related launch tasks do not require the agency to receive credentials at all.

Ask the client to confirm:

• Which provider manages DNS
• Who owns the domain registrar account
• Whether the agency has been invited
• Whether the requested DNS records were added
• Whether the CMS user was created
• Whether two-factor authentication is enabled
• Whether the old admin account should be removed after launch
• Whether the launch-day approver is available during the DNS window

Confirmations are safe to record in a launch workspace. Passwords, recovery codes, private keys, API tokens, and billing credentials are not.

Website access request template for agencies

Use this format for each access request:

Here are practical examples you can adapt.

Domain or DNS access request

Please invite our launch admin to the DNS provider for the launch domain with permission to add and edit DNS records. We need this by Tuesday at noon to prepare SSL, verification, and go-live records. Please do not paste domain, DNS, or registrar passwords into this request. If your IT admin prefers to make the changes directly, we can send the exact records instead.

CMS access request

Please create a temporary CMS user for our launch team with the role needed to edit pages, review settings, and complete launch QA. We need access by Thursday at 3 p.m. After launch, we will confirm whether the user should be removed or downgraded.

Hosting access request

Please add our launch lead as a collaborator or temporary user in the hosting platform with permission to review deployment settings, SSL, redirects, and backups. If collaborator access is not available, please assign your hosting admin to complete the requested steps and confirm when done.

Analytics or Search Console access request

Please add our agency email to the analytics or Search Console property with the minimum permission level needed to verify tracking and submit launch updates. If ownership access is not required, please avoid granting owner permissions.

Password manager fallback request

If this platform does not support user invitations or temporary accounts, please share the required credential through your password manager with an expiration date and recipient restriction. Do not send the password in email, chat, screenshots, or this launch task.

Safe website access checklist

Use this checklist before the final launch week.

This checklist should sit beside your content, QA, SEO, and approval work. Access is not a side task. It is one of the main reasons a site can be technically ready but still not launch-ready.

Common mistakes when asking clients for access

Asking for everything at once

"Send all logins" feels faster, but it makes the request harder for the client to route safely. Break access into system-specific tasks.

Treating credentials as normal project information

A password is not the same as a file, URL, or approval comment. Keep secrets out of project threads, launch portals, shared docs, and screenshots.

Requesting more permission than the task needs

If the agency only needs to add DNS records, it may not need billing, account ownership, or broad admin permissions. Narrower requests are easier to approve and easier to revoke.

Waiting until launch day

Access problems often reveal hidden blockers: the domain owner is unavailable, the account belongs to an old employee, two-factor authentication blocks sign-in, or the client does not know which vendor controls DNS. Ask early enough to fix ownership issues.

Forgetting to remove temporary access

Temporary launch access should have a cleanup plan. Decide who removes or downgrades agency users after go-live, and record that action as part of project completion.

How Shipperly helps agencies manage safe access requests

Shipperly is an AI launch coordinator for website agencies. It helps teams keep client-side website launch work moving without turning access requests into messy email threads.

For safe access workflows, agencies can use Shipperly to:

• Turn access needs into client-owned launch tasks
• Assign requests to a named client owner or Client Lead
• Track whether domain, DNS, hosting, CMS, and analytics access is ready
• Surface overdue, blocked, or unassigned access requests before go-live
• Draft follow-up messages for agency review when a client has not responded
• Keep the final launch approval record separate from informal comments

Shipperly should not be used to collect passwords, private keys, API tokens, recovery codes, or payment credentials. Use it to coordinate the work around access: who owns the request, what safer path is expected, when it is due, and whether the client confirmed completion.

That distinction matters. The agency gets launch visibility without teaching clients to paste secrets into another tool.

FAQ

Should an agency ask clients to send website passwords?

No. Agencies should avoid asking clients to send website passwords through email, chat, project comments, screenshots, or launch checklists. A safer request is to invite the agency as a user, create a temporary account, assign a scoped role, ask the client's admin to complete the action, or use a secure password manager when a credential truly must be shared.

What is the safest way to get DNS access from a client?

The safest DNS access path is usually a user invitation with permission to manage the required DNS records, or a client-admin workflow where the agency sends the exact records and the client's DNS owner makes the change. Avoid requesting full registrar owner credentials unless there is no safer alternative and the client uses a secure credential-sharing method.

What if the client does not know who owns the domain?

Treat it as a launch blocker. Ask the Client Lead to identify the registrar, DNS provider, billing owner, and technical contact. If ownership is unclear, resolve that before launch week because DNS control is often required for SSL, verification, redirects, and go-live changes.

Can clients paste passwords into Shipperly?

No. Clients should not paste passwords, API keys, private tokens, recovery codes, SSH keys, or payment credentials into Shipperly. Shipperly is for coordinating launch requests, ownership, blockers, follow-ups, and approval records. Secrets should stay in safer systems such as user invitations, temporary accounts, client-admin actions, or secure password managers.

When should agency access be removed?

Temporary access should be removed or downgraded after the launch work is complete, QA is finished, and the client has approved the handoff. Add the revoke or downgrade step to the post-launch checklist so it is not forgotten after the site goes live.

Safe access requests protect both sides of the launch. The client keeps control of sensitive systems, the agency gets the permissions or confirmations it actually needs, and the launch team can see which access issues still threaten go-live.

If you want that workflow to feel less like chasing and more like launch coordination, Shipperly can turn access requests, blocker status, owner assignment, reviewed follow-ups, and final approval into one client-facing launch process.