How to Point a Domain to Hosting: DNS Records, Nameservers, and Propagation

Overview

A domain registrar manages the registration of your domain, while a hosting provider supplies the web server or cloud environment where your site runs. DNS, or the Domain Name System, connects the two. Before changing anything, identify which company currently manages your DNS zone. It may be your registrar, your hosting provider, or a separate DNS service.

There are two common ways to point a domain to hosting:

• Change nameservers: Replace the domain's current authoritative nameservers with the nameservers provided by your hosting or DNS provider. That provider then manages the domain's DNS records.
• Change individual records: Keep the existing nameservers and update specific records, usually an A record for the root domain and a CNAME record for www.

Nameserver changes are often simpler for a new website, especially when the host supplies a complete DNS configuration. Individual record changes provide more control and are usually safer when the domain already supports email, verification services, subdomains, or other applications.

Do not treat DNS as a single switch. A website may use several records at once. A, AAAA, and CNAME records can direct web traffic, while MX, TXT, and other records may support email, security policies, or third-party tools. Before editing a live domain, record the current values or export the DNS zone if your provider supports that option.

Checklist by scenario

Scenario 1: A new domain and a new website

1. Confirm the hosting provider's setup instructions and find the destination IP address or assigned nameservers.
2. At the registrar, open the domain's DNS or nameserver settings.
3. If you are using the host's DNS service, enter the exact nameservers provided. Remove old nameservers only when you are ready to move DNS management.
4. If you are keeping the registrar's DNS, create an A record for the root domain, often shown as @, pointing to the hosting IPv4 address.
5. Create a CNAME record for www pointing to the root domain, or use the target specified by the host.
6. Save the changes and add the domain inside the hosting control panel. A DNS record alone does not always configure the web server to respond to that domain.

Scenario 2: Connecting a domain to WordPress

First connect the domain using the host's required nameservers or A and CNAME records. Then add the domain to the hosting account and install or attach WordPress. In WordPress settings, check that the WordPress Address and Site Address use the intended protocol and hostname, such as https://example.com. Avoid changing these values before the domain resolves unless you have a recovery path.

After DNS works, issue or activate the site's SSL certificate through the hosting platform. Test both the root domain and www version, then choose one as the canonical version and redirect the other. For a broader launch sequence, use this website launch checklist.

Scenario 3: Keeping business email while moving web hosting

Use individual web records rather than changing nameservers unless you intend to move all DNS management. Update the web A and CNAME records, but leave the existing MX records unchanged. Preserve email-related TXT records, including SPF, DKIM, and DMARC values, unless your mail provider gives you replacement records. Review the business email DNS guide before making changes.

Scenario 4: Migrating an existing website with minimal interruption

1. Build and test the new site on a temporary hostname, staging domain, or host-provided preview URL.
2. Reduce the DNS TTL ahead of the planned cutover if your provider allows it. A lower TTL may help caches request the new value sooner, but it cannot control every resolver.
3. Copy the site and database, test links and forms, and confirm the new server is ready before changing DNS.
4. Update the A or CNAME record during a quiet maintenance window.
5. Keep the old hosting account available until the new site is resolving consistently and important functions have been tested.

For WordPress workflows, see the guide to setting up a staging site before launch.

What to double-check

Nameservers and DNS records

Nameservers must be entered exactly as supplied. A typo, missing nameserver, or mixture of old and new nameservers can produce inconsistent results. If you use individual records, confirm that the A record points to the correct server and that an old AAAA record is not sending IPv6 visitors somewhere else. Remove conflicting duplicate records only after confirming they are no longer needed.

Root domain versus subdomain

The root domain, such as example.com, is not the same record as www.example.com. Some DNS providers use @ for the root, while others leave the name field blank. Follow the provider's interface instructions. A CNAME normally points one hostname to another hostname; it should not be used as a substitute for an IP address where the provider requires an A record.

TTL and propagation

TTL, or time to live, tells resolvers how long they may cache a DNS answer. After a change, some networks may continue showing the previous value until the cached TTL expires. This process is commonly called DNS propagation, although it is better understood as different resolvers refreshing their cached data at different times. A DNS propagation checker can compare responses from multiple locations, but it is a diagnostic aid rather than a guarantee that every user sees the same result.

Verification

Check the domain from more than one network, such as a mobile connection and a local connection. Use browser tests for both the root and www hostnames, and verify the final HTTPS redirect. Developers can also query records with tools such as dig or nslookup. Confirm that the returned IP or canonical name matches the hosting provider's instructions. Finally, check the hosting dashboard for domain verification, SSL status, application logs, and any required server-level configuration.

Common mistakes

• Changing nameservers without copying email records: If the new DNS zone lacks MX and email authentication records, mail delivery or sending reputation may be affected.
• Editing DNS at the wrong provider: Changes made in a registrar dashboard have no effect if another service hosts the domain's authoritative nameservers.
• Forgetting the hosting-side configuration: The DNS may point correctly while the web server still lacks the domain, document root, virtual host, or application mapping.
• Testing only one hostname: Check the root domain, www, HTTP, and HTTPS. Each may have a separate record or redirect.
• Assuming propagation is instant: Avoid repeated edits while waiting. Record each change, check authoritative answers, and allow cached responses to expire.
• Deleting records during a migration: Preserve existing records until you understand what they support. A DNS export or written inventory makes rollback easier.
• Expecting DNS to fix an application error: A correct DNS response cannot resolve a database failure, incorrect WordPress URL, firewall block, or misconfigured SSL certificate.

If your hosting interface is unfamiliar, a hosting control panel comparison can help you locate the relevant domain and DNS settings.

When to revisit

Revisit this checklist before a planned website launch, hosting migration, seasonal traffic cycle, domain transfer, or major DNS provider change. It is also useful after changing email providers, adding a subdomain, enabling a CDN, moving an application to cloud hosting, or renewing a certificate. Review the process whenever your registrar or hosting dashboard changes its labels or workflow.

Keep a current inventory of your domains, authoritative nameservers, important DNS records, hosting destinations, SSL status, and email providers. Before each change, save the current configuration and write down the intended result. After the change, verify DNS from multiple networks, test the application, confirm email still works, and monitor the old and new environments during the transition. This small record turns a stressful domain connection into a repeatable technical procedure.

For the final pre-launch pass, combine this guide with the site's domain, DNS, SSL, email, and analytics checklist.