Connecting a domain to web hosting means directing the domain’s DNS records to the server or platform that delivers your website. This reusable checklist explains when to use nameservers, when to edit individual records, how to preserve email, how to activate SSL, and how to verify the result before launch.
Overview
Your domain registrar and web host are often separate services. The registrar manages the domain registration, while the host stores and serves the website. DNS connects the two by translating a domain such as example.com into the destination used by the hosting provider.
Before changing anything, collect these details:
- The registrar account that controls the domain.
- The hosting account and the provider’s connection instructions.
- The hosting destination, usually an IPv4 address, IPv6 address, hostname, or platform-specific target.
- Any existing email, verification, or third-party service records.
- A record export or screenshots of the current DNS zone, if the registrar provides them.
There are two main connection methods:
- Change nameservers: Replace the registrar’s authoritative nameservers with nameservers supplied by the hosting or DNS provider. That provider then manages the domain’s DNS zone.
- Edit DNS records: Keep the current DNS provider and add or change only the website records, commonly an A record, AAAA record, or CNAME record.
Nameserver changes are convenient when the host should manage the entire DNS zone, but they can affect every service using the domain. Direct record changes offer more control and are often safer when email, verification services, subdomains, or other applications must remain with their current providers.
Checklist by scenario
Scenario 1: You are launching a new website with no existing email
- Open the hosting dashboard and find its domain connection instructions.
- Choose whether the host expects nameserver changes or specific DNS records.
- If using nameservers, copy both or all required nameserver addresses exactly. At the registrar, replace the existing nameservers and save.
- If using records, add the host’s required A, AAAA, or CNAME records. Remove only obsolete website records, not records you do not recognize.
- Set the root or apex domain, such as
example.com, and thewwwhostname according to the host’s instructions. A common arrangement uses an A record for the root and a CNAME forwww, but provider requirements differ. - Wait for DNS changes to become visible, then test both the root domain and
wwwversion in a browser. - Activate the hosting provider’s SSL certificate and confirm that the site loads over
https://.
Scenario 2: The domain already has email
Do not replace nameservers or reset the DNS zone without documenting email records first. Email commonly depends on MX records and may also require TXT records for SPF, DKIM, and DMARC. If those records disappear, website connectivity may appear successful while mail delivery or authentication fails.
- Record the current MX, TXT, CNAME, and any provider-specific records.
- Prefer changing only the website records if the current DNS provider already works for email.
- If nameservers must change, recreate the email records in the new DNS zone before or immediately after the change, using the mail provider’s current instructions.
- Send and receive test messages using more than one mailbox where practical.
For a deeper email-specific workflow, see SPF, DKIM, and DMARC Setup for Domain Email.
Scenario 3: You are connecting a domain to WordPress
- Complete the DNS connection in the hosting dashboard or at the DNS provider.
- Confirm that the WordPress installation has the intended site URL and does not continue using a temporary hosting address.
- Enable SSL at the host, then check that the WordPress and site address settings use HTTPS.
- Test the homepage, internal links, images, forms, redirects, and the administrative login in a private browser window.
- Clear relevant caches only after DNS and SSL are working; otherwise, caching can hide the actual configuration problem.
When moving an existing WordPress site, treat DNS as one part of a wider migration. Use the website migration plan to coordinate files, databases, redirects, testing, and the final DNS switch.
Scenario 4: You are adding a subdomain
A subdomain such as shop.example.com or app.example.com can point to a different service from the main website. Add the exact hostname requested by the destination provider. Use a CNAME when the provider gives you a hostname; use an A or AAAA record when it gives you an IP address. Then verify the subdomain directly rather than assuming the root domain’s configuration applies.
DNS record reference
| Record | Typical purpose | What to check |
|---|---|---|
| A | Points a hostname to an IPv4 address | Use the exact address supplied by the host. |
| AAAA | Points a hostname to an IPv6 address | Add it only when the destination and hosting setup support IPv6. |
| CNAME | Points a hostname to another hostname | Follow the provider’s required target and note that apex-domain support varies. |
| NS | Delegates DNS management to nameservers | Change these only when you intend to move DNS authority. |
| MX | Routes incoming email | Do not delete or replace it during a website change unless email is also moving. |
| TXT | Stores verification and email policy data | Preserve relevant SPF, DKIM, DMARC, and service-verification values. |
What to double-check
Nameservers versus records: Confirm which system is authoritative before editing DNS. If you edit records at a registrar that is not currently providing authoritative DNS, the changes may have no effect.
Host and record names: Some control panels expect the root as @; others expect the full domain or a blank host field. Follow the panel’s field labels and avoid duplicating the domain if the interface appends it automatically.
TTL settings: TTL controls how long resolvers may cache a DNS answer. A lower TTL can make planned changes easier to test, but it does not force every resolver to refresh immediately. Record the original value and restore the provider’s recommended setting after the change if appropriate.
IPv4 and IPv6: An incorrect AAAA record can send IPv6-capable visitors to the wrong server even when the A record is correct. Remove or correct stale IPv6 records rather than assuming the A record covers both protocols.
SSL and redirects: DNS only directs traffic; it does not itself issue an SSL certificate. Activate the certificate through the host or certificate provider, then test HTTP-to-HTTPS redirects, the root domain, www, and representative page URLs.
Verification: Check DNS with a DNS lookup tool, dig, or nslookup from more than one network or resolver when possible. Compare the returned values with the hosting instructions. A browser test should follow the DNS check, not replace it.
Common mistakes
- Changing nameservers without copying email records: This can disconnect mail even if the website works. Use the DNS records troubleshooting guide before making a zone-wide change.
- Leaving an old A record in place: Conflicting records may produce inconsistent results between visitors or networks. Keep only the records required by the current setup.
- Expecting instant propagation: DNS caches update on different schedules. Check authoritative data and allow time for recursive resolvers to refresh before repeatedly changing records.
- Testing only one hostname: Test the root domain,
www, important subdomains, and both HTTP and HTTPS. - Forgetting domain status and renewal: A domain can be correctly configured yet still stop resolving if it expires or is suspended. Review the domain expiration and renewal guide.
- Deleting records that seem unrelated: Verification, email, analytics, payment, and security services may depend on records that do not look like website records.
- Making the final change before testing the new host: Where the host supports a temporary URL, preview domain, or local verification method, test the site before switching production DNS.
If the domain remains parked, first confirm which nameservers are authoritative and whether the expected A, AAAA, or CNAME record is visible there. If DNS points correctly but the host shows a default page, check the hosting account’s domain assignment, document root, and virtual-host configuration. If only some networks show the old site, compare resolver results and wait for cached answers to expire rather than switching records repeatedly.
When to revisit
Use this checklist whenever you launch a site, add a subdomain, change hosting, move DNS providers, connect WordPress, or alter domain email. Revisit it before seasonal planning cycles and before a high-traffic launch so there is time to document current records and lower risk. It is also worth reviewing after a registrar or hosting-panel redesign, a change to SSL workflows, or the addition of IPv6.
For a practical final pass, save a current DNS record list, confirm the registrar renewal date, verify the hosting account’s domain assignment, test the root and www hostnames over HTTPS, and send an email test if the domain handles mail. Keep the result with your operational notes. When the next migration or provider change arrives, that record becomes the starting point instead of guesswork. If the change includes moving the domain itself, consult the domain transfer playbook and separate the registrar transfer from the DNS cutover plan.
