How to Point a Domain to a Web Host: Nameservers vs A Records vs CNAME

Overview

If you want to connect a domain to web hosting, the first step is not editing DNS. The first step is deciding who should control DNS and what exactly you are pointing.

In practical terms, you usually have three common choices:

• Nameservers: You delegate the entire DNS zone to another provider, usually your web host or a DNS platform.
• A record: You point a hostname, often the root domain, to an IPv4 address.
• CNAME: You point one hostname to another hostname, commonly used for www or service-specific subdomains.

The right option depends on your setup, not on which button looks easiest.

Use this rule of thumb:

• Choose nameservers when you want one provider to manage the whole DNS zone.
• Choose an A record when your host gives you a server IP and you want to keep DNS at your registrar or DNS provider.
• Choose a CNAME when your provider tells you to point a hostname to another hostname instead of an IP.

It also helps to separate the domain into the hostnames people actually use:

• Root domain: example.com
• WWW host: www.example.com
• Other subdomains: app.example.com, blog.example.com, shop.example.com

Many setup mistakes happen because someone points only one of these and assumes the others will follow automatically.

Before making changes, gather these details from your host:

• The preferred connection method: nameservers, IP address, or target hostname
• The exact DNS values to enter
• Whether both the root domain and www should resolve
• Whether email is hosted somewhere else and must keep existing MX records
• Whether SSL will be provisioned automatically after DNS is correct

If you are also moving the site itself, not just DNS, it is worth reviewing a migration plan before cutover. See How to Migrate a Website to a New Host: Pre-Move Checks, DNS Cutover, and Rollback Plan.

Checklist by scenario

This section helps you choose the right DNS method based on the hosting situation in front of you.

Scenario 1: Your web host tells you to change nameservers

This is common with shared hosting, some managed WordPress hosting plans, and all-in-one platforms that want to manage DNS for you.

Use nameservers when:

• Your host provides two or more nameserver values such as ns1.provider.com and ns2.provider.com
• You want the hosting company to control your full DNS zone
• You are comfortable recreating or verifying all existing DNS records at the new DNS provider

Checklist:

1. Log in to your registrar, not just your host.
2. Find the domain’s nameserver settings.
3. Replace the current nameservers with the ones provided by the host.
4. Save the change.
5. At the new DNS provider or host, confirm the zone includes required records for the website, email, verification, and any other services.
6. Check whether the root domain and www are both configured.

Main advantage: simple ongoing management if you want hosting and DNS in one place.

Main tradeoff: you are moving all DNS control, not just the website. If you use third-party email, custom subdomains, or verification records, those must still exist after the change.

Scenario 2: Your host gives you an IP address

This is common with VPS hosting, cloud hosting, dedicated servers, and some traditional website hosting plans.

Use an A record when:

• Your host gives you an IPv4 address
• You want to keep DNS with your registrar or a separate DNS provider
• You only need to point selected hostnames rather than move the full zone

Checklist:

1. Open your DNS management panel where the zone is currently hosted.
2. Create or edit the A record for the root domain, usually represented as @.
3. Enter the server IP provided by your host.
4. Create or update the www record according to host guidance. This may be another A record or, more commonly, a CNAME pointing to the root domain.
5. Remove old conflicting A records for the same hostname.
6. Save changes and test resolution after propagation.

Main advantage: you keep full control of DNS and can point email, subdomains, and other services independently.

Main tradeoff: you are responsible for managing the records correctly.

Scenario 3: Your host gives you a target hostname

This often happens with SaaS platforms, managed application hosting, CDNs, and some modern cloud website platforms.

Use a CNAME when:

• You are pointing a subdomain such as www, app, or docs
• Your provider tells you to point to a hostname like site.hostplatform.net
• You want the destination to stay flexible even if the provider changes backend IPs

Checklist:

1. Create or edit the CNAME for the required hostname.
2. Set the value to the exact target hostname provided by the service.
3. Do not combine a CNAME with other record types on the same hostname unless your DNS provider explicitly supports special handling.
4. Confirm the service is expecting that hostname and, if required, complete domain verification.
5. Set up redirects so users land on the preferred version of the site.

Main advantage: the provider can manage infrastructure changes behind the target hostname.

Main tradeoff: the root domain usually cannot use a standard CNAME in the same way as a subdomain, depending on the DNS provider’s feature set.

Scenario 4: You want the simplest setup for a standard website

If your website has one host, one main site, and no unusual DNS requirements, a common pattern is:

• Root domain @ uses an A record to the server IP
• www uses a CNAME to the root domain

This is a clean and portable setup for many conventional hosting environments.

Scenario 5: You use external email and only want to move the website

This is where people often break mail flow by changing nameservers too quickly.

Safer approach:

• If possible, keep DNS where it is and only update the web-related records.
• Preserve existing MX, SPF, DKIM, and DMARC records.
• Document current DNS before you change anything.

If you do move nameservers, rebuild email-related records first so mail does not fail after the switch.

Scenario 6: You are using a CDN or reverse proxy

In this case, your DNS for web hosting may point to the CDN or proxy layer, not directly to the origin server.

Checklist:

1. Confirm which hostnames should be proxied and which should resolve directly.
2. Keep the origin server details documented separately.
3. Verify SSL mode and certificate provisioning at both the edge and origin where needed.
4. After DNS changes, test both performance and origin reachability.

For related site performance considerations, see How to Speed Up a Slow Website: Hosting, Caching, DNS, CDN, and Image Optimization Checklist.

What to double-check

Before you click save, review these items. They prevent most avoidable outages.

1. Know where DNS is actually hosted

Your domain registrar is not always your DNS provider. Many teams log in to the registrar and wonder why no records are visible. If nameservers point elsewhere, that external provider is the place to edit records.

2. Confirm the exact hostname you are editing

@, www, and subdomains are separate entries. A working root domain does not guarantee that www works, and vice versa.

3. Watch for conflicting records

If the same hostname has old A records, stale AAAA records, or duplicate CNAMEs, clients may resolve unpredictably. Clean up what no longer belongs.

4. Check TTL before planned changes

If you know you are migrating or cutting over, lowering TTL ahead of time can make later record changes update faster from a practical standpoint. Just do this before the move, not after the old TTL is already cached across resolvers.

5. Preserve non-web DNS records

Website DNS changes should not accidentally delete:

• MX records for mail
• TXT records for SPF, DKIM, DMARC, or verification
• Subdomains used by apps, APIs, or support tools
• Autodiscover, SIP, or other service-specific records

This is especially important if you switch nameservers.

6. Verify SSL after DNS resolves correctly

Many hosts issue SSL certificates only after the domain points to the correct destination. If HTTPS does not work immediately, the problem may be certificate provisioning, not DNS syntax. See How to Set Up SSL Certificates for Any Website: HTTPS, Auto-Renewal, and Common Errors.

7. Test from the outside, not only inside your dashboard

After changes, verify:

• The domain resolves to the expected target
• The correct site loads over HTTP and HTTPS
• The preferred host redirects properly, such as non-www to www or the reverse
• Email still works if applicable

Once traffic is live, uptime monitoring helps confirm the change did not introduce intermittent failures. See Website Uptime Monitoring Comparison: What to Track Beyond Simple Ping Checks.

8. Keep a rollback note

Before changing records, copy the current values into a text file or ticket. If the new setup fails, you can restore the previous state quickly instead of trying to remember what was there.

Common mistakes

Most DNS problems are not complicated. They are usually small mismatches between intent and implementation.

Changing nameservers when only one record needed to change

If your goal is only to connect a website, changing the whole nameserver delegation may be more disruptive than necessary. It can be correct, but only if you are ready to manage the entire zone move.

Using a CNAME at the wrong hostname

A CNAME is often perfect for www, but not every DNS environment supports a standard CNAME at the root domain. Follow your DNS provider’s supported method for apex records.

Forgetting the www version

Users may type both versions. Search engines, bookmarks, and existing links may also hit either hostname. Set up both and make sure one redirects to your canonical choice.

Deleting mail records during a website change

This is one of the most expensive small mistakes. The site may come up while mail quietly stops. Treat web, mail, and verification records as separate responsibilities.

Leaving stale DNS in place after a migration

Old records do not always fail obviously. They can create partial outages, inconsistent responses, or hard-to-diagnose traffic paths.

Ignoring hosting-side configuration

DNS can be correct while the host is still not ready. Make sure the domain is added in the hosting control panel, virtual host configuration, or platform project settings. If you are evaluating hosting dashboards, see cPanel vs Plesk vs Managed Dashboards: Which Hosting Control Panel Is Best?.

Assuming propagation is the only issue

People often blame propagation when the real problem is a typo, an old conflicting record, a missing SSL certificate, or a host that has not been configured to serve the domain yet.

When to revisit

This is not a one-time topic. Revisit your domain-to-host setup whenever the underlying inputs change.

Use this action checklist before you launch, migrate, or renew infrastructure:

1. Audit the current DNS zone. Export or copy all existing records, especially web, mail, and verification entries.
2. Confirm who should host DNS. Decide whether to keep DNS at the registrar, move it to the host, or use a dedicated DNS provider.
3. Match the method to the host. If the host provides nameservers, consider full delegation. If it provides an IP, use an A record. If it provides a hostname, use a CNAME where appropriate.
4. Map every public hostname. Include the root domain, www, and any subdomains used by apps or services.
5. Plan redirects and canonical hostnames. Decide whether users should land on www or the root domain and configure redirects accordingly.
6. Verify SSL timing. Know whether certificates are automatic after DNS validation or require manual steps.
7. Protect email and TXT records. Treat them as separate from the website cutover.
8. Test before and after. Confirm DNS resolution, site response, HTTPS, and mail flow.
9. Monitor after the change. Watch uptime, error rates, and certificate status for a period after cutover.
10. Document the final state. Save a clean record of what each DNS entry is for so the next change is easier.

You should also revisit this setup when:

• You move from shared hosting to VPS hosting or cloud hosting
• You adopt a CDN, reverse proxy, or DDoS protection layer
• You separate website hosting from email hosting
• You redesign a site and consolidate subdomains
• You transfer domain registration to a different registrar
• You review security and backup practices as part of routine operations

For broader operational resilience, it is worth pairing DNS changes with a backup review. See How Often Should You Back Up a Website? RPO and RTO Guidelines by Site Type and Website Backup Strategy Guide: Full, Incremental, Differential, and Snapshot Backups Compared.

If you remember only one thing, make it this: pointing a domain to hosting is less about the record type itself and more about choosing the right level of DNS control. Nameservers delegate the whole zone. A records point hostnames to IPs. CNAMEs point hostnames to hostnames. Once that distinction is clear, the setup becomes much easier to reason about, test, and repeat.