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

Overview

If you need to connect a domain to hosting, there are really two separate decisions to make:

1. Where will DNS be managed? This is usually your registrar, your web host, or a third-party DNS provider.
2. How will traffic be pointed? Usually by changing nameservers or by editing specific DNS records such as an A record or CNAME.

That distinction matters because many DNS mistakes happen when users mix those two methods. If you change nameservers to a host, that host becomes authoritative for DNS. If you keep nameservers where they are, you usually should not also try to manage the same live records somewhere else.

Before making any change, collect the following:

• Your registrar login
• Your current DNS provider login
• Your hosting account details
• The target IP address for the website, if your host provides one
• The exact DNS records required by your host or mail provider
• A backup or screenshot of current DNS settings

For most websites, the records that matter are straightforward:

• A record: points a hostname to an IPv4 address
• AAAA record: points a hostname to an IPv6 address
• CNAME: points one hostname to another hostname
• MX: routes email for the domain
• TXT: used for verification, SPF, and other text-based policies
• NS: identifies which nameservers are authoritative for the domain

If you are brand new to hosting decisions, it helps to understand your hosting environment before editing DNS. A small brochure site on shared hosting will usually need a simpler setup than an application on VPS hosting or cloud hosting. For that comparison, see Shared Hosting vs VPS vs Cloud Hosting: Which Option Fits Your Website in 2026?.

A practical rule: change as little as necessary. If your website is moving but email should stay where it is, update only the records needed for the website and leave the mail records intact.

Checklist by scenario

This section gives you the most common ways to point a domain to hosting. Use the scenario that matches your setup rather than trying to combine all of them.

Scenario 1: Change nameservers to your web host

Use this when your host wants to manage all DNS for the domain and provides nameservers like ns1.examplehost.com and ns2.examplehost.com.

1. Log in to your domain registrar.
2. Find the domain management area.
3. Open the nameserver settings.
4. Replace the current nameservers with the nameservers supplied by your hosting provider.
5. Save the change.
6. Log in to the new DNS zone at your hosting provider and confirm the required records exist for the root domain, www, email, and any subdomains.

Best for: simple setups, new websites, and users who want DNS and web hosting in one control panel.

Watch for: if you switch nameservers and the new DNS zone does not include your old MX, TXT, or verification records, mail and related services may stop working.

Scenario 2: Keep current nameservers and point the website with an A record

Use this when you want DNS management to stay at the registrar or a third-party provider, but the website should load from a new hosting server.

1. Find the server IP address in your hosting panel or welcome email.
2. Log in where DNS is currently managed.
3. Edit the A record for the root domain, often shown as @, to the new server IP.
4. Edit or create the A record for www if your provider uses A records for both.
5. If your provider prefers www as a CNAME, point www to the root domain or the hostname specified by the host.
6. Save changes and test after propagation.

Best for: migrations where you want to keep existing mail and DNS records untouched.

Watch for: old CDN, firewall, or reverse proxy records that may still sit in front of the origin server.

Scenario 3: Point a subdomain to different hosting

This is common when the main site stays on one platform but an app, store, staging site, or docs site lives elsewhere.

1. Choose the subdomain, such as app.example.com or blog.example.com.
2. Create an A record to the target IP, or a CNAME to the hostname your provider gives you.
3. Make sure the hosting platform is configured to accept that subdomain.
4. Install or issue SSL for the subdomain once DNS resolves correctly.

Best for: mixed infrastructure and gradual migrations.

Watch for: a CNAME at a hostname that already has other incompatible records.

Scenario 4: Keep website DNS the same but preserve email elsewhere

This is one of the most common and most important scenarios. You may be moving website hosting while email remains with a separate provider.

1. Before editing anything, export or note the current MX records.
2. Also note relevant TXT records used for SPF, DKIM, verification, or mail policy.
3. Update only the website-related A or CNAME records.
4. Do not delete MX or mail-related TXT records unless you are also migrating email intentionally.
5. After propagation, send a test email in and out of the domain.

Best for: businesses that separate website hosting from email hosting.

Watch for: hosts that auto-generate zone files and overwrite custom mail records during setup.

Scenario 5: Connect a domain to managed WordPress hosting

Many managed WordPress hosting platforms prefer either an A record to a dedicated IP or a CNAME to a platform hostname.

1. Add the domain in the WordPress hosting dashboard first.
2. Follow the platform’s preferred DNS method exactly.
3. Create the root and www records as instructed.
4. Wait until the platform validates the domain.
5. Issue or enable SSL after DNS is live.
6. Confirm the WordPress site URL settings are correct once traffic reaches the host.

If you are still comparing hosting types for a CMS site, see Best Web Hosting for Small Business Websites: Features, Limits, and Upgrade Paths.

Scenario 6: Move a live site from one host to another with minimal disruption

This requires a little planning because you want DNS cutover to happen after the new host is ready.

1. Build and test the site on the new host first using a temporary URL, preview domain, hosts file override, or platform preview method.
2. Copy files, databases, media, and application settings.
3. Lower the DNS TTL on key records in advance if your DNS provider allows it.
4. Schedule the cutover during a low-traffic period.
5. Update the A record or nameservers when ready.
6. Monitor site availability, SSL, redirects, forms, and mail flow after the change.
7. Keep the old host active until you are sure traffic has fully shifted and rollback is no longer needed.

Best for: production moves where uptime matters.

Watch for: stale caches, hardcoded URLs, and hidden dependencies such as SMTP relays or API allowlists tied to the old server IP.

What to double-check

These are the details that prevent most avoidable DNS problems. Use them as a preflight and post-change checklist.

1. Where DNS is authoritative

Make sure you know which platform is the live source of truth. If the domain uses your registrar’s nameservers, edits at the host will not matter unless the host is actually authoritative. If the domain uses the host’s nameservers, edits at the registrar’s DNS area will not affect live traffic.

2. Root domain and www behavior

Confirm whether both the apex domain and www resolve correctly. Many users point only one and forget the other. Decide which version should be canonical and redirect the alternate version consistently.

3. Mail records

Check MX, SPF-related TXT records, and any other mail authentication entries before and after the change. Website DNS and email DNS often share the same zone, so a web change can accidentally break email.

4. TTL and propagation expectations

DNS changes are not always instant. TTL controls how long resolvers may cache answers. Even when the new record is correct, some users may still see the old destination for a period. Plan launches and migrations accordingly.

5. SSL certificate issuance

Many hosts can only issue or validate an SSL certificate after DNS points correctly. If the site loads over HTTP but not HTTPS after a cutover, check whether the certificate has been issued, attached, and bound to the right hostname.

6. CDN, proxy, or firewall layers

If you use a reverse proxy, web application firewall, or CDN, confirm whether the DNS target should be the origin server or the proxy hostname. This is a common source of confusion during migrations.

7. Application-level settings

DNS may be correct while the application still points to the old domain or URL. Check WordPress site URL settings, environment variables, redirect rules, and any hardcoded asset or API endpoints.

8. Hosting readiness

Before you point the domain, make sure the hosting account is actually ready. The virtual host, document root, database connection, and SSL path should be in place first. A correct DNS record cannot fix an incomplete server configuration.

If you are setting up a new domain as part of the process, you may also find How to Choose a Domain Name in 2026: Availability, Branding, SEO, and TLD Tips useful.

Common mistakes

Most DNS problems are small configuration mismatches rather than major outages. These are the mistakes that show up repeatedly.

Changing nameservers when only an A record was needed

If your goal is only to point the website to a new host, a nameserver change may be unnecessarily disruptive. It can move the entire zone, including mail and verification records, to a new provider.

Editing records in the wrong DNS panel

Users often edit records at the registrar while the domain actually uses third-party nameservers, or they edit records at the host while the registrar remains authoritative. Always verify the active nameservers first.

Deleting MX or TXT records during cleanup

When a DNS zone looks cluttered, it is tempting to remove records that do not look web-related. That can break email, domain verification, or sender authentication. If you do not know what a record does, document it before removing it.

Using a CNAME where it should not be used

Some DNS providers restrict CNAME use at the root domain. Others provide special alias-like records for the apex. Follow the provider’s supported method rather than forcing a CNAME where it is not valid in that environment.

Not adding the domain inside the hosting platform

DNS is only half the connection. Many hosting platforms require you to add the domain, map it to a site, or configure the server block before requests will work properly.

Ignoring www redirects and canonical handling

It is common for the root domain to work while www does not, or vice versa. Treat both as part of the same launch checklist.

Cutting over before the new site is fully tested

DNS should be one of the last steps, not the first. Build, test, and verify the application before you point production traffic to it.

Canceling the old host too early

Keep the old environment available until DNS propagation, cache expiry, and functional testing are complete. This is especially important for dynamic websites, e-commerce sites, and systems with forms or login sessions.

When to revisit

DNS and domain hosting settings are not something you configure once and forget forever. Revisit this checklist whenever the underlying inputs change.

• Before changing hosts: confirm which records must move and which must stay, especially mail records.
• Before changing registrars: verify whether DNS will remain where it is or be transferred as part of the move.
• Before switching DNS providers: replicate the full zone first, then cut over nameservers.
• Before launching a redesign or migration: test the site on the target host and plan the DNS cutover window.
• Before seasonal traffic periods: avoid ad hoc DNS work during your busiest times unless necessary.
• After adding new services: email platforms, CDN layers, verification tools, and security products often require new DNS entries.
• After staff or workflow changes: document where DNS is managed so future changes happen in the right place.

Here is a simple action plan you can reuse every time:

1. Identify the authoritative DNS provider.
2. Export or capture the current zone.
3. List the exact records needed for web, mail, and verification.
4. Choose the correct method: nameserver change or record edit.
5. Prepare the hosting platform first.
6. Make the DNS change.
7. Test root domain, www, subdomains, SSL, redirects, and email.
8. Keep the old setup available until you are confident the transition is complete.

For teams reviewing broader hosting choices before a move, it is worth comparing platform limits, upgrade paths, and support quality, not just the DNS mechanics. A better hosting fit often reduces the number of moving parts in future migrations.

Done well, connecting a domain to hosting is not complicated. The key is understanding which system controls DNS, changing only what is necessary, and verifying website and email behavior separately. Save this checklist, and revisit it whenever you change registrars, hosts, DNS providers, or launch workflows.