DNS Records Explained: A Practical Guide to Connecting a Domain to Hosting

Overview

DNS, or the Domain Name System, translates human-readable names such as example.com into destinations that browsers, mail servers, and other services can use. Your domain registrar, DNS provider, and hosting company may be three different services, or they may be combined in one control panel. Before changing anything, identify which provider is authoritative for the domain.

The authoritative provider is the service whose nameservers are delegated to your domain. That is where the active DNS zone is normally managed. Editing records at a registrar or hosting control panel that is not authoritative will not change the public DNS response, even if the interface looks correct.

Core DNS records

• A record: Points a hostname to an IPv4 address. This is commonly used to connect a root domain or subdomain to a hosting server.
• AAAA record: Points a hostname to an IPv6 address. Add it only when the destination is configured to support IPv6 correctly.
• CNAME record: Points one hostname to another hostname, rather than directly to an IP address. It is commonly used for subdomains such as www or service-specific destinations.
• MX record: Specifies which mail servers receive email for the domain. MX records work with a priority value; lower numbers generally indicate higher priority.
• TXT record: Stores text used for domain verification and email authentication, including SPF, DKIM, and DMARC-related configuration.
• NS record: Identifies the authoritative nameservers for a domain or delegated subdomain. Changing nameservers can move control of the entire DNS zone.

An A record versus a CNAME is not simply a matter of preference. Use the destination and the provider's instructions as the deciding factors. A CNAME is normally used for a hostname-to-hostname relationship, while an A record requires a specific IPv4 address. At the root of a domain, some DNS providers offer special alias records for hostname destinations; these are provider-specific and should not be assumed to work everywhere.

For broader setup planning, see How to Choose Web Hosting for a Small Business. If you are changing providers, also keep the website migration checklist open before editing DNS.

Checklist by scenario

Scenario 1: Connect a domain to a new website host

1. Record the current DNS zone, including A, AAAA, CNAME, MX, TXT, and NS records. Save screenshots or export a zone file if your provider supports it.
2. Confirm the new host's required destination. It may provide an IPv4 address, IPv6 address, hostname, or a nameserver pair.
3. Choose whether to update individual website records or delegate the domain to new nameservers. Updating individual records is more targeted; changing nameservers moves DNS management to another provider.
4. Update the root domain record as instructed. Configure www separately if it does not inherit or redirect through your hosting setup.
5. Leave email records unchanged unless email is also moving. Website hosting and email hosting can use different providers.
6. Confirm that the new host has the correct document root, virtual host, application configuration, and SSL setup before testing the live domain.
7. Test both the root domain and common variations such as www, HTTP, and HTTPS.

Scenario 2: Add a subdomain

1. Choose a clear hostname, such as app, docs, or shop.
2. Use an A or AAAA record when the subdomain should resolve directly to an IP address.
3. Use a CNAME when the service gives you a hostname as its destination.
4. Check whether the hosting platform requires the subdomain to be added inside its control panel as well as in DNS.
5. Issue or configure an SSL certificate for the subdomain before sending visitors to it.

Scenario 3: Set up professional email

1. Obtain the exact MX records from your email provider, including priorities and any required trailing dot conventions shown by that provider.
2. Remove obsolete MX records only after confirming that the old mail service is no longer needed.
3. Add the provider's TXT records for sender authentication and domain verification.
4. Check whether DKIM uses a TXT record or a CNAME delegation. Do not substitute one record type for another.
5. Send and receive test messages from more than one mailbox, then review authentication results where available.

For the email-specific details, use SPF, DKIM, and DMARC Explained for Domain Owners and the professional email setup guide.

Scenario 4: Verify a domain for a service

1. Copy the record name, type, and value exactly as supplied by the service.
2. Check whether your DNS panel automatically appends the domain name. If it does, enter only the host portion when instructed.
3. Preserve punctuation and quotation marks when the provider requires them, especially for TXT values.
4. Wait for the record to become visible, then use the service's verification control.
5. Remove temporary verification records only if the service says they are no longer required.

What to double-check

Before saving a DNS change, use this short review:

• Correct zone: You are editing the authoritative DNS provider, not a disconnected hosting or registrar interface.
• Hostname format: The panel may expect @, a blank field, the full domain, or only a label such as www. Follow that panel's convention.
• Record conflicts: A hostname should not normally have a CNAME alongside other record types. Check for an existing record with the same name before adding one.
• Old destinations: Remove or replace obsolete website records, but do not delete MX or email authentication records merely because the website is moving.
• TTL: A record's time to live influences how long resolvers may cache it. Lowering TTL before a planned change can help, but it does not instantly clear caches that already hold a previous value.
• IPv6: An incorrect AAAA record can cause some visitors to reach the wrong server even when the A record is correct. Remove an unused AAAA record or configure IPv6 properly.
• SSL and application settings: DNS only directs traffic. The destination still needs the domain configured, the application deployed, and HTTPS enabled.

DNS propagation is often described as if one central update must travel across the internet. In practice, different recursive resolvers may retain cached answers for different periods. A change can therefore appear from one network before another. Check from more than one connection and avoid repeatedly changing records while waiting, because each new change makes diagnosis harder.

For a useful test, query the record type directly using a DNS lookup tool or a command such as dig or nslookup. Compare the authoritative answer with the answer from a public recursive resolver. If the authoritative answer is wrong, the zone configuration needs attention. If it is correct but a recursive resolver still shows the old answer, caching may be the explanation.

Common mistakes

• Changing nameservers without copying required records: A new DNS provider starts with its own zone. If MX, TXT, verification, or subdomain records are missing, services can stop working after delegation.
• Pointing email at the web host by assumption: Website hosting does not automatically mean that the same provider handles email. Use the mail provider's MX records.
• Using an IP address in a CNAME: CNAME values are hostnames. Use an A or AAAA record for an IP address.
• Adding duplicate SPF records: SPF is published through TXT and should be consolidated according to the email provider's instructions rather than added as unrelated duplicate policies.
• Forgetting the www hostname: The root domain and www are separate DNS names. Configure both, or deliberately redirect one to the other.
• Editing records during a migration without a rollback plan: Save the original values and note the time of each change. This makes it possible to restore the previous destination if needed.
• Testing only from an administrator's network: Local DNS caches, corporate resolvers, VPNs, and browser caches can produce a misleading result. Test through multiple resolvers and devices.

If the site is reachable but slow after a DNS change, the issue may be hosting, application performance, or caching rather than DNS. The guide to speeding up a slow website on shared hosting can help separate those problems.

When to revisit

Keep this checklist with your domain and hosting records, and revisit it whenever the underlying setup changes. Good checkpoints include a hosting migration, a change in email provider, a new subdomain, a CDN or security service rollout, a domain transfer, or a seasonal launch when traffic and business-critical workflows receive extra attention.

Review the DNS zone before planned changes rather than during an outage. Confirm that registrar access, DNS-provider access, hosting access, and email-provider access are available to the appropriate administrators. Check domain renewal status, nameserver delegation, SSL coverage, backups, and the current contact or escalation path. A hosting control panel may simplify record editing, but it does not replace a saved inventory of important records.

Use this final action list before closing a DNS task:

1. Write down the intended hostname, record type, destination, and reason for the change.
2. Export or capture the current zone.
3. Confirm the authoritative nameservers.
4. Make the smallest possible change.
5. Record the time, expected effect, and rollback value.
6. Test DNS resolution, the website, HTTPS, forms, and email as applicable.
7. Check again from an independent network or resolver.
8. Update your internal documentation once the change is confirmed.

DNS management becomes much less risky when every record has a known purpose and every change has a recovery path. Treat this page as a working reference, and update your own checklist when your hosting, email, deployment, or security workflow changes.