DNS Records Explained: A, AAAA, CNAME, MX, TXT, and NS Records Reference Guide

Overview

When someone visits example.com or sends mail to user@example.com, DNS helps systems find the correct destination. A DNS zone is a collection of records managed by the authoritative DNS provider for a domain. Your registrar may provide DNS hosting, or the domain may use nameservers operated by a separate hosting, cloud, CDN, or email provider.

The record type determines how a query should be interpreted:

DNS interfaces use different labels. A provider may call the name field Host, Name, or Record. The symbol @ commonly means the root domain, but some interfaces require the full domain or a blank field. If the interface automatically appends your domain, entering www.example.com could unintentionally create www.example.com.example.com. Check the provider’s field instructions before saving.

For a broader launch sequence, see How to Connect a Domain to Web Hosting. It covers the relationship between DNS records, nameservers, hosting, and verification.

Checklist by scenario

Website at the root domain

• Confirm whether the host supplies an IPv4 address, an IPv6 address, a hostname, or a combination.
• Add an A record for the root domain if the host gives you an IPv4 address.
• Add an AAAA record only when the host has provided a working IPv6 address.
• If the platform gives you a hostname instead of an address, follow its instructions. A CNAME is commonly suitable for a subdomain, while the root domain may require provider-specific support.
• Keep unrelated records, especially email records, unless the hosting provider explicitly requires their removal.

www or another subdomain

• Create a CNAME such as www pointing to the hostname supplied by the hosting or CDN provider.
• For blog.example.com, use blog as the host if the DNS interface appends example.com automatically.
• Do not add an A record and CNAME for the same hostname unless the provider documents a special implementation.
• Decide which version is canonical, such as the root domain or www, and configure a redirect for the other version at the web server or platform level.

Business email

• Collect every MX record from the email provider, including its priority or preference value.
• Enter each mail target as a hostname exactly as supplied. Avoid adding a trailing dot unless the DNS interface specifically expects one.
• Publish the provider’s SPF, DKIM, and DMARC records as instructed. These are commonly TXT records, although DKIM may use a selector-specific hostname.
• Check whether an existing SPF TXT record is already present. SPF should be managed as one policy for a domain rather than by blindly adding competing SPF policies.
• Test sending and receiving after the records are visible. DNS changes alone do not configure mailboxes, aliases, forwarding, or authentication inside the email service.

Third-party verification

• Identify whether the service requests a TXT record, a CNAME, or another record type.
• Use the exact host or selector supplied by the service. A verification token placed at @ is not equivalent to one placed at _verify.
• Preserve existing records unless the instructions specifically say to replace one.
• After saving, use the service’s verification control or query the record from an independent DNS resolver.

CDN, security, or traffic routing

• Read the provider’s cutover instructions before changing A, AAAA, or CNAME records.
• Confirm that the origin server is ready and that the provider has issued any required SSL or domain validation record.
• Document the old values so you have a rollback path.
• After the change, test HTTP and HTTPS, the root domain and key subdomains, redirects, forms, and any API endpoints.

What to double-check

Authority: First determine which nameservers are authoritative. Editing DNS at a registrar has no effect if the domain uses nameservers at a different provider. An NS change is broader than adding a single record because it moves responsibility for the zone.

Record scope: A record for example.com does not automatically apply to www.example.com, mail.example.com, or other subdomains. Review each hostname separately.

Formatting: A records require IP addresses; CNAME and MX targets require hostnames; TXT values must preserve punctuation, spaces, underscores, and capitalization where the provider requires them. Do not paste https:// into a DNS value.

Conflicts: Look for duplicate A, AAAA, MX, or TXT records. Multiple records can be intentional, but an unexpected old address can send traffic to the wrong service. A CNAME generally cannot coexist with other data at the same name.

TTL: TTL controls how long resolvers may cache a response. A shorter TTL can make planned changes easier to adjust, while a longer TTL can reduce repeated lookups. Lowering TTL shortly before a change does not instantly clear caches that already stored the previous value. Plan the change window around the existing TTL and allow for resolver behavior.

SSL readiness: DNS points traffic toward a service; it does not by itself issue or install an SSL certificate. After routing a hostname, confirm that the hosting or CDN platform has provisioned HTTPS and that the certificate covers every required hostname. For troubleshooting, use SSL Certificate Errors Explained.

Backups and rollback: Export or record the current zone before making important changes. During a migration, keep the old hosting environment available until the new site, email, certificates, and monitoring have been tested. The website migration checklist provides a fuller workflow.

Common mistakes

• Using a URL in an A or CNAME value: DNS values do not normally include a protocol such as https:// or a page path.
• Entering the domain twice: Check whether the control panel appends the zone automatically.
• Replacing all MX records with a web host’s records: Website hosting and email hosting can be separate. Change MX records only when you intend to move mail delivery.
• Adding several SPF records: Review the existing policy and merge authorized senders according to the email provider’s instructions.
• Publishing an AAAA record without working IPv6: Some visitors may attempt IPv6 first and reach an unavailable service.
• Expecting an immediate global update: Cached answers can persist according to TTL, and different resolvers may show different results during a transition. Use a DNS propagation checker as an observation tool, not as proof that every network has updated.
• Editing the wrong DNS zone: Confirm the domain, authoritative nameservers, and exact hostname before saving.
• Changing nameservers without copying records: A new provider may start with an empty or incomplete zone, interrupting websites, email, validation, or other services.

For a full audit covering ownership, renewals, DNS, and account security, use the domain portfolio management checklist.

When to revisit

Return to this reference before launching a website, moving hosting, adding business email, connecting a CDN, renewing a security service, or verifying a new SaaS platform. Review DNS after a team member changes providers, after a domain transfer, and whenever a service’s setup instructions change.

As a recurring maintenance task, keep an inventory of each domain’s authoritative nameservers, important records, purpose, owner, and last review date. Before seasonal campaigns or planned infrastructure work, check that A and AAAA records still point to active systems, MX records still match the mail provider, TXT records are still required, and SSL certificates cover the names visitors use.

When troubleshooting, record the time of the change, the previous value, the new value, and the resolver or tool used for testing. If the result is unexpected, compare answers from multiple resolvers, inspect the authoritative nameserver directly, and verify the application separately from DNS. For propagation-specific symptoms, see DNS Propagation Problems: A Troubleshooting Guide.

Action checklist: identify the authoritative DNS provider, document the current zone, define the exact hostname and record type, copy the provider’s value precisely, select a sensible TTL, save one change at a time, test from more than one network, and keep a rollback note. This process turns DNS changes from guesswork into a controlled part of website and email operations.