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

Overview

A domain registrar, DNS provider, and web host can be three separate services. The registrar holds the domain registration, the DNS provider publishes instructions for where the domain should resolve, and the host serves the website. Some companies combine all three, but the underlying jobs remain different.

Before making changes, record the current setup. Export or copy the existing DNS zone if your provider allows it, and list the records used by the website, email, verification services, subdomains, and third-party applications. This is particularly important during a migration because changing nameservers can replace the entire DNS zone at the new provider.

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

• Change nameservers: You delegate DNS management to the hosting provider or another DNS hosting service. The provider then manages the zone and gives you the records needed for the website and other services.
• Keep existing nameservers and edit records: You leave DNS with the current provider and change specific records, usually an A record for the root domain and a CNAME record for www.

Neither approach is automatically better. Nameserver changes can simplify management when the host supplies a complete, working DNS configuration. Editing individual records gives you more control and reduces the risk of unintentionally replacing email or verification records. For a broader explanation of A, AAAA, CNAME, MX, TXT, and SRV records, see DNS record types explained.

Checklist by scenario

Scenario 1: A new website with no existing email

1. Confirm the hosting provider's target. This may be an IPv4 address for an A record, an IPv6 address for an AAAA record, or a platform hostname for a CNAME record.
2. Choose whether to use the host's nameservers or keep DNS at the current provider.
3. For a root domain such as example.com, add the record type the host specifies. Do not substitute a guessed address.
4. For www.example.com, add the host's recommended CNAME or redirect configuration.
5. Save the changes, then verify both the root domain and the www version.
6. Enable SSL in the hosting control panel after the domain resolves to the correct site. Confirm that both HTTP and HTTPS requests use the intended canonical version.

Scenario 2: An existing website moving to a new host

1. Build and test the site on the new host before changing public DNS. Use a staging URL, temporary hostname, or hosts-file test where appropriate. The guide to staging versus production environments covers this separation.
2. Lower the DNS record's time-to-live in advance if your provider supports it and your migration plan benefits from shorter caching periods. This does not instantly clear records already cached elsewhere.
3. Copy every required DNS record, including email, subdomains, domain verification, payment integrations, analytics, and security services.
4. Change only the web records if DNS remains with the current provider. If changing nameservers, recreate the full zone first.
5. Keep the old hosting environment available while caches expire and traffic is checked. The correct overlap period depends on the DNS setup and the services involved.
6. After the switch, test important URLs, forms, logins, redirects, file downloads, webhooks, and administrative areas.

Scenario 3: The domain also handles email

Treat email as a separate workstream. Website records usually include A, AAAA, or CNAME entries, while email delivery commonly depends on MX records and may also require TXT records for sender authentication or provider verification. Do not delete or replace these records simply because the website is moving.

Before changing nameservers, obtain the complete email provider configuration. After the change, send test messages in both directions, check existing mailboxes, and verify that any email client or application using the domain still works. A domain and email setup checklist should include mailbox access, aliases, forwarding, contact forms, and application-generated messages.

Scenario 4: A platform gives you a CNAME target

Some managed cloud hosting platforms use a hostname rather than a fixed IP address. Follow the platform's instructions for the root domain because DNS providers differ in how they support root-level CNAME-like records. Add the specified CNAME for the subdomain, commonly www, and configure the root domain according to the platform's documented method. Avoid adding both a conflicting A record and CNAME for the same hostname.

What to double-check

• Correct destination: Compare the record value character by character with the hosting provider's instructions. A single incorrect digit or hostname can send visitors to the wrong service.
• Record conflicts: Look for duplicate A, AAAA, or CNAME records. Multiple destinations may produce inconsistent results, especially when an old host remains in the zone.
• Nameserver delegation: If you changed nameservers at the registrar, confirm that the registrar displays the intended pair or set. Editing records at a provider that is no longer authoritative will have no public effect.
• Subdomains: Check separately configured hosts such as app, api, staging, and mail. A successful root-domain test does not prove that every subdomain is correct.
• SSL coverage: DNS only directs traffic; it does not by itself issue or install a certificate. Complete the host's domain verification and SSL steps, then test the HTTPS version and certificate hostname.
• IPv6 behavior: If an AAAA record exists but the new host does not support IPv6 correctly, some visitors may see a failure while others do not. Remove or update obsolete records only after confirming their purpose.
• Propagation: Check from more than one network or DNS lookup tool. Cached answers can differ by resolver, location, and record TTL, so one successful lookup is not the whole picture.

For performance work after the connection is stable, review how hosting, DNS, CDN, caching, and image optimization affect website speed. DNS is only one part of the delivery path.

Common mistakes

Changing nameservers without copying email records can interrupt mail even when the website loads correctly. Preserve the existing zone before delegating DNS elsewhere.

Using the hosting server IP as a CNAME value is another frequent error. CNAME records point to hostnames, while A records point to IPv4 addresses. Use the record type specified by the provider.

Testing only one domain format can hide a broken redirect or missing record. Test the root domain, www, HTTPS, and any business-critical subdomains.

Assuming propagation is a hosting failure can lead to unnecessary changes. First check authoritative DNS, local resolver results, browser cache, and the actual response from the new host.

Deleting old records too quickly can break services that were not included in the initial migration inventory. Keep a change log and remove obsolete entries only after confirming that they are no longer used.

When to revisit

Use this checklist whenever you register a domain, buy domain and hosting from separate providers, transfer a domain to a new host, launch a subdomain, change email providers, or move from one cloud hosting platform to another. Revisit it before seasonal launches and other high-traffic planning cycles, when DNS workflows or hosting control panels change, and whenever a team member takes over domain administration.

Keep a current DNS inventory with the registrar, authoritative nameservers, record purpose, destination, owner, and last review date. Before the next change, compare that inventory with the live zone and the new host's instructions. Then follow this final launch sequence:

1. Back up the current DNS records.
2. Confirm the new hosting destination and test the site before cutover.
3. Protect email, verification, and application records.
4. Change nameservers or web records using one deliberate plan.
5. Verify DNS, HTTPS, redirects, forms, email, and critical subdomains from multiple networks.
6. Document the result and schedule a follow-up review after the migration settles.

This process turns how to point a domain to hosting from a one-time fix into a repeatable part of secure DNS management and website migration hosting.