What Should You Ask Before Giving a Website Provider Access to Your Domain?

Ask what change is actually needed

Before a website supplier receives any domain access, ask them to name the exact change and why it is necessary. A request to verify ownership with one TXT record is different from transferring the registration, changing nameservers, moving the website or replacing email routing. Ask for the affected domain, record type, existing value, proposed value, intended result and expected timing. A vague request for complete account access is not a technical specification. Keep the business owner responsible for approving scope, and distinguish a request for advice from permission to make a live change. A small documented change can often be reviewed without surrendering the registration account.

Separate registration, DNS and hosting

A domain registration establishes the relationship between the registrant and registrar; DNS tells other systems where services are located; hosting provides the server or platform serving a website. These are related but separate responsibilities. A developer working on page layout may not need any registrar permissions. A technician configuring DNS may need access only to the authoritative DNS provider, which may be different from the registrar. Ask the supplier to identify each platform by name and explain which settings they intend to use. Confusing these layers can result in excessive access or an unnecessary provider migration disguised as a routine website update.

Confirm who the registrant is

The first ownership question is whose name or organisation appears as the registered domain holder under the applicable registry and registrar arrangements. An invoice paid by the business does not by itself establish that the registration account and registrant record are controlled by the business. ICANN explains that registrants have rights and responsibilities through their registrar, while MYNIC describes specific registrant and contact roles for .my domains. Request the current registration details through an authorised account or registrar statement, and confirm the correct organisation and authorised contacts. Do not assume a public lookup will reveal personal contact details, because privacy restrictions may hide them.

Understand the .my contact roles

MYNIC distinguishes registrant, administrative, technical and billing contacts. Its published managing-domain guidance describes the administrative contact as an authorised person able to act for the registrant and lists sensitive actions that may be available to that role. Technical contacts have different nameserver responsibilities, while billing contacts handle payment matters. Ask which role a supplier wants and whether the named person meets the relevant registry rules. Do not casually replace the company's administrative contact with an outside developer simply because a website needs updating. Record which individual can request changes, which party approves them and how the arrangement ends.

Use the least access that works

Ask whether the supplier can complete the work through a limited DNS role, a supervised change or a change request executed by the business's authorised administrator. Cloudflare documents account members, policies, roles and resource scopes, including domain-specific DNS permissions. Availability of equivalent delegation depends on the actual registrar and DNS provider, so do not promise that every panel supports the same controls. If a narrow role exists, prefer it over an account-wide administrator. If it does not, agree on a supervised procedure and document the temporary access boundary. Never share an owner password merely to avoid explaining the requested technical change.

Ask why a password is being requested

A request for the main registrar username, password and recovery codes deserves a specific explanation. Shared credentials can make it difficult to attribute actions, remove one supplier's access or protect account recovery. Ask whether the provider supports individual member accounts or a ticket-based change process. If an exceptional supervised login is unavoidable, have the authorised owner control the session and confirm what will be changed; do not send passwords through an ordinary email thread. Review account recovery methods and multifactor authentication with the actual registrar. The goal is accountable work, not creating an access bottleneck that prevents legitimate maintenance.

Protect the recovery route

Domain recovery may depend on the registrar's registered email address, telephone number, identity checks and multifactor methods. Ask whose contact information is recorded, who receives security alerts and what happens if a staff member leaves. The business should have a documented, authorised recovery route independent of a temporary website contractor. A supplier may legitimately help prepare technical evidence, but should not quietly become the only person who can reset the owner's account. Confirm backup administrators where the service permits them and store recovery procedures in an approved secure location. Never publish passwords, recovery codes or sensitive identity documents in the website project brief.

Identify the authoritative DNS provider

Before approving any DNS change, establish which provider actually serves the domain's authoritative nameservers. A hosting control panel can display a DNS zone even when the domain delegates authority elsewhere. Editing the wrong panel may have no public effect and can create confusion during troubleshooting. Ask the supplier to show the present nameserver delegation and identify the active zone. Record the current DNS provider separately from the domain registrar and website host. The cPanel Zone Editor documentation explains editing zone records, but access to that interface alone does not prove those records are authoritative for the domain. Verify the intended location before proceeding.

Inventory email records before website work

A domain commonly supports business email as well as a website. Before changing nameservers or importing a DNS zone, record the active MX, SPF, DKIM, DMARC and relevant mail host records, including provider-supplied values. Cloudflare's email troubleshooting documentation describes how missing or conflicting records can disrupt delivery or authentication. A developer focused only on web hosting may not know the company's email provider. Ask who owns the email service, who can validate its configuration and whether a proposed change touches mail routing. A new website must not be treated as permission to replace an existing mailbox service or remove records that look unfamiliar.

Distinguish a record edit from nameserver migration

Changing one DNS record and replacing authoritative nameservers carry different operational risks. A record edit affects a specific service mapping; a nameserver migration changes where the entire authoritative zone is served. Before approving the latter, request a complete inventory of existing records, an equivalent destination zone, verification steps and a recovery plan. Confirm who will monitor website and email behaviour after the change. Do not describe nameserver replacement as a harmless design adjustment. If the supplier cannot explain why a narrower change will not work, ask them to revise the technical proposal before granting broad permissions.

Ask whether any transfer is intended

A registrar transfer moves domain management between registrars and is not the same as changing web hosting or DNS. For generic top-level domains, ICANN explains that an Auth-Code is used in registrar transfers and that policy restrictions can apply. Rules for .my domains follow MYNIC's relevant processes, which should be checked separately. Ask the developer explicitly whether they intend to transfer the domain, change the registrant, change a contact or only update records. Require a written reason for any ownership or registrar change. Do not provide an authorisation code simply because a supplier says it is needed to launch a website.

Clarify who can approve high-impact changes

An account may technically permit actions that a project contract does not authorise. Distinguish permission to view DNS, propose a change, edit a specified record and alter domain ownership. Name the business decision-maker for each class of action and require approval to be recorded in the agreed project channel. For high-impact changes, specify a second reviewer if the organisation has the staff capacity. Avoid ambiguous statements such as the supplier can manage everything. A written responsibility matrix can identify the requester, implementer, approver and verifier. This helps prevent a successful login from being mistaken for business authorisation to change production services.

Agree on a written change record

For each authorised DNS task, record the domain, provider, zone, record name, type, old value, new value, TTL where relevant, reason, owner approval and intended verification. Keep timestamps and the person who performed the action. This record need not expose passwords or private keys. It should allow another technician to understand what happened without guessing from a screenshot. If several records change together, document their dependencies and the order of checks. A change log supports troubleshooting and later handover, especially when a business uses different suppliers for email, hosting and domain registration. Unrecorded changes are difficult to audit even when the website appears normal.

Prepare rollback before changing records

Ask what the supplier will do if the website stops resolving or email fails after a change. Save the original values and verify that someone authorised can restore them in the correct DNS panel. Understand that DNS caching and propagation mean reverting a record may not immediately restore every visitor's experience. Agree on a maintenance window appropriate to the business and an escalation contact for affected services. Do not promise zero downtime or instant rollback without evidence. The recovery plan should cover the exact changes proposed rather than a generic statement that backups exist. A website file backup alone does not preserve DNS settings.

Use a realistic example of limited access

Consider a hypothetical small retailer whose website supplier needs to add a TXT record to verify a new website service. The retailer's domain is registered with one company, while authoritative DNS is hosted with another. The supplier could provide the exact record details and evidence of the verification requirement. The retailer's authorised DNS administrator might then implement and confirm that one change without sharing the registrar's master password. This is a workflow example, not a claim that every DNS platform supports identical delegated roles. If the requested operation changes, the access decision should be revisited rather than silently expanded.

Check third-party account ownership

A website project may involve a registrar, DNS platform, hosting account, content system and external verification service. Ask whose email address owns each account, who pays renewals and which accounts the business can access independently. A supplier's own shared hosting account may be a legitimate commercial arrangement, but it is not equivalent to business ownership of the domain registration. Request a clear explanation of licences, account portability, data export and support boundaries. Do not assume that a vendor providing technical work is entitled to become the domain registrant. Record whether the arrangement is a managed service, a delegated administration service or a transfer of assets.

Set an expiry date for temporary access

Temporary supplier access should have a defined purpose, start, review date and end condition. Ask whether the platform permits individual invitations that can be revoked without changing the owner's credentials. Cloudflare's member-management documentation describes adding, editing and removing account members, but other services may use different processes. At handover, verify which invitations and roles remain active, including pending invitations. If credentials were exceptionally shared, agree on a controlled rotation and recovery check after work finishes. Do not remove access abruptly while an approved critical task is underway; coordinate the end of the work and preserve an audit trail.

Treat DNS changes as service changes

An A or AAAA record may direct website traffic; CNAME records can support services; MX records influence mail delivery; TXT records may carry verification and email authentication data. A developer who has permission to edit DNS can potentially affect more than the visual website. Ask the supplier to explain the impact of each record in ordinary language, and have the appropriate service owner review changes involving email or identity verification. Cloudflare's DNS and email guidance shows why seemingly small edits can have consequences outside the website. A domain is shared infrastructure, so a website redesign should not override unrelated service responsibilities.

Protect renewal and billing continuity

Domain expiry can affect services even if website development is otherwise complete. Ask who receives renewal notices, which account holds the payment method, whether renewal is automatic and how the business confirms successful renewal. Do not move billing contacts or account ownership merely to simplify a website supplier's work. For .my names, MYNIC describes billing and administrative roles separately; for other extensions, the registrar's contract and applicable registry rules govern. Record the renewal date and responsible owner in an internal inventory. Never present a supplier's quotation as proof that the domain has actually been renewed or that an invoice has been paid.

Agree on evidence of completion

A change is not complete merely because a supplier says the control panel was saved. Agree on observable acceptance evidence: the intended record appears from the authoritative source, the relevant website destination works, and unaffected business email continues functioning. Verification should match the scope and may require checks from different networks or tools because cached DNS answers can vary. Keep the approved before-and-after values and record any outstanding exceptions. Do not demand production changes simply to demonstrate a draft article. For a real project, separate technical implementation, independent verification and final business acceptance; each has a different responsible person.

Plan the supplier's exit before granting access

Ask what happens when the website project ends or the business changes suppliers. The handover should identify the domain registrar, authoritative DNS provider, current nameservers, authorised contacts, active DNS records, account roles and any outstanding renewal or support obligations. Agree who removes temporary access and who verifies that the business still controls recovery. If a provider managed DNS within its own account, discuss a documented migration path rather than assuming the zone can be exported without restrictions. A clear exit plan reduces dependence on one technician and helps a future supplier distinguish existing infrastructure from new work.

Keep a concise access-decision worksheet

Before approval, make a worksheet listing the exact domain, registrar, DNS provider, business registrant, requested action, required permission, approver, implementer, evidence and access expiry. Add a column for possible effects on website, email and other services. Mark unknown items as questions, not assumptions. This worksheet can accompany a supplier quote or change ticket without disclosing credentials. If the supplier requests a broader role than the action requires, ask for a narrower method or a specific justification. The worksheet helps a small business make a proportionate decision without pretending that every domain provider has identical administrative features.

Know when to postpone the request

Delay access when the supplier cannot identify the requested action, the business cannot confirm registrant control, email dependencies are unknown or the proposed change lacks a recovery plan. This is not a rejection of necessary technical work; it is a request for missing information before an irreversible or high-impact step. A provider should be able to explain its scope, dependencies and verification method in terms the owner can approve. When those facts are clear, authorise only the bounded work and retain the evidence. The most useful outcome is a website project that can proceed without sacrificing domain control, email continuity or future portability.

Sources & further reading

• ICANN: Information for domain name registrants
• ICANN: Auth-Code overview
• ICANN: Registrar transfer FAQs
• MYNIC: Managing a domain and contact roles
• MYNIC: .my registrant agreement
• Cloudflare: Manage account members
• Cloudflare: Account and domain roles
• Cloudflare: Email DNS troubleshooting
• cPanel: Zone Editor