Website Hosting vs. Domain vs. DNS: Who Controls What?

A business website can look like one thing from the outside. You type in yourcompany.com, the website appears, and that seems simple enough. Yay!

But, behind that address, several different services may be involved. Your domain could be registered with one company, DNS managed somewhere else, website hosted by another provider, email running through Google or Microsoft, and the actual website managed in WordPress, Wix, Squarespace, Shopify, or another platform.

This setup is completely normal. However, the problem starts when nobody knows which company controls which piece.

Then the website goes down, email stops arriving, a developer leaves, the organization wants to migrate platforms, or somebody discovers the domain is registered under an account belonging to a former contractor.

First: What Is A Domain?

A domain name is the address people use to find you online, such as byraeform.com.

You register a domain through a domain registrar. Registrars manage domain registrations and communicate with the registry responsible for the domain extension, such as .com, .org, or .net.

ICANN accredits many registrars for generic top-level domains and maintains information about the registration ecosystem. Your registrar might be a company such as GoDaddy, Namecheap, Squarespace Domains, Cloudflare Registrar, or another provider.

Registering a domain does not automatically mean that company hosts your website.

This is one of the first places people get confused.

You could register example.org through Namecheap and host the website on Vercel. You could register through GoDaddy and use Wix for the website. Your nonprofit could own a .org registered through one company while its email runs through Google Workspace.

The domain is the address but it is not necessarily the building sitting behind the address.

Who Should Control The Domain?

The organization should.

That sounds painfully obvious until you look at how many domains are registered using a developer's personal email address, an agency account, a former employee's login, or the founder's old Gmail account that nobody checks anymore.

If a freelancer is building your website, they may help configure the domain. That does not mean the domain should permanently belong to the freelancer.

Your domain affects far more than whether visitors can reach your homepage. Depending on your setup, losing control of it can affect your website, organizational email, verification records, subdomains, and other services connected to it.

At minimum, the organization should know:

• which registrar holds the domain

• which organization-controlled account owns or administers it

• when the registration renews

• whether auto-renewal is enabled

• which payment method is attached

• who can access the registrar

• whether multifactor authentication is enabled

• which contact information is associated with the registration

ICANN specifically advises registrants to maintain accurate contact information with their registrar because those details can be necessary for account and domain-related communications.

A domain may cost you fifteen or twenty dollars a year. Losing control of it can cost considerably more.

Then, What Is Website Hosting?

Hosting is where the files, code, database, or application powering your website actually run.

Think about a traditional WordPress site. The domain might be example.com, but the WordPress installation could live on a server operated by SiteGround, WP Engine, Kinsta, Hostinger, or another hosting provider.

Modern websites make this even more varied.

A Next.js site might run on Vercel. An ecommerce store might run entirely through Shopify. Wix and Squarespace combine much of the website builder and hosting experience into their platforms. A web application may have the frontend hosted in one place while its database, file storage, and other services live somewhere else.

So when someone tells you, “We host the website,” ask what they mean.

• Do they host the actual website?

• Do they merely manage the hosting account?

• Is the website running under their agency account?

• Does your organization have its own login?

• Can the website be transferred if the relationship ends?

Those answers become much more relevant the day you decide to switch providers.

Your Domain Can Work Perfectly While Your Hosting Is Broken

This is useful to understand when troubleshooting.

Suppose example.org is registered and active for another eight months. Nothing is wrong with the domain itself.

But the hosting subscription expires. Visitors may now see an error instead of your website. Does the domain still exist? Yes. It is simply pointing toward a service that is no longer serving the site properly.

The opposite can happen too. Your hosting server may be running perfectly, but if the domain expires or DNS records are changed incorrectly, visitors may no longer be able to reach it using your normal address.

Okay, So What The Hell Is DNS?

DNS stands for Domain Name System.

If the domain is the address and hosting is where the website lives, DNS is part of the system that tells internet traffic where that address should go.

When someone visits your domain, DNS records help direct their request to the correct service. Those records can control more than your website.

They can also help direct:

• business email

• subdomains

• verification services

• third-party applications

• certain security and authentication services

For example, your DNS configuration may contain an A record pointing your domain toward a server, a CNAME record connecting one hostname to another, and MX records telling email systems where mail for your domain should be delivered.

TXT records are commonly used for things such as domain verification and email authentication.

You do not need to memorize all of these records to own a website. But, you do need to know where they are managed.

Your DNS Provider May Not Be Your Domain Registrar

You can register a domain with one company and manage its DNS somewhere else.

For example, your domain could be registered with GoDaddy while its authoritative nameservers point to Cloudflare. In that case, you might log into GoDaddy to renew or transfer the domain, but log into Cloudflare when you need to change the active DNS records.

In a scenario like:

“Can you update the DNS?”

“I logged into the domain account and the records aren't there.”

“Check Cloudflare.”

“Who has the Cloudflare login?”

“…I thought you did.”

will let you realize how, at this point, you have an operations problem.

Nameservers Tell You Where DNS Authority Lives

Nameservers are one of the clues you can use when figuring out a domain setup. They tell the broader DNS system which servers are authoritative for your domain's DNS information. If your nameservers point to Cloudflare, for example, the active DNS records are generally being managed through Cloudflare. If they point to your registrar's nameservers, DNS may be managed there instead.

Changing nameservers is a powerful action because you are effectively changing where the internet goes to ask for your domain's DNS information.

Just because a tutorial from 2019 told you to copy and paste something means you have to do so. Do not change it for the love of the game.

Hello There, CMS

A content management system, or CMS, is the software you use to manage the website itself.

WordPress is a CMS, and so are platforms such as Drupal. Other hosted website platforms blur the lines because the CMS, hosting, and other website infrastructure may come together as one service.

Your CMS login controls what happens inside the website. It does not necessarily control the domain. Businesses frequently believe they own everything because they can log into WordPress.

You could be a WordPress Super Admin and still have absolutely no access to:

• the domain registrar

• DNS

• hosting

• CDN settings

• email records

• billing

• server backups

Similarly, somebody could control the domain without having any WordPress access at all. Both forms of access are powerful, but they control different parts of the infrastructure.

A Simple Example

Imagine Raccoon Coffee Co. has the following setup:

Now imagine the website breaks.

If the Vercel deployment failed, changing something at Namecheap probably will not help. If the domain expired, rebuilding the Vercel deployment will not fix the domain. If somebody removed the Google Workspace MX records in Cloudflare, the website might work perfectly while business email stops receiving messages.

Same domain, different systems. Knowing the structure dramatically shortens the troubleshooting conversation.

What Happens When You Change Web Developers?

Suppose your current developer manages the website and you decide to work with somebody new.

What needs to move? Maybe nothing except access. Or maybe the developer created everything under accounts they own.

Before ending the relationship, confirm who controls:

• the domain registrar

• DNS provider

• hosting account

• CMS

• website repository or source code

• database

• media and file storage

• CDN

• analytics

• Google Search Console

• Google Tag Manager

• email provider

• third-party integrations

• backups

Do not assume “website transfer” automatically includes all of this.

Ask.

If the agency pays for hosting through its master account, find out whether the site can be transferred into your own account. If they registered the domain for you, confirm that your organization is actually in control of the registration account.

What Happens When You Change Hosting Providers?

Changing hosting does not automatically require changing your domain registrar.

You might keep the exact same domain registration and simply update DNS so the domain points toward the new hosting environment.

For example:

Before migration:
example.com → DNS → Old host

After migration:
example.com → DNS → New host

The domain stays the same. Visitors may never know anything changed.

Website migrations can still involve other technical work, especially databases, files, redirects, SSL certificates, caching, email configurations, and application settings. But “we are moving the website” does not necessarily mean “we are transferring the domain.”

Please establish which one somebody means before approving anything.

Be Extremely Careful With Email DNS Records

This deserves its own warning because website work can accidentally break business email.

Your domain's DNS records may contain the settings your email provider depends on.

If someone changes nameservers or replaces the entire DNS configuration during a website migration without preserving the existing email records, your new website might work beautifully while your inbox suddenly stops receiving mail.

MX records are particularly relevant to mail delivery. Other records such as SPF, DKIM, and DMARC can also be involved in email authentication and deliverability.

So when moving DNS, do not copy only “the website records.”

Review the entire DNS zone first.

If your organization uses Google Workspace, Microsoft 365, Zoho Mail, or another email provider, make sure the required records survive the change.

Who should actually have access?

Not everybody needs access to everything.

A content editor might need CMS access but have absolutely no reason to touch DNS. A developer may need hosting and DNS access while working on a deployment. An operations lead may need administrative control over the registrar because renewals and organizational ownership fall within their responsibilities.

The founder or executive director may need backup control over critical infrastructure without personally managing it every day.

For example:

Your exact setup will vary. The point is that access should follow responsibility, not convenience.

Make a website ownership record.

Create an internal record containing:

• Domain registrar:
  Where the domain is registered.

• Domain owner/account:
  Which organization-controlled account manages it.

• Renewal date:
  And whether auto-renewal is enabled.

• DNS provider:
  Where active DNS records are managed.

• Hosting provider:
  Where the website runs.

• CMS:
  Where website content is managed.

• Email provider:
  Google Workspace, Microsoft 365, Zoho, etc.

• Primary administrator:
  Who manages the system.

• Backup administrator:
  Who can recover or take over if needed.

• Billing owner:
  Who handles payment and renewal.

• Developer/agency access:
  Who currently has external access.

• Last access review:
  When somebody last confirmed all of the above.

Do not put your passwords in this document. Use a password manager for credentials. The record tells you where the keys are. The password manager protects the actual keys.

Before Touching Anything, Know What You Are Changing

If someone tells you, “We need to move your domain,” ask whether they actually mean the domain registration, DNS, hosting, or website. If someone asks for “website access,” ask what access they actually require. If your email stops working after a website change, check DNS before assuming your email provider randomly broke at the exact same time.

And if your organization cannot currently answer who controls its domain, DNS, and hosting, figure that out before the next redesign, migration, contractor transition, or emergency forces you to.

Your website may look like one thing to your customers, but behind it are several different systems, and somebody inside the organization should know exactly who controls each one.

And if you find yourself in trouble, you know where to reach out.