How to Connect a Domain Name to Web Hosting: DNS Records and Setup Checklist

Overview

Your domain registrar manages the domain registration, while your hosting provider stores and serves the website. DNS acts as the directory between them: it tells browsers which server should answer for a domain and tells mail systems where email should be delivered.

Before you connect a domain to hosting, collect these details:

• The account or control panel used for DNS management.
• The hosting provider’s required nameservers, server IP address, or target hostname.
• The website’s preferred hostname, such as example.com or www.example.com.
• Any existing email, verification, analytics, or third-party service records.
• A recent copy or export of the current DNS zone, if your provider supports it.

There are two main ways to connect a domain. Changing nameservers delegates DNS management to the hosting provider. Editing individual DNS records keeps DNS management at the current provider and points only selected services to the new host. The right choice depends on where you want to manage DNS and whether the domain already supports email or other services. For a detailed comparison, see Nameservers vs DNS Records.

Checklist by scenario

Scenario 1: Use the hosting provider’s nameservers

This is often the simplest option for a new website when the hosting provider is intended to manage the complete DNS zone.

1. Sign in to the hosting control panel and locate the assigned nameservers.
2. Record the current nameservers before making changes.
3. Open DNS or nameserver management at the domain registrar.
4. Replace the existing nameservers with the provider’s nameservers, entering them exactly as supplied.
5. Save the change and note the time it was made.
6. Confirm that the hosting account includes the correct domain and that the website files or application are in place.
7. Recreate or verify email, verification, and security records in the new DNS zone before relying on the domain.

Changing nameservers can move control of all DNS records, not just the website. If the domain already uses business email, subdomains, external services, or custom verification records, inventory those records first. A nameserver change without an equivalent DNS zone can interrupt services even when the website itself is configured correctly.

Scenario 2: Point the domain with an A record

Use this approach when DNS should remain with the current provider and the host has supplied an IPv4 address.

1. Open the authoritative DNS management panel for the domain.
2. Find the apex or root record, commonly shown as @ or the bare domain.
3. Create or update an A record with the host’s IPv4 address.
4. Check whether an existing conflicting A record, forwarding record, or parked-domain record needs to be removed.
5. Configure the www hostname separately, usually with a CNAME record or an additional A record according to the host’s instructions.
6. Save the records and confirm that the hosting account accepts both the root domain and the chosen www arrangement.

Do not guess the IP address. Hosting accounts can use different addresses for different servers, environments, or services. Copy the value from the hosting provider’s control panel or setup instructions.

Scenario 3: Point a subdomain with a CNAME record

A CNAME record aliases one hostname to another hostname. It is commonly used for subdomains such as app.example.com, docs.example.com, or www.example.com when the destination provider supplies a hostname rather than an IP address.

1. Confirm the exact source hostname, such as docs or www.
2. Enter the provider’s target hostname in the CNAME value field.
3. Do not add an extra protocol such as https:// unless the DNS interface explicitly requires it.
4. Check that no A, AAAA, or other conflicting record already exists for the same hostname.
5. Complete any verification step required by the destination service.

A CNAME is not normally used at the root domain because DNS providers handle root records differently. Follow the hosting provider’s documented method for the apex domain rather than substituting a CNAME without confirmation.

Scenario 4: Connect WordPress, cloud hosting, or a VPS

Pointing DNS is only one part of the setup. For WordPress hosting, confirm that the domain is added to the correct site, the application is installed, and the preferred URL is configured consistently. For cloud hosting or a VPS, also check the virtual host, reverse proxy, firewall, and web server configuration. A DNS record can resolve correctly while the server still returns the wrong site or a default page.

Before switching production traffic, take a backup and test the site on a temporary hostname or staging environment where practical. The VPS hosting setup checklist and WordPress staging guide provide useful preparation steps.

What to double-check

• Authoritative DNS: Make changes at the provider named by the domain’s active nameservers. Editing DNS somewhere else will not affect the live domain.
• Record conflicts: Avoid multiple A records, an A record and CNAME for the same hostname, or old forwarding records that compete with the intended destination.
• TTL: The time-to-live value influences how long resolvers may cache an answer. Lowering TTL before a planned change can make testing and rollback more predictable, but cached results may still persist.
• Both hostnames: Test the root domain and www version. Decide which is canonical and redirect the other consistently.
• Email DNS records: Preserve MX records and review SPF, DKIM, and DMARC records before changing nameservers. These records support email delivery and authentication and are separate from website routing.
• SSL certificate: Issue or activate an SSL certificate after the domain points to the correct host. Test HTTPS, redirects, and certificate coverage for every hostname in use.
• Application configuration: Update the site URL, allowed domains, callbacks, webhooks, and any firewall allowlists that depend on the domain.
• IPv6: If an AAAA record exists, verify that the IPv6 destination serves the same site. An incorrect AAAA record can cause some visitors to reach the wrong server even when the A record is correct.

Propagation is not a single global event. Different networks, devices, and DNS resolvers can show old and new answers at different times. Check from more than one network and use DNS lookup tools to compare the A, AAAA, CNAME, MX, and nameserver responses. Avoid repeatedly changing records while waiting, because each change makes diagnosis harder.

Common mistakes

• Changing nameservers without copying email records: The website may work while email stops arriving. Export or document the existing DNS zone first.
• Putting a full hostname in the wrong field: Some panels append the domain automatically. Entering www.example.com in a field expecting only www can create an unintended hostname.
• Using the wrong record type: Use an A record for an IPv4 address and a CNAME for a hostname target unless the provider specifies another method.
• Forgetting the hosting account configuration: DNS can point to the right server, but the server must still recognize the domain and serve the intended site.
• Testing only one URL: Check HTTP and HTTPS, the root and www hostnames, important pages, forms, login areas, and assets.
• Deleting records during troubleshooting: Remove only records confirmed to be obsolete. Keep a dated backup of the previous configuration so you can restore it.
• Assuming SSL fixes every HTTPS problem: Mixed content, redirect loops, incorrect canonical URLs, and proxy settings may require separate fixes. See the guide to mixed content and SSL errors.

If the change fails, use a controlled rollback: restore the previous nameservers or DNS values, wait for caches to update, and confirm the old host is still available. Keep the new configuration documented so you can compare each value rather than starting over.

When to revisit

Return to this checklist before a hosting migration, domain transfer, nameserver change, server rebuild, or major DNS provider change. It is also useful before seasonal traffic periods, product launches, planned maintenance, and changes to business email or security services.

Review the DNS zone whenever a new subdomain, third-party application, email platform, CDN, analytics tool, or verification service is introduced. Keep an internal record of the domain’s registrar, authoritative nameservers, hosting destination, SSL arrangement, email records, and rollback values. Include the date of the last review and the person responsible for the change.

For a final launch pass, combine this guide with the website launch checklist. Then run this short action list:

1. Back up the current DNS zone and website.
2. Confirm whether you are changing nameservers or individual records.
3. Apply only the records supplied by the hosting or service provider.
4. Verify website, email, subdomains, and SSL separately.
5. Monitor from multiple networks and document the final working configuration.