Who should own your domain, hosting, and business email?

A website can look entirely owned by a business while its essential accounts belong to a former employee, freelancer, or agency. The problem becomes visible only when a renewal fails, email stops, a supplier relationship ends, or an urgent change requires access nobody can find.

Ownership does not mean the business must perform every technical task. It means the organization holds the durable account, billing visibility, recovery route, and authority, while trusted specialists receive the access they need to operate the system.

Keep the domain under organizational control

The domain is the address on which the website and often the email system depend. Register it in an account controlled by the organization, using a role-based business address rather than one employee's personal inbox.

Record the registrar, account owner, renewal date, payment method, and recovery process. Enable multi-factor authentication and keep recovery codes in an approved secure location. Turn on automatic renewal, but do not treat it as the only control; expired cards and missed messages still happen.

A supplier can manage DNS and renewals through delegated access. They do not need to become the legal registrant or sole account holder. Check that registration contact details are accurate and that any privacy service does not prevent the business from proving control.

Understand where DNS is managed

DNS connects the domain to the website, email, verification records, and other services. It may be managed at the registrar, hosting provider, a security platform, or another DNS service.

Document the authoritative provider and nameservers. Keep a current export or record of important entries. A careless nameserver change can disable both the website and business email even if neither service itself has failed.

Limit editing access, use named accounts, and review changes. Before a migration, lower relevant record lifetimes only when needed, copy all existing records, and plan rollback. Do not delete unfamiliar email or verification entries merely because they are unrelated to the website.

Put hosting in the right account

Hosting runs the website or application. For a business-critical system, the organization should normally be the account owner or have a clearly documented contractual right to the deployed application, data, configuration, and transfer.

The supplier may manage deployments and technical settings. Use team roles instead of sharing one password. Ensure billing notices and service incidents reach more than one responsible person.

Understand what can be exported. A static site, custom application, managed builder, and proprietary agency platform have different portability. Ask where the source code lives, whether the database can be exported, which services are required, and what handover would involve.

Treat business email as a separate critical service

Email may use the domain but is not the same as website hosting. Moving the website should not require moving mail, and changing DNS without copying mail records can interrupt delivery.

The organization should own the email tenant, administrator roles, billing, user lifecycle, security policies, and recovery. Use at least two carefully protected administrators where the provider allows it. Personal addresses should not be the only recovery route.

Document mail exchange, sender-policy, signing, and reporting records. These controls help legitimate messages arrive and make domain impersonation more difficult. Configuration should be based on the actual sending services rather than copied blindly from a template.

Own analytics and business listings

Analytics, search tools, maps, advertising accounts, tag managers, business profiles, consent platforms, and social properties often outlive a website build. Create them under the organization and invite partners with the minimum role required.

Do not let a supplier place multiple clients inside an account that cannot be separated later. Confirm which historical data remains available after access changes and whether the organization can add or remove users independently.

For Google Business Profile and similar listings, keep primary ownership with the organization. Agencies and staff can be managers. Review old access when roles change.

Define ownership of code, design, and content

A contract should explain the rights to custom source code, design files, written content, photography, licensed assets, fonts, and third-party components. “You own the website” is too broad without these distinctions.

Open-source dependencies remain under their licenses. Stock assets and fonts may have usage restrictions. A supplier's reusable tools may remain theirs while the client receives a license to use the delivered system. Custom project work may transfer after final payment, depending on the agreement.

Store source code in a repository with organizational access when appropriate. Keep installation, environment, deployment, and backup documentation proportional to the system's complexity. Never place passwords or secret keys in the repository.

Use delegated access instead of shared passwords

Most modern services support members, roles, or collaborators. Give each person a named account and only the permissions needed. This creates accountability and allows access to be removed without changing credentials for everyone.

Use a business password manager for services that cannot delegate. Protect administrator accounts with phishing-resistant multi-factor authentication where possible. Do not send passwords, recovery codes, or secret keys through ordinary email or chat.

Review access at project completion and periodically afterward. Remove former staff and suppliers, rotate shared secrets, and confirm that active owners can still recover the accounts.

Build a simple digital asset register

The register can be a protected table containing the service, purpose, web address, business owner, technical manager, billing owner, renewal date, recovery method, data classification, and handover notes. It should point to the password manager, not contain passwords.

Include the domain, DNS, hosting, repository, email, form delivery, database, storage, analytics, search tools, maps, advertising, consent, newsletter, booking, payment, and licensed media. Record key dependencies: the contact form may rely on an email provider, for example.

Review the register before renewals, staff departures, supplier changes, and major launches. Assign responsibility rather than assuming “IT” or “the agency” will remember.

Plan handover before it is needed

A clean handover includes an account inventory, role changes, code and data export where applicable, deployment instructions, outstanding renewals, known issues, backup status, and a short period for questions. Verify access by signing in through the organization's own account.

Do not wait for a disputed relationship or outage. Include handover expectations in the original proposal and contract. Agree which assistance is included and which migration work is separately estimated.

The healthy model is simple: the business owns durable assets and recovery, specialists manage technical work through appropriate access, and responsibilities are documented. This structure reduces dependency without excluding expert help. It also turns supplier changes, staff transitions, and renewals from emergencies into manageable operations.