How to Point a Domain to Your Hosting Provider: DNS Records Step by Step

Overview

When people say they want to “point a domain to hosting,” they usually mean one of two things:

• Change nameservers so the hosting provider controls the whole DNS zone.
• Update specific DNS records at the current DNS provider so the website points to the new hosting environment.

Both methods can work. The right choice depends on who should manage DNS, whether you already use external email or security services, and how much of the setup you want consolidated in one place.

Before you make any change, it helps to understand the records involved:

• A record: Points a hostname to an IPv4 address, commonly your web server IP.
• AAAA record: Points a hostname to an IPv6 address.
• CNAME record: Points one hostname to another hostname instead of an IP.
• MX record: Directs mail delivery for your domain.
• TXT record: Used for verification, SPF, and other text-based DNS data.
• NS record: Identifies which nameservers are authoritative for the domain or a delegated subdomain.
• CAA record: Specifies which certificate authorities may issue SSL certificates for the domain.

The main practical rule is simple: website records and email records are separate, but they live in the same DNS zone. That is why website moves sometimes break email. If you change nameservers without copying existing MX, SPF, DKIM, or verification records, mail flow can fail even though the site itself loads correctly.

A safe workflow looks like this:

1. Identify where DNS is currently hosted.
2. Collect the exact values required by your hosting provider.
3. Export or record your current DNS zone.
4. Choose between nameserver changes and individual record changes.
5. Apply changes carefully.
6. Verify the website, SSL, and email after propagation.

If you are still deciding on infrastructure, it may help to review how to choose between shared hosting, VPS, cloud hosting, and dedicated servers before changing DNS. The type of web hosting you choose often affects whether you receive a simple server IP, a platform hostname, or provider-managed nameservers.

Checklist by scenario

Use the checklist that matches your setup. In most cases, your hosting dashboard or welcome email will tell you exactly which values to use.

Scenario 1: New domain, new hosting, simplest path

This is the cleanest setup: you registered a domain and want it connected to a new hosting account.

1. Log in to your domain registrar.
2. Confirm the domain is active and not expired.
3. Locate the current nameserver settings.
4. Get the nameservers from your hosting provider.
5. Replace the registrar’s default nameservers with the hosting provider’s nameservers.
6. Save changes.
7. Wait for propagation, then confirm the provider has created the expected DNS zone records.
8. Visit the domain and verify that the correct site loads.

Best fit: Users who want one vendor to manage both web hosting and DNS.

Watch for: If you use third-party email or domain verification services, recreate those records at the new DNS host before or immediately after the nameserver change.

Scenario 2: Keep DNS at the registrar, point only the website

Many teams prefer to keep DNS with the domain registrar or a dedicated DNS provider, especially if they already use custom email, external CDN rules, or security services.

1. Log in where your DNS zone is hosted.
2. Find the root domain record, often shown as @.
3. Update the A record for @ to the new server’s IPv4 address.
4. If your host provides IPv6, update or add the AAAA record.
5. Find the www record.
6. Set www as a CNAME to the root domain or to the hostname your provider specifies.
7. Leave MX, TXT, and other unrelated records unchanged unless your provider tells you otherwise.
8. Save changes and test both example.com and www.example.com.

Best fit: Users who want DNS independence, easier migrations, or tighter control over records.

Watch for: Some registrars prefill parking records or forwarding settings. Remove conflicting old website records so there is only one valid answer for the hostname you are updating.

Scenario 3: Migrate an existing website to a new hosting provider

If the site is already live, your goal is to avoid downtime and reduce confusion during propagation.

1. Build and test the site on the new host before changing DNS.
2. Make sure the application, CMS, database, media, and SSL prerequisites are ready.
3. Reduce DNS TTL in advance if your provider allows it. This can make future changes update faster.
4. Copy the existing DNS zone so you have a rollback reference.
5. At cutover time, update either nameservers or the A/AAAA/CNAME records, depending on your DNS strategy.
6. Monitor the old and new environments during propagation.
7. Avoid making content changes on both servers during the switch, especially for CMS sites.
8. After traffic settles on the new host, decommission the old environment only after confirming logs, forms, uploads, and email-related functions.

Best fit: Website migration to cloud hosting, VPS hosting, or a different managed WordPress hosting platform.

Watch for: DNS propagation is not the only delay. Browser cache, application cache, CDN cache, and local resolver cache can all make a site appear inconsistent during a move.

Scenario 4: Connect a domain to managed WordPress hosting

Managed WordPress hosting often gives you either a target IP address, a temporary URL, or provider-managed DNS instructions.

1. Add the domain inside the WordPress hosting control panel first.
2. Check whether the provider expects an A record, a CNAME, or a nameserver change.
3. Create or update the required records.
4. Set the primary domain inside the hosting panel or WordPress management interface.
5. Make sure both the root domain and www point correctly.
6. After DNS resolves to the new host, issue or verify SSL.
7. Confirm WordPress site URL settings match the final domain.

Best fit: Users who want simplified administration and performance features without managing raw server configuration.

If your hosting evaluation is still open, compare practical business needs in Best Web Hosting for Small Business Websites.

Scenario 5: Move the website but keep third-party email untouched

This is one of the most common real-world needs. The website changes hosts, but business email stays where it is.

1. Identify current MX records.
2. Record existing mail-related TXT entries, including SPF, domain verification, and any DKIM selectors.
3. If changing nameservers, recreate these records in the new DNS zone before completing the switch.
4. If changing only website records, leave mail records unchanged.
5. After propagation, send and receive test messages from external accounts.

Best fit: Small business setups where domain registration, web hosting, and email are split across providers.

Watch for: Email outages often happen because teams treat a nameserver switch as a web-only change. It is not. It hands over the full DNS zone.

Scenario 6: Point a subdomain instead of the main domain

You may want app.example.com, staging.example.com, or shop.example.com to go to a different hosting environment.

1. Keep the existing apex domain records unchanged unless needed.
2. Create an A, AAAA, or CNAME for the subdomain only.
3. Confirm the new host is configured to serve that subdomain.
4. Apply SSL for the subdomain after it resolves.

Best fit: Multi-environment deployments, separate apps, or phased migrations.

This approach is often cleaner than moving the entire domain at once, especially for development teams using cloud hosting or scalable hosting across multiple services.

What to double-check

Before and after any DNS change, review these items. This is the checklist most people wish they had used the first time.

1. Where authoritative DNS actually lives

Your domain registrar is not always your DNS host. You might register the domain in one place and manage DNS somewhere else. Check the current nameservers before making assumptions.

2. Exact record values from the hosting provider

Do not guess. Some providers want an IP address. Others want a CNAME target. Others want you to change nameservers entirely. Copy the values exactly, including any trailing dots if the interface requires them.

3. Root domain and www behavior

Users often update only one hostname. Decide which version should be primary and make sure both resolve correctly. For example:

• example.com loads the site
• www.example.com loads the same site
• One version redirects consistently to the canonical version

4. TTL settings

TTL controls how long resolvers cache a record. Lower TTLs can make planned changes more responsive, but they do not override every cache layer on the internet. If you are planning a migration, lowering TTL ahead of time can help, but it is not an instant-update switch.

5. SSL issuance

Many hosts can issue SSL only after the domain resolves to their platform. If the site appears insecure after DNS changes, check whether the certificate has been issued, whether the domain was added correctly, and whether CAA records allow the intended certificate authority.

6. Email continuity

Review MX, SPF, DKIM, and verification TXT records whenever nameservers change. If you use email marketing or transactional mail services, those TXT or CNAME records may matter too.

7. CDN, proxy, or firewall layers

If a CDN or reverse proxy sits in front of the site, verify whether DNS should point to the origin server or to the CDN endpoint. Changing records incorrectly can bypass caching, break SSL expectations, or expose an origin that should stay private.

8. Application-level configuration

DNS may be correct while the site still fails because the application is not ready. Check virtual host settings, server blocks, WordPress site URL, redirect rules, and any origin restrictions. DNS only gets traffic to the right place; the application still has to answer correctly.

Common mistakes

The fastest way to troubleshoot DNS is to know the usual failure patterns.

Changing nameservers when only an A record was needed

If your only goal is to move the website, a nameserver change can be more disruptive than necessary. It transfers responsibility for the whole zone, not just the site.

Forgetting that DNS changes can overlap with caching

You may see the new site from one network and the old site from another. That does not always mean the records are wrong. It can reflect propagation or cache persistence.

Leaving conflicting old records in place

Multiple A records, stale CNAMEs, registrar forwarding, or parking entries can produce inconsistent results. Clean up the old website path once the new one is confirmed.

Breaking email during a website move

This deserves repetition because it is so common. Before changing nameservers, inventory all mail-related records and recreate them.

Using a CNAME at the apex where the provider does not support it

The root domain often has stricter DNS limitations than subdomains. If your provider supports flattened or alias-style behavior, follow its instructions. Otherwise use the supported record type.

Not adding the domain inside the hosting account first

Even perfect DNS will not work if the host is not configured for that domain. Add the domain, site, or vhost in the hosting dashboard before you switch traffic.

Testing too early and assuming failure

Give changes time, then test from multiple networks or devices. Check both the DNS answer and the site response. A resolved record and a working site are related, but they are not the same thing.

If you prefer to keep more control over your domain and hosting split, read Domain Registrar Comparison: Pricing, WHOIS Privacy, Transfers, and Renewal Costs. It can help you choose where registration belongs, even if the website lives elsewhere.

When to revisit

DNS is not a set-it-and-forget-it task. Revisit your setup whenever the underlying inputs change.

• Before switching hosts: Confirm whether the new provider wants nameservers, A records, or CNAMEs.
• Before seasonal traffic periods or launches: Verify DNS, SSL, redirects, and failover assumptions ahead of time.
• When adding email or marketing tools: Review TXT, MX, and verification records.
• When enabling a CDN or proxy: Make sure DNS points to the intended layer.
• When redesigning infrastructure: Reassess whether registrar DNS, host-managed DNS, or a separate DNS provider best fits your reliability and operations model.
• At renewal or transfer time: Check that nameservers and zone records will remain intact if the domain registrar changes.

A practical maintenance routine is simple:

1. Keep a current export or written copy of all DNS records.
2. Document which provider owns registration, DNS, hosting, email, and SSL.
3. Review records before any migration or major launch.
4. Test the website and email after every DNS-related change.
5. Remove obsolete records once the new configuration is stable.

If you are evaluating whether a move makes operational sense, these related guides may help: Cloud Hosting Pricing Explained for cost planning and The All-in-One Hosting Stack for thinking through convenience versus lock-in.

The short version is this: point the domain by changing only what your scenario requires, preserve unrelated records, and verify the full service chain after propagation. If you keep that discipline, connecting a domain to web hosting becomes a routine operation rather than a risky event.