How to Connect a Domain to Web Hosting: DNS Records Explained

Overview

If you want to connect a domain to hosting, you are usually doing one of two things: either pointing specific DNS records at a server or service, or changing the domain to use a different set of nameservers. Both approaches work, but they solve different problems.

At a high level, DNS is the system that tells browsers, email providers, and other services where your domain should go. Your hosting account stores your site files or application runtime. DNS connects the name people type into a browser with the infrastructure that serves the site.

Before making changes, it helps to know the main record types involved:

• A record: points a hostname to an IPv4 address.
• AAAA record: points a hostname to an IPv6 address.
• CNAME record: points one hostname to another hostname.
• MX record: tells email where to be delivered for your domain.
• NS record / nameservers: delegates DNS control to a DNS provider.
• TXT record: often used for verification, SPF, DKIM, and other email or security settings.

There are also a few terms worth keeping straight:

• Root domain: example.com
• Subdomain: www.example.com, app.example.com, docs.example.com
• TTL: the time resolvers may cache a DNS record before checking again
• Propagation: the period during which different resolvers begin seeing your updated DNS

The most common confusion is this: changing nameservers is not the same as editing DNS records. If you switch nameservers, you are moving DNS authority to a different provider. If you edit A, AAAA, CNAME, or MX records, you keep the current DNS provider and only update the routing.

As a rule of thumb:

• Use record-level changes when you want to keep DNS where it is and only point the domain to a new host.
• Use nameserver changes when your host or DNS provider should manage the full zone for you.

This distinction matters because changing nameservers can affect more than just the website. It can also affect email delivery, verification records, and any subdomains currently in use.

Checklist by scenario

Use this section like a preflight list. Pick the setup that matches your environment, then work through the steps in order.

Scenario 1: Point the root domain to a hosting server with an A record

This is the standard setup when your host gives you a public IPv4 address.

1. Confirm the destination IP address from your hosting provider.
2. Open the DNS zone where your domain is currently managed.
3. Find the A record for the root domain, often shown as @.
4. Replace the old IP with the new server IP.
5. If you use www, either point it with another A record or, more commonly, a CNAME to the root domain.
6. Leave existing MX, TXT, and other email-related records untouched unless you also intend to move email.
7. Save the change and test with DNS lookup tools and a browser.

This method is usually the cleanest option if you want to point a domain to a server without changing the rest of your DNS setup.

Scenario 2: Add an AAAA record for IPv6 hosting

If your host provides IPv6, you may also want an AAAA record.

1. Confirm the IPv6 address with your host.
2. Add or update the AAAA record for the hostname you want to serve.
3. Make sure your application, firewall, and web server are actually listening on IPv6.
4. Test both IPv4 and IPv6 paths after propagation.

If your host is not fully configured for IPv6, publishing an AAAA record too early can create hard-to-debug intermittent access issues. Some users may reach the site over IPv4 while others fail over IPv6.

Scenario 3: Point a subdomain to another hostname with a CNAME

This is common for managed services such as blog platforms, CDNs, storefronts, landing pages, or SaaS tools.

1. Get the target hostname from the provider, such as service.vendor.example.
2. Create a CNAME record for the subdomain, such as www, shop, or app.
3. Do not create conflicting A or AAAA records for that same hostname.
4. Add any required TXT verification records if the service asks for domain ownership validation.
5. Confirm the service is expecting the exact hostname you configured.

When comparing A record vs CNAME, the short version is this: use an A record when you are pointing directly to an IP, and use a CNAME when you are aliasing one hostname to another.

Scenario 4: Change nameservers to move DNS to a new provider

This is the broader move. Instead of changing individual records, you delegate the whole zone to another DNS platform.

1. Collect the new nameserver values from the DNS provider or host.
2. Before switching, recreate all required records in the new DNS zone: A, AAAA, CNAME, MX, TXT, SRV, and any custom records your services depend on.
3. Double-check email records carefully. Missing MX or TXT records can break mail even if the website resolves correctly.
4. Update the domain at the registrar to use the new nameservers.
5. Wait for propagation and compare the old and new zone behavior during the transition.

If you change nameservers without preparing the new DNS zone first, the domain may go partially or fully offline. Website and email issues often come from incomplete record migration, not from the nameserver switch itself.

Scenario 5: Connect a domain to shared hosting or managed WordPress hosting

Many beginner-friendly hosting platforms provide either a server IP or their own nameservers.

1. Check whether the host wants record-level DNS changes or full nameserver delegation.
2. If they provide a single IP, update the root A record and the www record as instructed.
3. If they provide nameservers, build or confirm the zone before switching.
4. Add the domain inside the hosting control panel so the host knows to serve that hostname.
5. Issue or activate SSL only after the domain resolves to the host, unless the provider supports prevalidation.

This is also where many launch delays happen: DNS may be correct, but the domain has not been added inside the hosting account, so the host returns a default page, 404, or certificate mismatch.

Scenario 6: Keep website hosting and email with different providers

This is a common and sensible setup. The website may move, but business email should stay where it is.

1. Identify current MX records and email TXT records such as SPF, DKIM, and domain verification entries.
2. Take a full export or screenshot of the DNS zone before changing anything.
3. Update only the web-related records: A, AAAA, or CNAME.
4. Do not delete MX records just because they look unrelated to the website.
5. After the website is live, send and receive a test email using the domain.

If you are planning a larger migration, the process overlaps with a good domain transfer checklist for moving a domain without downtime. The key difference is that domain transfer and DNS changes are separate tasks, even though people often perform them around the same time.

Scenario 7: Use a CDN or proxy in front of hosting

Some setups place a CDN, reverse proxy, or security edge between the domain and the origin host.

1. Point the DNS record to the proxy target or configure the record inside the CDN-managed zone.
2. Set the origin server to accept traffic from the proxy path and confirm host headers if needed.
3. Review SSL mode on both the edge and origin.
4. Test cache behavior, redirects, and canonical hostname rules.

In this model, DNS may point at the CDN rather than directly at your server. That is normal, but it makes verification more important because multiple layers are involved.

What to double-check

After any DNS update, there are a handful of checks that prevent most launch-day surprises. These apply whether you use cheap domain names, enterprise DNS hosting, shared hosting, or a scalable cloud environment.

1. The domain is added in the hosting platform

DNS can be correct while the host is still unprepared to serve the domain. Make sure the domain or subdomain is attached to the correct site, app, vhost, container ingress, or control panel account.

2. Root and www behave the way you expect

Decide which hostname is canonical:

• example.com
• www.example.com

Then make sure the other version redirects cleanly. Incomplete setups often leave one hostname working and the other broken, duplicated, or unencrypted.

3. SSL issuance and renewal

Once DNS points correctly, verify that the SSL certificate covers the hostnames you serve. Check:

• root domain coverage
• www coverage
• subdomain coverage if needed
• automatic renewal behavior

Do not assume SSL is active just because the host supports it. A valid certificate usually depends on the domain resolving to the right place first.

4. Redirects and application URLs

Many platforms keep an internal site URL or app base URL. If that value still points to a temporary domain, staging URL, or old host, you may see redirect loops, mixed content, broken logins, or asset paths that fail.

5. Email records are still intact

Check MX, SPF, DKIM, and any vendor-specific TXT records after the website switch. A website launch that breaks business email is usually more disruptive than a short web issue.

6. TTL before and after the change

If possible, lower TTL ahead of a planned move so resolvers refresh sooner during the cutover. After the change stabilizes, increase TTL to a more normal value if that suits your operational model. Lower TTL can make transitions smoother, but only if set early enough to expire old cached values.

7. Propagation from more than one network

Use command-line lookups, public resolvers, and real browser tests from different networks. DNS propagation is not always uniform. It is normal for one resolver to show the new answer while another still shows the old one for a while.

8. Backups and rollback notes

Before touching DNS, copy the existing zone and write down the previous values. If something breaks, rollback is much faster when you know exactly what changed.

If you are still deciding on the naming side of a launch, it is also worth reviewing best domain extensions for startups, SaaS, and developer projects before you lock in a production hostname that will appear in certificates, email signatures, and customer-facing URLs.

Common mistakes

Most DNS problems are not advanced technical failures. They are small configuration mismatches that slip through because the terms are easy to mix up.

Changing nameservers when only an A record was needed

If the goal is just to connect a website to a new host, a nameserver move may be unnecessary. Switching nameservers without copying the full zone often breaks unrelated services.

Deleting MX records during a website move

This happens often when someone assumes old records are clutter. Email routing records should only change when you are intentionally moving email.

Creating conflicting records

A hostname should not typically have both a CNAME and other record types attached to it. If a provider says to use a CNAME for www, remove conflicting A or AAAA records for that same hostname.

Pointing DNS correctly but forgetting the application layer

Examples include:

• virtual host not defined
• reverse proxy missing the hostname
• WordPress site URL still set to a temporary domain
• container ingress not updated
• SSL not yet issued

DNS gets the request to the right place. Your hosting stack still has to know what to do with it.

Adding an AAAA record without working IPv6 service

If the app or firewall is not ready for IPv6, some visitors may hit a dead end even though IPv4 users can load the site.

Testing too soon and assuming failure

DNS changes are not always instant. If records are correct, some inconsistency during propagation is expected. Test methodically instead of making repeated edits in quick succession.

Ignoring subdomains and service records

The main domain may work while forgotten records break login portals, API endpoints, support tools, or email authentication. Audit the full zone, not just the homepage hostnames.

When to revisit

This topic is worth revisiting whenever your infrastructure, provider mix, or launch workflow changes. DNS is not a one-time setup task. It is part of ongoing domain and hosting operations.

Review your setup in these situations:

• Before a migration: moving to new web hosting, changing DNS hosting, or introducing a CDN
• Before seasonal traffic periods: promotions, product launches, campaigns, or high-visibility events
• When adding services: email platforms, subdomains, verification tools, edge security, or multi-region routing
• When your team changes tools: new control panels, automation workflows, IaC, or registrar accounts
• After incident review: if a previous launch caused downtime, mail disruption, or SSL errors
• During documentation cleanup: whenever records have accumulated over time and no one is sure which are still required

A practical maintenance routine can be simple:

1. Export or document the current DNS zone.
2. Label records by purpose: web, email, verification, app, redirect, or legacy.
3. Confirm who owns each system: registrar, DNS provider, host, CDN, and mail provider.
4. Test root, www, key subdomains, HTTPS, and email delivery.
5. Record rollback steps before the next change window.

If you manage multiple sites, create a standard launch worksheet with these fields:

• domain registrar
• authoritative nameservers
• hosting destination
• canonical hostname
• SSL status
• MX provider
• TXT verification records
• TTL plan
• rollback values
• verification checklist

That small bit of discipline turns DNS from a fragile launch step into a repeatable operating procedure.

The short version is this: to connect domain and hosting correctly, first decide whether you need a record change or a nameserver change, update only what the chosen scenario requires, and verify both web and email before calling the launch complete. Keep this checklist handy for the next host move, site launch, or DNS cleanup, because the steps stay useful even when the tools and dashboards change.