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

Overview

Your domain registration and web hosting are separate services. The registrar manages the domain name, while the hosting platform stores and serves the website. DNS connects the two by telling browsers which servers should answer for your domain.

Before making a change, collect four pieces of information:

• The exact domain or subdomain you want to connect.
• The hosting provider's required DNS values, such as nameservers, an IPv4 address, or a target hostname.
• The DNS records currently used for email, verification, subdomains, and other services.
• Access to both the domain's DNS management panel and the hosting account.

There are two common approaches. Changing nameservers delegates DNS management to the hosting provider. Editing individual records keeps DNS at the current provider and changes only the records needed for the website. Neither approach is universally best; choose the one that matches your provider's instructions and your need to preserve existing DNS services.

If you are comparing infrastructure options before a migration, review cloud hosting versus VPS hosting. The server decision and the DNS decision are related, but they are separate steps.

Checklist by scenario

Scenario 1: Use the hosting provider's nameservers

1. Open the hosting account and locate its authoritative nameserver values.
2. At the domain registrar, replace the existing nameservers with the supplied values. Enter them exactly as shown.
3. Save the change and keep a record of the previous nameservers in case you need to restore them.
4. Confirm that the hosting account recognizes the domain and that the domain is assigned to the intended website.
5. Wait for DNS changes to become visible in different networks. Avoid repeatedly changing settings while the update is being observed.

This approach can simplify management because the hosting provider controls the zone. However, review the DNS zone before switching if the domain handles email, verification tokens, subdomains, or third-party services. Moving nameservers without recreating required records can interrupt those services.

Scenario 2: Point the domain with an A record

1. Ask the hosting provider for the website's public IPv4 address.
2. In the current DNS panel, find the A record for the root domain, often shown as @.
3. Replace the old web destination with the new IPv4 address, or create the record if none exists.
4. Check whether a separate www record exists. Point it to the intended destination rather than leaving it attached to an old server.
5. Save the record and confirm that the hosting control panel has the domain configured as the primary or additional site.

An A record is appropriate when the host provides an IP address. Do not enter a URL such as https://example.com into an A record; DNS records require the value type specified by the provider.

Scenario 3: Point a subdomain with a CNAME record

1. Identify the subdomain, such as app.example.com or blog.example.com.
2. Create or edit its CNAME record.
3. Use the hosting provider's target hostname, not a full URL and not usually an IP address.
4. Check for conflicting A, AAAA, or CNAME records with the same name and remove only obsolete entries.
5. Verify that the destination service also knows about the subdomain and has issued or configured its certificate.

A CNAME creates an alias to another hostname. It is commonly used for hosted applications, content platforms, and service subdomains. Follow the provider's exact instructions because some DNS panels automatically add the domain name to an entered value.

Scenario 4: Migrate an existing website

1. Build and test the website on the new hosting environment before changing public DNS.
2. Reduce avoidable risk by confirming backups, database credentials, application settings, and the correct document root.
3. Copy the site and database, then test links, forms, assets, redirects, and administrative access on the staging or temporary address.
4. Record current DNS values, email records, redirects, and third-party verification records.
5. Change only the web-related records unless you intentionally plan to move other services.
6. After the change, test both the root domain and relevant subdomains from more than one network.

For a broader migration workflow, see the domain-to-cloud-hosting DNS setup guide and the staging site checklist.

What to double-check

Email-related DNS records

Website records and email records can coexist, but they serve different purposes. Before changing nameservers, identify the MX records that route mail and preserve the provider's required SPF, DKIM, and DMARC records. An A record change for the website does not normally replace MX records, but a full nameserver change can remove them if the new DNS zone is incomplete.

Root domain and www behavior

Test both example.com and www.example.com. They may use different records and may not automatically redirect to one another. Choose a preferred version, configure the other to redirect where appropriate, and confirm that the hosting platform recognizes both hostnames.

IPv4, IPv6, and SSL

If the provider supplies an AAAA record, check whether the website is correctly available over IPv6 before publishing it. A stale or incorrect AAAA record can direct some visitors to the wrong server even when the A record is correct. After DNS points to the new host, confirm that HTTPS works, the certificate covers every required hostname, and HTTP redirects to the intended secure URL.

Propagation and verification

DNS resolvers may retain previous answers until their cached values expire. During this period, different users can reach different destinations. Check the record using independent DNS lookup tools, test from separate networks, and inspect the hosting provider's domain verification status. A DNS update becoming visible does not prove that the application, certificate, redirects, and email configuration are all correct.

Common mistakes

• Editing DNS at the wrong provider: Make changes where the domain's active nameservers direct DNS management, not necessarily where the domain was registered.
• Using a URL in an A record: Enter the supplied IP address only. Use a CNAME when the provider gives a hostname.
• Leaving conflicting records: Multiple old A records can send visitors to different servers. Review duplicate and obsolete entries carefully.
• Changing nameservers without copying email records: Recreate required mail and verification records in the new zone before or during the switch.
• Testing only one hostname: Check the root domain, www, important subdomains, HTTP, and HTTPS.
• Assuming DNS completion means migration completion: Check application logs, forms, assets, redirects, certificates, and monitoring after the domain resolves.
• Changing several variables at once: Keep a change log and make one logical adjustment at a time so failures are easier to isolate.

Once the site is live, monitor server health and response behavior using a structured server monitoring checklist. If performance is a concern, review whether a CDN or caching layer is appropriate rather than treating DNS changes as a performance fix.

When to revisit

Keep this checklist with your domain and hosting records. Revisit it before a hosting migration, a seasonal traffic period, a DNS provider change, a domain renewal or transfer, an email provider change, or the launch of a new subdomain. It is also useful after changes to deployment workflows, certificates, CDN settings, or security verification.

For each future change, export or document the current DNS zone, note the intended change, record the time and responsible system, and define a rollback step. Afterward, verify resolution, HTTPS, email, redirects, application functionality, and monitoring. Keep backups available and document the final configuration so the next migration does not begin with guesswork.

Final action checklist: identify the active DNS provider, choose nameservers or individual records, preserve email records, configure the domain in hosting, test root and subdomain behavior, verify SSL, monitor the transition, and remove obsolete records only after the new setup is confirmed.