How to Point a Domain to Your Hosting Provider, Website Builder, or Server

Overview

Before you change anything, it helps to separate three related but different parts of the stack:

• Domain registrar: where the domain is registered.
• DNS host: where the DNS zone is managed.
• Hosting provider or platform: where the website, app, or service actually runs.

Sometimes one company handles all three. Often they do not. That is why “connect domain to website” can mean different actions depending on your setup.

Here is the simplest rule:

• Use nameservers when you want another provider to manage the entire DNS zone.
• Use an A record or AAAA record when you want a domain or subdomain to point directly to a server IP.
• Use a CNAME record when a provider tells you to point one hostname to another hostname, which is common with website builders, SaaS tools, and service subdomains.

If you are still fuzzy on the record types, see DNS Records Explained: A, AAAA, CNAME, MX, TXT, NS, and SRV. If your change seems correct but the site still does not load, the next thing to check is propagation; this guide can help: DNS Propagation Time Guide: How Long Changes Take and How to Check.

Before any DNS edit, gather these details in one place:

• The domain you are connecting.
• Whether you need the root domain, www, or both to work.
• Your hosting provider’s exact DNS instructions.
• Any current records for email, verification, or other services you must preserve.
• Whether SSL will be handled by the host, builder, reverse proxy, or CDN.

If you only remember one thing from this article, make it this: do not replace DNS records until you know what else depends on the zone. A working website can be restored quickly; broken email is usually more disruptive.

Checklist by scenario

This section gives you reusable steps for the most common domain to hosting setup paths. Pick the scenario that matches your provider’s instructions rather than guessing from memory.

Scenario 1: Point the entire domain by changing nameservers

Use this when your hosting company, CDN, or managed DNS provider tells you to replace the domain’s current nameservers with theirs. This is common when a provider wants to control the full DNS zone.

1. Find the current nameservers. They are usually visible in your registrar account.
2. Export or copy the existing DNS zone first. Save A, AAAA, CNAME, MX, TXT, and any special records. This is your rollback reference.
3. Verify whether the new provider will import existing records automatically. Many do not, or they import only partially.
4. Recreate required records in the new DNS zone before switching nameservers. Pay special attention to email-related records such as MX, SPF, DKIM, and DMARC if you use custom email.
5. Update the nameservers at the registrar. Replace the old set with the exact values provided.
6. Wait for propagation. During this period, some users may still hit the old DNS.
7. Test the root domain and www separately. Some providers configure one but not the other by default.
8. Check email, verification records, and redirects. A website that works does not guarantee the rest of the zone is correct.

This is the cleanest option when you want one provider to manage everything, but it is also the easiest way to accidentally break unrelated services if you forget to copy records over.

Scenario 2: Point a domain or subdomain to a server using A and AAAA records

Use this when you have a VPS, dedicated server, cloud instance, or a hosting provider that gives you a fixed IP address. This is the classic answer to “how to point domain to server.”

1. Get the server IP address. You may have an IPv4 address, an IPv6 address, or both.
2. Decide which hostnames should point there. Common choices are @ for the root domain and www as either a CNAME or its own A record.
3. Create or update the A record. Point the root domain to the IPv4 address.
4. Create or update the AAAA record if you use IPv6. Only add it if the server is configured for IPv6.
5. Set the www hostname. In many setups, www is best as a CNAME to the root or to the provider’s preferred hostname.
6. Confirm the web server is configured for the domain. DNS can be correct while Nginx, Apache, or the application still serves the default site.
7. Install or provision SSL. A DNS change alone does not enable HTTPS.
8. Test both HTTP and HTTPS. Confirm the correct certificate is served for both the root and www.

This method gives you granular control because you keep DNS where it is and change only the records you need. It is often the safest choice if you already have working email or multiple services under the same domain.

Scenario 3: Connect a domain to a website builder using CNAME and related records

Use this when a site builder or SaaS platform asks you to verify the domain and point either www or a subdomain to a platform hostname. This is a common pattern when you need to connect domain to website builder platforms.

1. Read the provider’s instructions carefully. Builders often require one record for connection and another for verification.
2. Identify whether they want the root domain, www, or a subdomain. This matters because CNAME records generally work best on subdomains like www, while root domain handling varies by DNS provider.
3. Add the required CNAME record. For example, www may point to a hostname controlled by the builder.
4. Add any verification TXT or CNAME record. Some platforms need a separate token before the connection is approved.
5. Set up the root domain redirect if needed. Many builders prefer the root domain to redirect to www or vice versa.
6. Wait for the platform to detect the DNS. The connection panel may take time to refresh.
7. Enable SSL inside the builder dashboard if it is not automatic.
8. Check canonical hostname behavior. Make sure the site consistently resolves to either the root or www, not both as separate versions.

Website builders usually document these steps well, but the common failure point is trying to force a root-domain CNAME where the DNS host does not support the provider’s method. If the instructions mention ALIAS, ANAME, flattening, or provider-managed root mapping, follow that exact route.

Scenario 4: Keep DNS at the registrar but move only the website

This is one of the most practical scenarios because it minimizes risk. You might be moving from one host to another while keeping the registrar and email unchanged.

1. Leave nameservers as they are.
2. Change only the web-related records. Usually the A record for the root and the CNAME or A record for www.
3. Do not touch MX, TXT, or unrelated subdomains.
4. Lower TTL in advance if your DNS host allows it. This can make future changes take effect faster.
5. Test on the new host before changing DNS. Use a temporary URL, hosts file, or provider preview method if available.
6. Update DNS during a low-traffic window.
7. Keep the old hosting active until traffic and content have fully switched over.

If you are buying a domain for a new project rather than migrating an existing one, these setup decisions are easier when made early. Related reading: How to Buy a Domain Name: Beginner Checklist Before You Register, Best Domain Extensions for Business, Blogs, Stores, and Personal Sites, and Best Domain Registrars Compared: Pricing, Privacy, Transfers, and Renewal Fees.

What to double-check

Once your DNS changes are in place, use this short review list before you call the setup done.

• Root domain and www: Verify both resolve as expected. Decide which one is primary and redirect the other.
• Old conflicting records: Remove stale A, AAAA, or CNAME entries that point to the previous host. Mixed records create inconsistent behavior.
• TTL settings: Very high TTL values can make changes feel stuck for longer than expected.
• Email records: Confirm MX, SPF, DKIM, and DMARC were not overwritten during the domain to hosting setup.
• SSL status: HTTPS should load without certificate warnings on all expected hostnames.
• Provider verification: Some platforms require you to click a confirmation step after DNS is visible.
• Redirect logic: Make sure HTTP goes to HTTPS and non-primary hostnames redirect cleanly.
• Server virtual host or application config: The backend must know which domain it is serving.
• CDN or proxy settings: If you use Cloudflare or another layer in front of the host, check whether records should be proxied or DNS-only for the service you are connecting.

One especially common confusion is nameservers vs DNS records. If you changed nameservers, you must manage records at the new DNS host. Editing old records at the registrar will do nothing once the nameserver delegation has moved.

If pricing or provider lock-in is part of your decision process, it is also worth reviewing renewal and transfer implications before centralizing domain and hosting at one company. This background guide may help: Domain Name Cost Guide: Registration, Renewal, Transfer, and Hidden Fees.

Common mistakes

Most DNS errors are not hard to fix, but they are easy to create. These are the patterns that cause the most trouble during launch.

• Replacing nameservers when only a record change was needed. This can break email and third-party tools.
• Adding a CNAME at the root without checking DNS host support. Not every provider handles apex aliasing the same way.
• Leaving multiple A records from old and new hosts. Visitors may land on different servers depending on resolver behavior.
• Forgetting the www hostname. A site can appear half-broken when only one hostname is configured.
• Ignoring SSL until after DNS changes. The domain points correctly, but browsers still show warnings.
• Assuming propagation is instant everywhere. Some networks update quickly; others take longer.
• Editing the wrong DNS panel. This happens often after a nameserver move.
• Removing TXT records that look unimportant. Those records may control email authentication, ownership verification, or security settings.
• Pointing DNS before the application is ready. The domain resolves, but users see a default server page, installer screen, or 404.

A simple way to avoid most of these issues is to work from a pre-change checklist rather than from memory. Write down what must keep working, what will change, and where each DNS edit should be made.

When to revisit

Domain connections are not a one-time task. Revisit this setup whenever one of the underlying inputs changes.

• When you migrate to a new host or server.
• When you add a CDN, reverse proxy, or website builder.
• When you move DNS to a different provider.
• When you launch custom email or change email hosting.
• When SSL stops renewing or hostnames no longer match the certificate.
• Before major seasonal traffic periods or product launches.
• After registrar, hosting, or platform workflow changes.

For a practical recurring habit, keep a small domain connection record for every project:

1. List the registrar, DNS host, and hosting provider.
2. Record the active nameservers.
3. Save a copy of the DNS zone.
4. Note which hostname is canonical: root or www.
5. Document where SSL is managed.
6. Document where email is hosted and which records it depends on.
7. Review the setup before any migration or launch window.

If you treat domain pointing as a documented system rather than a one-off change, launches become calmer and rollbacks become much easier. That is the real goal of a good domain hosting guide: not just getting a site online once, but making future changes predictable.