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

Overview

A domain name and a hosting account are separate services. The domain is registered with a registrar, while the website files or application run on a hosting platform. DNS connects the two by telling browsers which servers should answer for your domain.

There are two common ways to make that connection:

• Change nameservers: You delegate DNS management to the hosting provider. The host supplies nameserver addresses, and you manage the domain’s DNS records in the host’s control panel.
• Edit DNS records: You keep DNS management at the registrar or another DNS provider and point selected records to the hosting service. This is often preferable when email, verification records, or other services already depend on the existing DNS zone.

Neither option is automatically better. Nameserver changes can be simpler when a hosting provider is designed to manage the whole zone. Direct record changes provide more control and reduce the risk of replacing unrelated records. Before making either change, record the current DNS configuration and identify every service that uses the domain.

For a wider launch review, use the Website Launch Infrastructure Checklist. It covers the surrounding areas of a domain and hosting setup, including backups, monitoring, SSL, and email.

Checklist by scenario

Scenario 1: Your host provides nameservers

1. Confirm the exact nameserver hostnames in your hosting account. Copy them carefully; do not infer them from a different account or an old setup.
2. At your registrar, open the domain’s nameserver or DNS delegation settings.
3. Replace the existing nameservers only after exporting or recording the current DNS records.
4. Save the change and note the time. Nameserver changes can take time to appear consistently across recursive DNS resolvers.
5. After the host’s DNS zone is active, confirm that the zone contains the records required for the website, email, verification services, and any subdomains.

Use this approach when the host clearly states that it will provide authoritative DNS and you want that provider to manage the zone. If the domain has active business email or third-party services, verify that the new zone contains their records before switching.

Scenario 2: Your host provides an IP address

1. Find the hosting service’s documented IPv4 address. If it provides an IPv6 address, note that separately for an AAAA record.
2. In the authoritative DNS zone, set the apex or root record, commonly written as @, to the supplied IPv4 address using an A record.
3. Add or update the www record. A CNAME pointing www to the root domain is common, but follow the host’s instructions if it requires a different target.
4. Remove conflicting A, AAAA, or CNAME records for the same hostname. A hostname should not have a CNAME alongside other record types.
5. Keep MX, TXT, and other unrelated records unless you have confirmed they are no longer needed.

This is often the safer choice when DNS is already managed centrally or when the domain supports email and several external services. It changes only the records needed for the website instead of replacing the entire DNS delegation.

Scenario 3: Your host provides a CNAME target

Some platforms assign a hostname such as a project or application address rather than a fixed IP. Add the requested CNAME for the specified subdomain, often www or another application hostname. The root domain may require an A record, an ALIAS or ANAME-style feature, or a forwarding method supported by your DNS provider. Do not assume that a CNAME can be placed at the root; check the provider’s instructions and your DNS platform’s capabilities.

Scenario 4: You are migrating an existing site

1. Lower the relevant DNS record TTL before the planned cutover if your provider allows it. A lower TTL can make later changes easier to apply, but it does not guarantee instant worldwide updates.
2. Build and test the new site on its temporary host address, preview URL, or local hosts-file override.
3. Copy the website, database, uploaded files, scheduled tasks, environment variables, and application secrets as appropriate.
4. Confirm that the new server can handle redirects, canonical URLs, robots directives, and application-generated links.
5. Change the A, AAAA, or CNAME record at the agreed cutover time.
6. Keep the old hosting environment available until the new site has been checked from more than one network and important transactions have been tested.

For a more detailed migration sequence, see How to Migrate a Website to a New Host With Minimal Downtime.

Scenario 5: You are setting up SSL and subdomains

Pointing DNS at a host does not by itself complete HTTPS setup. Add the required website records first, then start certificate issuance or verification in the hosting control panel. Some certificate workflows require a temporary TXT or CNAME record. Add that verification record exactly as supplied, including its host label and value, and remove it only when the provider says it is no longer needed.

For subdomains such as app.example.com, staging.example.com, or api.example.com, create separate A or CNAME records and confirm that the application is configured to answer for each hostname. Issue or attach certificates for those names as well.

What to double-check

Email records

Website changes should not unintentionally interrupt email. Preserve MX records and the related SPF, DKIM, and DMARC TXT records unless you are deliberately moving mail. When changing nameservers, compare the old DNS zone with the new zone line by line. A newly created zone that contains only website records may omit mail configuration.

If you are planning domain email separately, review Business Email on Your Domain before changing delegation.

TTL and propagation

TTL, or time to live, tells resolvers how long they may cache a DNS response. It is not a countdown that guarantees an exact completion time. Different resolvers may refresh at different times, and local operating systems, browsers, networks, and security services may cache results separately.

Use a DNS propagation checker to compare results from multiple locations, but interpret it as an observation tool rather than proof that every user sees the same answer. Check the authoritative nameservers directly as well as public recursive resolvers. The article DNS Propagation Explained provides a focused troubleshooting workflow.

SSL, redirects, and application settings

After DNS begins resolving to the new host, test both HTTP and HTTPS. Confirm that the certificate covers the root domain and the www hostname if both are in use. Check that one intended version is canonical, that redirects do not loop, and that mixed-content warnings do not appear. CMS platforms and applications may also require an updated site URL, trusted host setting, reverse-proxy setting, or environment variable.

Security and control

Make DNS changes from a protected registrar or DNS account with two-factor authentication enabled. Confirm that the domain is not accidentally unlocked if no transfer is planned, and limit access to people who need to edit the zone. DNSSEC may be appropriate for your setup, but enable or change it carefully because incorrect DS or signing configuration can make a domain fail to resolve. Use the Domain Security Checklist for a broader review.

Common mistakes

• Changing nameservers without copying email records: The website may work while mail delivery fails. Export the existing zone first.
• Editing DNS at the wrong provider: Changes have no effect if the edited service is not authoritative for the domain. Check the active nameservers before troubleshooting.
• Leaving conflicting records: Multiple A records can distribute traffic, while an old AAAA record can send IPv6 users to the wrong server. Remove obsolete records deliberately.
• Using an IP address in a CNAME field: CNAME values are hostnames. IP addresses belong in A or AAAA records.
• Forgetting the root and www relationship: Test the exact hostnames visitors use, not just one of them.
• Expecting propagation to be instant: Repeatedly changing records can make diagnosis harder. Make one controlled change, record it, and test from several networks.
• Testing only the homepage: Check login, forms, checkout, APIs, downloads, redirects, scheduled jobs, and any integrations that matter to the site.
• Deleting verification records too early: Some services periodically check their DNS verification record. Keep it if the service requires ongoing proof of ownership.

When to revisit

Keep this checklist with your domain and hosting records, and revisit it before a planned migration, seasonal campaign, major application release, or change to email providers. It is also useful when your hosting platform changes its required records, your DNS provider changes its control panel, or a new subdomain or third-party service is introduced.

At each review, confirm the registrar account, authoritative nameservers, DNS zone backup, TTL choices, SSL coverage, email records, and recovery contacts. Remove records for retired services, but only after checking that no application, certificate, or verification process still depends on them. Review the domain’s renewal status as well; DNS cannot compensate for an expired domain. For renewal planning, see Domain Renewal and Expiration.

Before making the next change, write down the current state, the intended end state, the person responsible, and a rollback plan. Then make the smallest DNS change that achieves the goal, verify authoritative results, test the site and email independently, and keep the change record for the next person who has to manage the domain.