Connecting a domain to web hosting means directing DNS traffic to the server that stores your website, while keeping services such as email and verification records working. This guide explains when to change nameservers, when to edit individual DNS records, how to preserve MX records, and how to verify the result without guessing.
Overview
A domain and a hosting account are separate services. The domain is your website’s address; web hosting provides the server space and software that delivers the site. DNS connects the two by translating a hostname such as www.example.com into the destination required by your hosting provider.
There are two common connection methods:
- Change nameservers: You delegate DNS management to the hosting provider. The provider usually supplies two or more nameserver addresses, which you enter at the registrar where the domain is registered.
- Edit DNS records: You keep DNS management at the registrar or a separate DNS host and add records such as an A record for the root domain and a CNAME for
www.
Use the method documented by your host. Nameserver changes are often simpler for a new site, but they can replace an existing DNS zone. Direct record edits provide more control and are usually safer when the domain already supports business email, subdomains, verification tokens, or other services.
Before making a change, record the current DNS zone. Export it if your DNS provider supports exports, or take a screenshot and copy the existing A, CNAME, MX, TXT, and other important records into a temporary change log. This gives you a reference if a record is accidentally removed.
What to track
1. Your domain, registrar, and DNS host
Confirm where the domain is registered and where its authoritative DNS is managed. These may be different companies. The registrar controls registration settings and nameserver delegation; the DNS host controls the records that answer queries. If you edit records in the wrong control panel, the change will not affect live traffic.
2. The hosting destination
Find the exact destination supplied by the hosting account. Depending on the platform, this may be an IPv4 address for an A record, an IPv6 address for an AAAA record, a hostname for a CNAME, or provider-specific nameservers. Do not substitute a generic server address if the hosting dashboard gives you a site-specific value.
3. Website DNS records
The following reference covers the records most often involved in a basic website connection:
| Record | Typical name | Purpose | Important check |
|---|---|---|---|
| A | @ | Points the root domain to an IPv4 address. | Use the host’s exact IPv4 address. |
| AAAA | @ | Points the root domain to an IPv6 address. | Add it only when the destination is configured for IPv6. |
| CNAME | www | Points a subdomain to another hostname. | Do not place a CNAME beside another record with the same name. |
| MX | @ | Routes incoming email. | Preserve existing mail records unless you are intentionally moving email. |
| TXT | @ or a specified host | Stores verification, SPF, and other text-based settings. | Keep required verification and email-security records. |
Some hosts ask you to use an A record for both the root domain and www; others provide a CNAME for www. Follow the host’s instructions rather than copying a record from another project.
4. Email-related records
Changing a website’s destination does not automatically require moving email. If email is hosted elsewhere, keep its MX records and any related TXT records, including provider verification or sender-policy records. A nameserver change can replace the entire DNS zone, so recreate all required mail and verification records in the new DNS panel before or immediately after delegation. If email continuity is critical, plan the change as a migration rather than treating it as a simple website update.
5. Verification results
Track the time of each change, the record or nameserver edited, the expected value, and the observed result. Check the root domain, www, important subdomains, email delivery, HTTPS, and redirects separately. A site can appear correct at one hostname while another still points to an old server.
Cadence and checkpoints
Step 1: Prepare the hosting account
Add the domain inside the hosting control panel first. Many platforms require the domain to be attached to a specific site, document root, application, or virtual host before DNS can work. Note the assigned IP address, target hostname, nameservers, and any required verification record.
Step 2: Choose nameservers or individual records
For a new domain with no active services, changing nameservers may be the shortest path. At the registrar, replace the current nameservers with the complete set supplied by the host. Enter each value carefully; an incomplete set can leave DNS unavailable.
If the domain has live email or several connected services, consider keeping the current nameservers. Add or update the website’s A, AAAA, and CNAME records instead, leaving MX and unrelated TXT records unchanged.
Step 3: Set the intended hostname behavior
Decide whether the canonical website should use the root domain, www, or another hostname. Configure the alternate hostname to redirect to the preferred one through the hosting platform or web server. DNS points traffic to a destination; it does not, by itself, create an HTTP redirect.
Step 4: Allow for DNS caching
DNS changes are cached according to record TTL values and resolver behavior. Some networks may show the new destination before others. There is no single universal propagation time, so check from multiple networks or use a DNS propagation checker that queries different resolvers. During this period, avoid repeatedly changing records because each edit makes diagnosis harder.
Step 5: Verify the application and HTTPS
Open the root domain and www in a private browser window. Confirm that the expected site loads, links work, forms submit, and the preferred hostname redirects correctly. Then verify HTTPS at every public hostname. Certificate issuance may depend on DNS resolving to the correct host, and the certificate must cover the names visitors use.
For a broader launch review, use the website launch checklist. If you are moving an existing site, document the old destination and rollback plan as described in the website migration checklist.
How to interpret changes
If the root domain works but www does not, compare their records. The root may have an A record while www still has an old CNAME or A record. If neither works, verify that the active nameservers are the ones you edited and that the domain is attached to the correct hosting account.
If the website works but email stops, inspect MX records first. A nameserver change may have removed mail records, or an MX record may now point to the wrong provider. Restore the documented mail records and allow DNS caches to update. Do not change MX records merely because the website moved.
If a browser shows a certificate warning, check that DNS reaches the intended server, the certificate includes the requested hostname, and the hosting platform has completed its certificate setup. Mixed-content warnings are a separate application issue: the page may load over HTTPS while still requesting images, scripts, or styles over HTTP. See the guide to SSL certificate and HTTPS errors for a structured review.
If different devices show different sites, compare resolver results and local cache behavior before editing records again. Check for duplicate A or AAAA records, an old CDN configuration, or a second DNS provider. An unexpected AAAA record can send IPv6-capable visitors to a different destination than IPv4 visitors.
For each incident, classify the symptom as one of four types: delegation problem, record problem, hosting configuration problem, or application/SSL problem. This prevents a DNS edit from being used to solve an issue that actually belongs in the web server or application configuration. The DNS propagation troubleshooting guide can help separate caching from configuration errors.
When to revisit
Revisit this connection record at least quarterly for active projects, and immediately after any domain transfer, hosting migration, DNS-provider change, email-provider change, or new subdomain launch. A monthly check is sensible for sites that support important transactions, frequent deployments, or multiple third-party services.
At each checkpoint, confirm:
- The domain is registered to the intended account and renewal details are current.
- The authoritative nameservers are documented and still expected.
- A, AAAA, and CNAME records point only to approved destinations.
- MX and relevant TXT records still support email and verification services.
- The root domain and preferred alternate hostname resolve correctly.
- HTTPS certificates are valid for every public hostname, and redirects are consistent.
- Hosting backups, access controls, and rollback information are available.
Keep a short DNS change log with the date, operator, reason, previous value, new value, and verification result. When you next move the site or connect a service, that record turns a risky recollection into a repeatable workflow. For wider domain ownership and renewal checks, use the domain portfolio audit checklist and the domain renewal guide.
Action checklist: identify the active DNS host, back up the current records, attach the domain to hosting, choose nameservers or targeted records, preserve email records, test both root and www, verify HTTPS and redirects, then record the final configuration. Schedule the next review before closing the change.
