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

Overview

If you want to connect a domain to hosting, you are really doing one of two things: either changing which DNS provider controls your records, or changing the records themselves so traffic goes to the right server or service.

That distinction matters because many connection problems come from mixing the two approaches.

Nameservers decide who manages DNS. If you switch nameservers at your domain registrar, you are telling the internet to use a different DNS zone entirely.

DNS records decide where specific traffic goes. If you keep your current nameservers, you can edit records such as A, CNAME, MX, and TXT within the existing DNS zone.

In practice:

• Use nameserver changes when your host or platform wants to manage the full DNS zone for you.
• Use record changes when you want to keep DNS where it is and point only the website or selected services to your new host.

Here are the core record types you will see most often:

• A record: Points a hostname to an IPv4 address. Common for root domains like example.com.
• AAAA record: Points a hostname to an IPv6 address.
• CNAME record: Points one hostname to another hostname. Common for www.
• MX record: Routes email for the domain.
• TXT record: Used for verification, SPF, DKIM, DMARC, and other text-based DNS data.
• NS record: Delegates DNS authority, often relevant for subdomains or zone management.

Two more ideas are worth keeping in mind:

• TTL is the cache lifetime for a record. Lower TTLs can help planned changes take effect more quickly, but not all providers or resolvers behave the same way.
• Propagation is the time it takes for DNS changes to be seen across different resolvers and locations. Some changes appear quickly; others can take longer because of caching.

If you are also evaluating hosting before making DNS changes, it is worth benchmarking first so you are not pointing a domain at an underperforming platform. See How to Benchmark Web Hosting Speed Before You Switch.

Checklist by scenario

Use the scenario below that matches your setup. The goal is to avoid changing more than necessary.

Scenario 1: Point a domain to a single web server using an A record

This is the most common setup for traditional web hosting, cloud hosting, or VPS-based web hosting.

1. Find your hosting server's public IP address in the hosting control panel.
2. Log in to the DNS provider that currently manages your domain's zone.
3. Locate the existing A record for the root domain, usually shown as @ or blank.
4. Replace it with the new server IP address.
5. Check whether there is an existing www record. If needed, point www to the root domain with a CNAME.
6. Save the changes.
7. Wait for DNS propagation and test both example.com and www.example.com.

Best for: standard hosting plans, cloud hosting instances, custom application servers, and many WordPress hosting setups.

Scenario 2: Point www or another subdomain using a CNAME

Many website builders and managed platforms ask you to create a CNAME rather than pointing directly to an IP address.

1. Get the target hostname from your hosting or website builder provider.
2. In DNS, create or edit the subdomain record, such as www.
3. Set the record type to CNAME.
4. Set the value to the target hostname provided by the platform.
5. Make sure you do not have conflicting A, AAAA, or CNAME records for the same hostname.
6. Save and test after propagation.

Best for: website builder platforms, CDN-backed apps, SaaS landing pages, and some one-click deployment services. If you are comparing simpler deployment options, see One-Click Deployment Platforms Compared for Simple Web Projects.

Scenario 3: Change nameservers and let the host manage DNS

Some hosts want you to replace the domain registrar's nameservers with the nameservers they provide. This hands over DNS management to the new platform.

1. Collect the new nameserver values from your host.
2. Before changing anything, export or copy your current DNS zone if possible.
3. List all records you need to preserve, especially MX, TXT, SPF, DKIM, DMARC, verification records, and any subdomains.
4. At your domain registrar, replace the old nameservers with the new ones.
5. Log in to the new DNS host and recreate any non-website records that are not added automatically.
6. Test the website, email, and third-party services after propagation.

Best for: simplified management when you want the host to control the full DNS configuration. It can be convenient, but it is also the most disruptive option if you forget to migrate email or verification records.

Scenario 4: Connect a domain to WordPress hosting

WordPress hosting providers may support either A records, CNAMEs, or full nameserver delegation. The safe approach is to confirm exactly which one they require before editing DNS.

1. Check whether the provider expects an IP address, a CNAME target, or nameserver changes.
2. Verify the domain is added inside the hosting dashboard as the primary or parked domain.
3. Update DNS using the provider's recommended method only.
4. Confirm that both the root domain and www variant are handled correctly.
5. After DNS resolves, issue or install SSL and confirm the WordPress site URL matches the live domain.

If you are deciding between platform types before you connect DNS, related reading may help: Website Builder vs WordPress: Which Is Better for Small Business? and How to Choose Hosting for High-Traffic WordPress Sites.

Scenario 5: Connect a domain without breaking email

This is the scenario people most often regret rushing through.

1. Identify where email is currently hosted.
2. Before editing DNS, document all MX records and relevant TXT records.
3. If you are only moving the website, keep existing MX and email-related TXT records unchanged.
4. If you are changing nameservers, recreate those email records on the new DNS provider before or immediately after the switch.
5. Send and receive test messages after propagation.

Rule of thumb: website DNS changes and email DNS changes are separate concerns. A site move should not require replacing mail records unless your mail provider is changing too.

Scenario 6: Migrate to a new host with minimal disruption

When moving an existing live site, DNS timing matters.

1. Build and test the new hosting environment first.
2. Lower TTL ahead of time if your DNS provider allows it and you have enough notice.
3. Keep the old hosting active during the transition.
4. Update DNS only after the new site is ready.
5. Monitor traffic, SSL, forms, admin login, and any API callbacks after the cutover.
6. Do not cancel the old host until you are confident traffic has fully shifted.

For a full cutover workflow, see How to Migrate a Website to a New Host Without Downtime.

What to double-check

Before you save DNS changes, pause and verify the details below. Most DNS issues are small input errors rather than large technical failures.

1. Who actually hosts your DNS?

Your registrar is not always your DNS provider. A domain can be registered in one place and have DNS managed somewhere else. Check the active nameservers first so you know where changes belong.

2. Are you changing nameservers or records?

Do not do both unless the host explicitly requires it. Changing nameservers and editing the old DNS zone at the same time creates confusion because once nameservers change, the old records may no longer matter.

3. Did you enter the correct hostname?

Many DNS interfaces use different ways to represent hostnames:

• @ may mean the root domain
• www may represent only the subdomain
• some panels auto-append the base domain
• some expect a fully qualified domain name

If the panel format is unclear, use its examples or documentation before saving.

4. Are there conflicting records?

A hostname should not have a CNAME and an A record at the same label in a normal setup. Likewise, an old AAAA record can keep some traffic going to the wrong destination even after you update the A record.

5. Did you preserve email and verification records?

Before changing nameservers, inventory your MX and TXT records. This step protects email delivery and third-party integrations such as search console verification, transactional mail, calendar tools, and identity providers.

6. Is the domain added inside the hosting account?

DNS may point correctly, but the host also needs to know to serve that domain. Confirm the domain is attached to the right site, application, or virtual host in the hosting panel.

7. Is SSL ready after DNS resolves?

Many hosting providers issue certificates automatically once DNS points correctly. That still may not be immediate. Test both HTTP and HTTPS, and verify that the certificate covers the exact hostnames you plan to use.

8. Are redirects configured deliberately?

Decide which version is canonical:

• https://example.com
• https://www.example.com

Then configure redirects so users and search engines land on one preferred version. This is especially important after a migration or platform change.

9. Are application settings aligned with the domain?

Some platforms cache the site's base URL. WordPress, custom frameworks, reverse proxies, and CDN layers may all need updates after DNS changes. If the site loads with broken assets or redirects incorrectly, this is one of the first places to check.

Common mistakes

The mistakes below show up repeatedly, even for experienced users.

Editing records in the wrong dashboard

You update DNS at the registrar, but the domain is using external nameservers, so nothing changes. Always verify where authoritative DNS is managed first.

Switching nameservers when only an A record change was needed

This is a common source of surprise email outages. If all you need is to point the website to a new host, editing the web-related records may be enough.

Forgetting the www version

Many users update the root domain and forget that www is a separate DNS record. Test both versions after the change.

Leaving stale AAAA records in place

If your old setup used IPv6 and your new host does not, traffic from some networks may keep reaching the old destination. Remove or update outdated AAAA records when appropriate.

Assuming propagation is identical everywhere

You may see the new site on your network while someone else still sees the old one. That does not always mean the change failed. It often means different resolvers are caching different answers.

Canceling the old host too early

Even after DNS appears updated, late traffic, cached content, or background jobs may still hit the previous server for a while. Keep the old environment available during the transition window.

Ignoring non-web records during nameserver changes

MX, TXT, SIP, verification, and subdomain records are easy to overlook. A website can appear fine while email or a third-party service quietly breaks.

Confusing DNS success with application success

A domain can resolve correctly and still show errors because the app is not configured for the domain, SSL is incomplete, or redirects are misconfigured. DNS is only one layer of the connection path.

If you are choosing between hosting models before making domain changes, these comparisons can help frame the tradeoffs: Shared Hosting vs Cloud Hosting: Which Should You Choose? and Cloud Hosting vs VPS Hosting: Performance, Cost, and Control.

When to revisit

DNS is not a one-time setup task. Revisit your domain and DNS configuration whenever the underlying inputs change.

Use this practical review list before major changes or seasonal planning cycles:

• Before changing hosting providers: confirm whether the new platform wants nameservers, A records, or CNAMEs.
• Before redesigning or rebuilding a site: check how the new platform handles root domains, www, redirects, and SSL.
• Before launching a store, campaign, or traffic-heavy event: verify DNS, SSL, canonical redirects, and any subdomains used for landing pages or checkout.
• When adding email or marketing tools: review MX and TXT records so you do not overwrite existing mail settings.
• When moving to managed WordPress hosting or a website builder: confirm the provider's preferred DNS method before you touch nameservers.
• When troubleshooting intermittent reachability: compare A, AAAA, CNAME, CDN, and proxy settings instead of assuming the host is at fault.

A good final habit is to keep a small DNS change log. Record the date, the records changed, the old values, the reason for the change, and who made it. That simple document makes future migrations and incident response much easier.

If your setup includes developer workflows, staging environments, or custom deployment paths, it also helps to standardize how domains are attached across projects. Related reading: Best Web Hosting for Developers: SSH, Git, Staging, and CLI Access.

Action checklist for your next DNS change:

1. Identify who manages authoritative DNS.
2. Confirm whether you need nameserver changes or only record edits.
3. Document current A, AAAA, CNAME, MX, and TXT records.
4. Update only the necessary records.
5. Check the host is configured to serve the domain.
6. Test root domain, www, HTTPS, redirects, and email.
7. Keep old infrastructure live until the change is clearly complete.

That process is simple enough to repeat, but disciplined enough to prevent the most common DNS mistakes. The next time you need to connect a domain to hosting, you should be able to return to this checklist, choose the matching scenario, and make the change with more confidence.