Business domain, hosting and email: keeping access and renewals under control

For every critical service, the business should know where it was ordered, who controls the account, how access can be recovered and when payment is next due. A developer can handle technical work while someone in the company oversees access and billing.

Make the check concrete: an authorised person signs in with their own account and can see the correct domain or project, their permissions and the service status. A password for the content editor does not automatically give control of the domain, hosting or email.

Agree this when commissioning a business website, alongside the development scope and handover arrangements. If the website is already live, start by recording what exists without changing settings.

One company may sell all these services, or several providers may be involved. Separate their roles when managing them: renewing one service does not necessarily renew the others.

The content editor, backups and search tools may have accounts of their own. Add them to your map when they are part of the project; there is no need to buy another system just to fill a row in a checklist.

When creating accounts, agree who in the company will manage them. Contact details should be current and important notices should reach that person. If a service is already in a contractor’s shared account, first check whether the provider supports separate access or a transfer.

• Verify access to the actual domain, hosting project and email administration panel.
• Separate billing, technical settings and content editing. One person does not always need every permission.
• Invite the contractor as a separate user with the required role where the service allows it.
• Record who will revoke access when the work ends and how this will be done.

Keep service names, account URLs, roles and contacts in the register. Store passwords and secret keys in an agreed secure vault, rather than an open spreadsheet. Discussing a new website or obtaining an initial estimate does not require sharing secrets.

Check the recovery path before you need it: who controls the backup address, second factor and alternative sign-in method? Email on the same domain should not be the only way to recover its registrar account, because a domain problem could also interrupt that channel.

Protect administrative accounts with two-factor authentication and prepare the recovery methods the service supports. For example, Google Workspace’s administrator guidance covers recovery contacts, spare security keys and backup codes. The available options depend on the provider.

Agree which authorised person acts when the main administrator is away. The instructions can explain how to obtain emergency access without distributing the codes to the whole team. Do not disable protection or lock a working account just to test the process.

Build a calendar for the services you actually use: expiry or next charge date, billing period, payer, invoice recipient and person who checks completion. Account for the renewal price after any introductory period and the conditions for plan changes.

ICANN recommends tracking registration expiry and keeping payment details current. Auto-renewal, where available, can handle payment, but you still need to check the outcome. Ask your registrar about the rules for your particular domain extension.

• Set your own reminder in advance, for example a month ahead; this is a working buffer, not a universal provider deadline.
• Check where invoices and failed-payment notices are sent.
• After renewal, confirm the new expiry date or paid period in the account.
• When the payer or card changes, update every service using those details.

Keep recurring expenses separate from the build budget. The guide to website development and running costs explains how they fit into an estimate. Paying for a domain or hosting does not, by itself, mean someone is checking enquiries.

Moving hosting and changing email providers are different jobs. Before DNS changes, ask the person doing the work to record the existing entries and explain which support the website, email and connected services. Do not delete unfamiliar records just because they do not look like the website address.

Cloudflare’s email record documentation explains MX for receiving mail and SPF, DKIM and DMARC for authentication. Use the settings supplied by your actual email provider; there is no universal set of values for every website.

After agreed changes, test three separate actions: receiving a message from another mail system, replying from the business mailbox and submitting a website enquiry. A thank-you page does not establish that the manager received the message. Label test enquiries in advance.

A working domain and stable website also support accessibility to search engines. Page, indexing and language checks are covered in the guide to SEO before website launch. Managing infrastructure does not replace useful content or understanding search demand.

Imagine a small furniture repair studio. This is a teaching example, not an XEVOR case study. Each year the contractor sends one invoice “for the website”, while the owner can only sign in to a mailbox. Before the next renewal, nobody is sure which services are paid for or who can change billing details.

The team breaks down the invoice: the domain renews with a registrar, a separate platform hosts the website and email is billed by user. The owner gets the agreed account permissions, the bookkeeper receives invoices and the contractor has a technical role. Each service has a payment date and a contact for problems.

This does not necessarily require changing providers. First make the current arrangement clear and verify that the business can manage it. If separate access is unavailable, agree any transfer process and costs as a task of its own.

• A service list with account URLs and the correct project names.
• Responsible people in the business, their roles and verified sign-in access.
• Invoice delivery, payer, upcoming dates and payment confirmation process.
• Account protection and a recovery path that does not depend solely on the contractor.
• Backup location and the person responsible for restoring the website.
• Website, email and form checks after launch or configuration changes.
• A contact for problems and the scope of ongoing support.

Regular checks, incident response and new development need their own agreement. Read what website support includes for the broader scope. This checklist does not mean every task is automatically included in a website build.

Planning to commission a business website? We can discuss access and launch alongside its structure and features. For an existing website, we assess technical support after reviewing the platform and the work needed.