DNS Records Explained: A Practical Guide to A, CNAME, MX, TXT, and AAAA Records

Overview

The Domain Name System, or DNS, translates human-readable names such as example.com into destinations that computers can use. Your domain registrar, DNS provider, and web host may be different companies, so the first step in any DNS change is identifying where the domain's authoritative DNS records are managed.

DNS records are usually made up of a name, a record type, a value, and a time to live (TTL). The name identifies the hostname being configured. The type describes what the record does. The value points to an IP address, another hostname, a mail server, or a text-based instruction. TTL tells resolvers how long they may cache the result before checking again.

Common records serve different purposes:

• A record: Points a hostname to an IPv4 address. For example, example.com may point to 192.0.2.10.
• AAAA record: Points a hostname to an IPv6 address. It uses an IPv6 value such as 2001:db8::10.
• CNAME record: Aliases one hostname to another hostname, such as www.example.com pointing to app.host.example. It does not point directly to an IP address.
• MX record: Specifies which mail servers receive email for a domain. MX records include a priority value; lower numbers generally indicate higher preference.
• TXT record: Stores text instructions used for services such as domain verification, email authentication, and other configuration checks.

DNS changes do not always appear everywhere immediately because resolvers cache records. A change may be visible from one network while another still returns the previous value. For broader context, compare this guide with the DNS configuration guide for reliable websites.

Checklist by scenario

Connecting a website

1. Confirm the hosting provider's required hostname or IP address from its setup instructions.
2. Decide whether the root domain, such as example.com, will use an A record, an ALIAS or ANAME-style feature, or another method supported by your DNS provider.
3. Set the www hostname separately, commonly with a CNAME pointing to the host's supplied hostname.
4. Remove or replace old records only after confirming they are no longer needed. A legacy record may still support a subdomain, verification service, or application.
5. Check that the hosting platform recognizes both the root domain and the www version if both should work.

A CNAME cannot normally share the same hostname with other record types. For example, do not create an A record and a CNAME for www at the same time. Follow the DNS provider's interface carefully because it may automatically append the domain name to a value.

Adding IPv6 support

1. Confirm that the server or hosting platform is actually configured to accept IPv6 traffic.
2. Add an AAAA record using the exact IPv6 address supplied by the provider.
3. Keep the A record if IPv4 visitors still need access.
4. Test the site over both address families rather than assuming that an AAAA record alone confirms a working IPv6 setup.

An incorrect AAAA record can cause problems for visitors whose networks prefer IPv6. If IPv6 is not configured end to end, do not add an address simply because the DNS panel offers the record type.

Setting up email

1. Copy every required MX record from the email provider, including the exact destination and priority.
2. Remove obsolete MX records only when you are certain the old mail service is no longer in use.
3. Publish the provider's TXT records for domain verification and email authentication as instructed.
4. Check whether the provider requires a separate hostname, such as mail, for an MX destination.
5. Send test messages in both directions and inspect delivery results before treating the migration as complete.

MX records control where incoming mail is delivered; they do not configure every aspect of sending mail. TXT records may be used for SPF, DKIM-related configuration, or DMARC policy, but the exact values depend on the mail provider and should be copied precisely.

Verifying a service or subdomain

1. Use the exact record type and hostname requested by the service.
2. Preserve punctuation, quotation marks where required, and long TXT values without unintended spaces or line breaks.
3. Check whether the provider expects the full domain name or only the host label.
4. Leave the verification record in place if the service says it is needed for ongoing validation.

What to double-check

Before saving a DNS change, use this short review:

• Authoritative provider: Confirm that you are editing the DNS service named by the domain's nameservers. Changing records in the registrar panel will have no effect if another provider is authoritative.
• Hostname format: Some interfaces expect www; others expect www.example.com. Read the field labels and help text.
• Trailing dots: DNS tools may display fully qualified hostnames with a trailing dot. Do not add or remove one blindly when copying values.
• Record conflicts: Look for duplicate A, AAAA, MX, or CNAME records that send traffic to different destinations.
• TTL: Treat TTL as a caching instruction, not a guarantee of exact propagation time. Lowering it before a planned migration can help, but cached results may remain elsewhere.
• Security: Restrict access to the DNS account, use strong unique credentials, and enable available multi-factor authentication. DNS access can affect websites, email, and verification systems.
• Documentation: Record the original value, the reason for the change, the person or system that requested it, and the date.

For troubleshooting, query the domain from more than one network or use an independent DNS lookup tool. Compare the answer returned by the authoritative nameserver with answers from recursive resolvers. This distinction helps identify whether the record is wrong at the source or simply still cached elsewhere. The online DNS tools guide provides a useful companion checklist.

Common mistakes

• Editing the wrong DNS zone: A domain may have separate records for the root domain and subdomains, and the active nameservers may not be managed by the registrar.
• Using a CNAME at the root without checking support: DNS providers handle root-domain aliasing differently. Use the method supported by the authoritative provider and hosting platform.
• Leaving old mail records active: Multiple MX destinations can distribute or misroute messages when they were not intentionally configured together.
• Creating duplicate SPF TXT records: Email services may require one combined SPF policy rather than several separate SPF records. Follow the provider's current instructions.
• Copying a value with an extra domain suffix: A panel that automatically appends example.com can turn an intended hostname into an incorrect nested name.
• Changing several systems at once: Make one related change at a time where possible, then test before proceeding. This makes rollback and diagnosis easier.
• Assuming propagation is the only problem: If the authoritative answer is already wrong, waiting will not fix the configuration.

When to revisit

Review DNS records before moving web hosts, changing email providers, launching a new subdomain, enabling IPv6, renewing a security or verification workflow, or changing the domain's nameservers. Recheck them before seasonal planning cycles when traffic, campaigns, or support requirements may change. A hosting migration is a particularly useful point to inventory records; use the website hosting migration checklist to coordinate DNS changes with testing and rollback planning.

Also revisit the zone after an incident, an unexpected email delivery problem, a certificate or verification failure, or a change in the people and systems with DNS access. Remove records that are no longer needed, but preserve evidence of what was removed in your change log.

As a final action, create a current DNS inventory containing each hostname, record type, destination, purpose, owner, and last review date. Store it securely, compare it with the live authoritative zone, and update it whenever infrastructure changes. This small habit turns DNS management from a reactive troubleshooting task into a repeatable reliability check.