DNS Records Explained: A Practical Setup and Troubleshooting Guide for Websites

Overview

The Domain Name System, or DNS, translates human-readable names such as example.com into the addresses and services computers use. Your domain registrar, hosting provider, email platform, and security tools may all be involved in DNS management, but only the authoritative nameservers publish the records that visitors and mail servers ultimately read.

Before changing anything, identify where DNS is managed. Sign in to the registrar or DNS provider listed for the domain, then check the nameserver delegation. If the domain uses nameservers supplied by a web host, records may be managed in the hosting control panel. If it uses a separate DNS provider, changes made in the hosting panel may have no effect.

A record has several important fields: the record name or host, the record type, the destination or value, and the time to live (TTL). The root domain is often represented by @, while www is a subdomain. A hosting provider should give you the exact destination values to use. Do not substitute an address from a different server or copy records from an unrelated domain.

DNS records explained

• A: Points a hostname to an IPv4 address. It is commonly used for a website hosted on a server with an IPv4 address.
• AAAA: Points a hostname to an IPv6 address. Add it only when the destination is correctly configured for IPv6.
• CNAME: Aliases one hostname to another hostname. It is frequently used for www or third-party services. A CNAME normally should not be placed at the root domain where the DNS provider does not support that behavior.
• MX: Specifies which mail servers receive email for the domain. MX records use a priority value; lower numbers generally indicate higher priority.
• TXT: Stores text used for verification and email authentication, including SPF-related policy, DKIM keys, and other service checks.
• NS: Identifies the authoritative nameservers for a domain or delegated subdomain. These records determine where DNS management takes place.
• CAA: States which certificate authorities may issue TLS certificates for a domain, when supported by the certificate authority and DNS setup.

For a deeper domain-to-hosting workflow, see DNS Records Explained: A Practical Guide to Connecting a Domain to Hosting. If you are comparing the infrastructure behind the destination, the guide to shared hosting versus VPS hosting provides useful context.

Checklist by scenario

Connecting a new domain to web hosting

1. Confirm the hosting account is active and identify the provider's required A, AAAA, CNAME, or nameserver values.
2. Confirm where authoritative DNS is managed before editing records.
3. Choose either nameserver delegation or individual record changes according to the host's instructions. Avoid mixing approaches without understanding which system is authoritative.
4. Point the root domain, commonly represented by @, to the correct web destination.
5. Point www to the intended destination, usually with a CNAME or a separate A record.
6. Add the domain to the hosting control panel so the server knows which site should answer for it.
7. Confirm the preferred version, such as the root domain or www, redirects consistently to the other version.
8. Wait for caches to update, then test both HTTP and HTTPS in a browser and with DNS lookup tools.
9. Issue or activate the SSL certificate after the domain resolves to the correct hosting account. Certificate setup can fail when DNS still points elsewhere.

Adding or changing email hosting

1. Obtain the mail provider's complete MX record list and priority values.
2. Remove obsolete MX records only after confirming that the new service is ready. A mix of old and new records can send messages to the wrong system.
3. Publish the provider's TXT records for SPF or other verification requirements. Avoid creating multiple SPF records at the same hostname; combine authorized senders into one policy when appropriate.
4. Publish DKIM records exactly as supplied, including the selector and any required punctuation.
5. Configure DMARC deliberately, beginning with a monitoring-oriented policy if you need to observe legitimate senders before enforcing stricter handling. See SPF, DKIM, and DMARC Explained for Domain Owners.
6. Send and receive test messages from more than one mailbox, and check authentication results in the receiving service.

Using a third-party service or verification tool

Many services ask you to add a TXT, CNAME, or occasionally an A record to prove domain ownership or route a subdomain. Copy the host field carefully. A provider may show a fully qualified name while your DNS panel automatically appends the domain, producing a duplicated name if you paste it unchanged. Use the provider's documentation for the expected format, then verify the record publicly before completing setup.

Migrating a website or DNS provider

Lowering the TTL shortly before a migration may help some resolvers refresh sooner, but it cannot force every cached result to update immediately. Record the current zone before making changes, recreate all required website, email, verification, and security records, and test the new server using a temporary hostname or hosts-file method where practical. The website migration checklist covers the wider move, including redirects and validation.

What to double-check

• Nameservers: Query the domain's delegation and confirm it matches the DNS provider where you are editing records.
• Root and subdomain names: Check whether the panel expects @, a blank field, or the full domain name.
• Duplicate destinations: Review all A, AAAA, CNAME, and MX records for conflicting or retired services.
• IPv6: An incorrect AAAA record can make some visitors reach the wrong server even when the A record is correct.
• Trailing dots and formatting: Some panels require a fully qualified hostname with a trailing dot, while others add it automatically. Follow the panel's convention.
• TTL: Treat TTL as a caching instruction, not a guarantee that propagation will finish at a specific time.
• SSL coverage: Confirm the certificate covers every hostname visitors use, including the root domain and www where relevant.
• CAA restrictions: If a CAA record exists, make sure it permits the certificate authority being used. An overly restrictive record can prevent certificate issuance.
• Application configuration: DNS may resolve correctly while the hosting account, virtual host, WordPress URL, firewall, or redirect configuration still points to the old environment.

Use more than one resolver or lookup location when troubleshooting DNS propagation. A local result can reflect a cached answer, while an authoritative lookup shows what the DNS provider is currently publishing. Test the exact hostname and record type involved rather than checking only the domain's homepage.

Common mistakes

Editing the wrong DNS zone is the most frequent problem. A record can look correct in one dashboard and still have no effect if the domain delegates to different nameservers.

Replacing all records with a host's defaults can unintentionally break email, verification tokens, analytics, or security services. Export or document the existing zone before a migration and change only what is necessary.

Using a CNAME where an A record is required can fail at the root domain. Conversely, hard-coding an IP address for a service that supplies a hostname may create unnecessary maintenance when the service changes its destination.

Leaving old MX records in place can divide mail delivery between providers. Confirm the intended mail flow before removing records, especially when several teams or applications send email for the domain.

Assuming propagation is the same as a browser refresh leads to repeated edits. Cache duration varies by resolver and by record history. Make one controlled change, record the time, and verify from authoritative and public resolvers before changing it again.

When to revisit

Revisit your DNS records before a hosting migration, domain transfer, email-provider change, website relaunch, or new third-party integration. Review them before seasonal planning cycles when traffic, campaigns, or staffing changes may introduce new services. A quarterly or twice-yearly inventory is also useful for business domains, even when no immediate change is planned.

During each review, compare the live zone with an approved record inventory. Remove retired verification tokens and obsolete service records only after confirming they are no longer needed. Check that website and email destinations still match the current architecture, that SSL issuance is not blocked by CAA policy, and that administrative access to the registrar and DNS provider is documented securely.

When workflows or tools change, update the checklist itself. Record who approved the change, what was modified, the previous value, the new value, and how the result was tested. For teams deploying through Git or automation, connect DNS changes to the same review process used for application releases; the guide to deploying a website with Git can help structure that workflow.

Final action checklist: identify the authoritative nameservers, back up the current zone, confirm the provider's exact values, change only the required records, verify DNS from more than one location, test the website and email, and document the final configuration. This approach makes DNS management safer, easier to audit, and faster to troubleshoot the next time a domain or hosting workflow changes.