Pointing a domain to web hosting is usually a DNS configuration task, but changing the wrong record can interrupt a website, email, or subdomain. This guide explains when to use nameservers or individual DNS records, how to plan A, AAAA, CNAME, and MX entries, how to check propagation, and how to troubleshoot the most common connection failures without guessing.
Overview
When you buy domain and hosting from different providers, the domain registrar remains responsible for the domain registration while the hosting provider supplies the server or platform where the site runs. DNS connects the two by translating a domain name into the destination used by browsers, mail systems, and other services.
There are two common ways to connect a domain to web hosting:
- Change nameservers: You delegate DNS management to the hosting provider. The host usually creates or manages the required records for you.
- Edit individual records: You keep DNS at the registrar or a separate DNS provider and point only the website records to the new host.
Nameserver changes are often simpler for a new site, especially when the hosting account provides a complete DNS zone. Individual records offer more control and are usually safer when email, verification records, APIs, or other services already depend on the domain. Before changing anything, export or record the existing DNS zone and identify where email is currently hosted.
A DNS change does not move website files, databases, mailboxes, or SSL settings. Those tasks must be completed separately. If you are changing providers, prepare the new site and review the migration sequence in this domain transfer checklist before switching traffic.
What to track
Choose the connection method
Use nameservers when the hosting provider is intended to manage the entire DNS zone and you have confirmed that all existing records can be recreated. Do not change nameservers casually if the domain has working business email, third-party applications, or important verification records. A nameserver change can replace the active DNS zone rather than simply adding a website destination.
Use an A record or CNAME when you want to preserve the current DNS provider. This approach is useful when email is managed by a separate service or when you need precise control over each hostname. Your host should provide the exact destination value; do not substitute an IP address found in a general support article if the hosting account specifies another value.
Build a DNS record plan
| Record | Purpose | Typical value to request or confirm | Important caution |
|---|---|---|---|
| A | Points a hostname to an IPv4 address | The hosting server IPv4 address | Use the exact address assigned to the account. |
| AAAA | Points a hostname to an IPv6 address | The hosting server IPv6 address | Remove or correct it if IPv6 is not configured for the site. |
| CNAME | Aliases one hostname to another hostname | A host-provided target such as a platform hostname | Do not normally place a CNAME and A record on the same hostname. |
| MX | Specifies where email for the domain is delivered | The mail provider hostname and priority | Do not change it unless you are intentionally moving email. |
For a basic website, the root domain may use an A record and www may use a CNAME to the root domain or to a host-provided target. DNS interfaces vary: some represent the root as @, while others leave the name field blank. Follow the provider’s field instructions exactly.
Set a manageable TTL before a planned change, such as 300 to 900 seconds where the provider permits it. A shorter TTL may allow resolvers to refresh sooner, but it does not force every cached answer to disappear immediately. After the change is stable, raise the TTL if appropriate for your operational needs.
Record the baseline
Before editing DNS, save the current nameservers, A, AAAA, CNAME, MX, TXT, and relevant verification records. Note the current website IP, email provider, subdomains, and SSL setup. This baseline makes it easier to detect a missing record and restore the previous configuration if needed. A periodic DNS health audit can reveal stale or conflicting entries before they become an outage.
Cadence and checkpoints
Step-by-step workflow
- Prepare the hosting account. Add the domain in the hosting control panel and confirm the destination records, assigned IP addresses, required CNAME, and SSL process. Test the site on a temporary URL or staging environment where available.
- Inventory dependencies. Confirm who handles email, identify subdomains, and save all current DNS records. Pay particular attention to MX, SPF, DKIM, DMARC, and service-verification TXT records.
- Choose nameservers or records. Use the host’s nameservers only when it should manage the complete zone. Otherwise, update the website’s A, AAAA, or CNAME records at the current DNS provider.
- Lower the TTL if planned. Make this change before the main cutover when possible. If the change is urgent, continue carefully; lowering TTL after a record has been cached cannot shorten that existing cache period.
- Apply the change and note the time. Record exactly what changed, where it changed, and the previous values. This creates an audit trail for later troubleshooting.
- Check from several networks. Query the records using a DNS propagation checker, a command-line tool such as
digornslookup, and a normal browser. Compare authoritative answers with recursive resolver answers. - Validate the complete service. Load the root domain and
www, test important paths, submit a form, check redirects, send and receive email, and inspect the SSL certificate. DNS may be correct while the hosting virtual host or certificate is not.
Propagation is better understood as cache expiry and resolver refresh than as a single global event. Some networks may show the new answer while others still return the old one. A change can become visible quickly in one location and remain cached elsewhere for longer, depending on prior TTLs and resolver behavior.
Use a simple troubleshooting decision tree
- The domain shows a parked page: Check the authoritative nameservers first. If they belong to the registrar, the domain may still be using the registrar’s default zone. If the nameservers are correct, inspect the A or CNAME target and confirm that the domain was added to the hosting account.
- Some locations show the old site: Compare results from multiple resolvers and check the record TTL. If authoritative DNS already returns the new value, wait for cached responses to expire rather than repeatedly editing the record.
- The website works but email fails: Review MX records and mail-related TXT records. A website cutover should not require changing MX records unless email is moving too. Check that the new DNS zone did not omit existing mail records.
- The root domain works but
wwwfails: Check whetherwwwhas its own CNAME or A record and whether the hosting panel recognizes both hostnames. Also look for a conflicting record type. - HTTPS shows a warning: Confirm that the hostname resolves to the intended server, then check certificate issuance, coverage, and renewal. DNS alone does not install an SSL certificate.
How to interpret changes
A successful DNS connection has several separate signals. The authoritative nameservers should publish the intended records. Recursive resolvers should gradually return those records. The hosting server should respond to the domain, and the application should serve the correct content. Treat these as four checkpoints rather than assuming that a browser result explains everything.
Mixed results often indicate one of three conditions: different resolvers still hold cached data, the domain has multiple conflicting records, or the registrar and hosting provider are managing different DNS zones. Check the delegation first, then inspect the authoritative zone, and only after that investigate local browser or network caching.
Do not add duplicate A records simply because one location appears slow. Multiple A records can produce inconsistent destinations and make diagnosis harder. Likewise, do not delete MX or TXT records to simplify a website setup. Preserve records that serve email, domain verification, security policies, or third-party integrations unless you have confirmed they are obsolete.
When to revisit
Revisit this guide whenever you launch a site, add a subdomain, change hosting, move email, renew or replace an SSL certificate, or investigate an outage. A monthly or quarterly DNS review is useful for domains that support business operations, particularly when several people can edit the zone.
At each review, compare the live zone with your inventory. Confirm that nameservers are expected, remove records for retired services, verify that A, AAAA, and CNAME values still match the hosting design, and check that MX, SPF, DKIM, and DMARC records still belong to the active mail setup. Review TTLs and document any intentional exceptions.
For a planned move, use this short action list:
- Back up the current DNS zone and website.
- Prepare and test the new hosting account.
- Confirm email and subdomain dependencies.
- Choose nameserver delegation or targeted record changes.
- Monitor authoritative and recursive DNS answers.
- Test website, redirects, forms, email, and HTTPS.
- Keep the previous hosting environment available until traffic and services are consistently correct.
Keeping a dated DNS inventory turns a confusing connection problem into a repeatable operational task. When the next host change or outage occurs, you can identify what changed, verify what is live, and restore service without relying on memory.
