How to Point a Domain to Web Hosting: DNS Records, Nameservers, and Troubleshooting Checklist

Overview

A domain registrar and a hosting provider perform different jobs. The registrar holds the domain registration, while the host stores and serves your website. DNS connects the domain name to the services people need to reach.

There are two common ways to connect a domain and hosting:

• Change nameservers: You tell the registrar to use the hosting provider's DNS servers. The host then manages the domain's DNS zone.
• Edit DNS records: You keep the current DNS provider and add or update records such as A, AAAA, CNAME, MX, and TXT.

Nameserver changes are often simpler for a new website because the hosting provider may create the required records automatically. Editing records gives you more control and can be safer when the domain already supports business email, verification services, subdomains, or other systems. Do not change nameservers casually: doing so can replace the active DNS zone and may interrupt services that were configured elsewhere.

Before making changes, gather the exact values supplied by your host. These may include an IPv4 address for an A record, an IPv6 address for an AAAA record, a target hostname for a CNAME, or nameserver addresses. Use the provider's current instructions rather than guessing from examples.

If you are still selecting a provider, the practical differences between registrar and hosting provider are covered in this domain and hosting launch checklist. If the site will use WordPress, also compare backup, staging, support, and performance features before pointing the domain.

Checklist by scenario

Scenario 1: A new domain and a new website

1. Confirm that the domain is registered and not subject to a transfer, redemption, or verification issue.
2. Add the domain inside the hosting control panel. Some hosts require this before their server will respond to the domain.
3. Choose whether the host will manage DNS through nameservers or whether you will keep DNS at the registrar or another provider.
4. Record the required nameservers or IP address. Keep a copy in your setup notes.
5. Apply the change at the registrar or DNS provider.
6. Wait for DNS caches to refresh, then test both the root domain and the www version.
7. Confirm that the host has issued or enabled an SSL certificate before treating the launch as complete.

If you use nameservers, check the full DNS zone after the change. Look for the website records, mail records, and any verification records you still need.

Scenario 2: An existing website moving to a new host

1. Lower the DNS record time to live, or TTL, before the migration if your DNS provider allows it. A shorter TTL can make later changes refresh sooner, but it does not eliminate caching.
2. Build and test the site on the new host using its temporary URL, preview address, hosts-file method, or staging feature.
3. Copy the website files, database, media, redirects, scheduled tasks, and environment settings.
4. Recreate every required DNS record at the destination before switching traffic.
5. Update the A or AAAA record, or change nameservers if that is the migration plan.
6. Monitor the old and new environments during the transition. Avoid deleting the old hosting account until traffic and email are confirmed.
7. Test forms, logins, checkout pages, analytics, redirects, and third-party integrations after the new site responds.

A hosting change does not automatically transfer DNS, email, backups, or databases. Treat each as a separate migration item. For a broader preparation list, see the website launch checklist.

Scenario 3: Keep email where it is while moving the website

Change only the records required for the website. Usually, that means the root domain's A record and the www CNAME, depending on the host's instructions. Leave MX records unchanged unless you are intentionally moving email.

Also preserve the email provider's TXT and CNAME records for SPF, DKIM, DMARC, domain verification, and any related services. Removing or replacing these records can affect delivery or authentication. The business email DNS guide explains how these records work together.

Scenario 4: Use a separate DNS provider or CDN

For a setup such as Cloudflare DNS, first add the domain to the DNS provider and review the records it detects. Compare that list with the current zone before changing nameservers at the registrar. Recreate missing records manually, especially MX, TXT, verification, and subdomain records.

When a proxy or CDN is enabled, confirm whether the host expects the visitor-facing address or the origin server address. Follow the host's SSL mode and origin certificate requirements. A proxied record can behave differently from a DNS-only record, so test the site after each significant change.

What to double-check

Understand the important record types

• A: Points a hostname to an IPv4 address. It is commonly used for the root domain.
• AAAA: Points a hostname to an IPv6 address. Add it only when the destination is configured to serve IPv6 correctly.
• CNAME: Points a hostname to another hostname. It is often used for www or provider-managed services.
• MX: Identifies the servers that receive email for the domain.
• TXT: Stores text-based instructions and verification values, including email authentication records.
• NS: Identifies the authoritative nameservers for the domain or a delegated subdomain.

Check the host field format required by your DNS control panel. Some panels expect the root domain to be entered as an at-sign, while others expect a blank field or the complete domain name. A trailing dot may be displayed in DNS tools but is not always entered manually.

Verify propagation and the destination

Use a DNS propagation checker to query the record from multiple locations, but do not treat one result as conclusive. Compare public results with the authoritative nameservers, and test from a separate network or device. Local DNS caches, corporate networks, browsers, and operating systems can retain older answers.

Check these addresses separately:

• the root domain, such as example.com;
• the www hostname;
• any important subdomains, such as shop or app;
• mail delivery by sending and receiving a test message;
• HTTPS in a private browser window and on a mobile connection.

Confirm SSL after DNS works

SSL validation generally requires the hostname to resolve to the intended service and the hosting platform to recognize the domain. Once DNS points to the new host, enable the certificate through the host or certificate provider, then test both HTTP and HTTPS. Confirm that the certificate covers every hostname you publish, including www if visitors can use it.

Common mistakes

• Changing nameservers without copying the DNS zone: This can remove mail, verification, and subdomain records from the active configuration.
• Using the wrong IP address: Hosting dashboards may show several addresses for different services. Use the address specifically assigned to the website.
• Creating a CNAME at the root when the provider requires an A record: Root-domain behavior varies by DNS platform. Follow the provider's supported configuration.
• Leaving an old AAAA record in place: Some visitors may reach an IPv6 destination that is not configured for the new site. Remove or update it when appropriate.
• Replacing MX or email TXT records during a website move: Website DNS changes and email migration are separate decisions.
• Testing only one URL: Root, www, HTTPS, redirects, and key subdomains can behave differently.
• Assuming propagation has a fixed deadline: DNS caching varies by record, resolver, and network. Troubleshoot the authoritative answer first, then allow caches time to refresh.
• Disabling security controls unnecessarily: Keep registrar lock and two-factor authentication enabled, and plan DNSSEC changes carefully. Use the domain security checklist for a wider review.

When to revisit

Review your DNS configuration before a hosting migration, rebrand, seasonal campaign, domain transfer, email-provider change, or major website launch. Revisit it when you add a subdomain, connect a new SaaS tool, introduce a CDN, or change the site's SSL arrangement.

At least periodically, confirm that:

• the domain is renewing with the correct owner and payment details;
• registrar lock, two-factor authentication, and recovery contacts are current;
• the authoritative nameservers are expected;
• old A, AAAA, CNAME, MX, and TXT records are removed when no longer needed;
• email authentication records still match the current provider;
• DNSSEC, if enabled, has valid settings after any nameserver change;
• backups and restoration instructions are available before the next migration.

Keep a dated record of the domain, DNS provider, hosting provider, nameservers, important records, and the reason for each unusual entry. Before changing anything, export or screenshot the current zone. Then make one controlled change at a time, verify it with a DNS propagation checker and real browser or email tests, and document the result. That simple habit turns DNS management from a last-minute troubleshooting exercise into a repeatable website reliability process.