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

Overview

The Domain Name System (DNS) translates human-readable names such as example.com into information that browsers, mail servers, and other internet services can use. Your domain registrar, hosting provider, or dedicated DNS provider may manage these records through a DNS control panel.

DNS is separate from your website hosting account. You can register a domain with one company, host a website with another, and use a third provider for email or DNS management. The key is knowing where the authoritative nameservers point and making changes in the correct control panel.

Before editing records, make a simple inventory:

• Domain and subdomains currently in use, such as www, shop, or staging.
• Website hosting destination, including the required IPv4 address, IPv6 address, or target hostname.
• Email provider and the exact MX records it requires.
• Verification records requested by analytics, search, payment, or SaaS platforms.
• Current nameservers, TTL values, and any records that must remain unchanged.

If you are connecting a new website to a hosting account, first confirm whether the provider expects an A record, an IPv6 AAAA record, a CNAME, or a nameserver change. The safest setup depends on the provider's instructions and whether other services already use the domain. For a broader workflow, see how to point a domain to hosting.

Checklist by scenario

1. Point a root domain to a website

The root domain is written as example.com, although some DNS panels display it as @ or leave the name field blank. If your host gives you an IPv4 address, create an A record:

• Type: A
• Name or host: @
• Value: the hosting provider's IPv4 address
• TTL: the provider's recommendation, or a moderate default during normal operation

If the host supplies an IPv6 address, add an AAAA record using the same host name. Do not put an IPv6 address in an A record. If the provider gives you a hostname instead of an IP address, check whether it requires a CNAME or a nameserver connection. A CNAME at the root may not be supported by every DNS provider.

2. Connect the www subdomain

A common arrangement sends www.example.com to the root domain:

• Type: CNAME
• Name or host: www
• Value: example.com or the hostname specified by your host

Alternatively, your hosting provider may ask for an A record for www. Follow the provider's exact instructions and avoid creating both a CNAME and an A record with the same name. After the record is active, configure the preferred version of the site in the hosting or CMS settings and test both the root and www addresses.

3. Set up email with MX records

MX records tell sending mail servers where to deliver messages for your domain. An MX record normally includes a mail hostname and a priority value. Lower numeric priority generally means preference over a higher numeric value when multiple records are present.

Use the exact MX hostnames and priorities supplied by your email provider:

• Type: MX
• Name or host: @, unless the provider specifies another name
• Value: the provider's mail server hostname
• Priority: the provider's stated number

Remove old MX records only after confirming that the domain no longer relies on the previous email service. Incorrectly deleting existing records can interrupt mail delivery. Email providers may also request TXT records for SPF, DKIM, or domain verification; those are separate from MX records and should be added exactly as documented.

4. Add a TXT record for verification or email policy

TXT records store text associated with a domain. Services commonly use them to verify ownership or publish email-related information. A typical verification task looks like this:

• Type: TXT
• Name or host: the label specified by the service, such as @ or a unique token label
• Value: the complete string supplied by the service

Copy the value precisely, including punctuation, underscores, and capitalization where relevant. Do not replace an existing TXT record simply because the names match; many domains have multiple TXT records for different services. Your DNS provider may automatically add quotation marks or split long values. That can be normal, but verify the resulting value with a DNS lookup tool.

5. Use a CNAME for a hosted service or subdomain

CNAME records create an alias from one hostname to another hostname. They are useful for services such as a hosted documentation site, landing page, application, or CDN endpoint:

• Type: CNAME
• Name or host: the subdomain, such as docs
• Value: the service's target hostname, such as customer.example-service.com

A CNAME points to a hostname, not an IP address. It is not the right record type for a numeric IPv4 or IPv6 address. Also check whether the service requires you to add a separate TXT record before it will issue an SSL certificate or activate the custom hostname.

6. Add DNS records for a CDN

A CDN may ask you to route a subdomain, the root domain, or both through its network. A typical subdomain configuration uses a CNAME such as assets.example.com pointing to the CDN's assigned hostname. Some CDN configurations use provider-specific records or require nameserver delegation.

Before changing production traffic, record the current website destination and confirm that the CDN has the correct origin hostname, SSL settings, and caching behavior. If the change is part of a larger migration, use the low-downtime website migration checklist to organize testing and rollback steps.

What to double-check

Nameservers and the correct DNS zone

Changes only work when made in the authoritative DNS zone. If your domain's nameservers point to your hosting provider, editing records at the registrar may have no effect. Check the nameserver values first, then open the matching DNS control panel.

Record conflicts

Look for duplicate or conflicting records with the same name. A hostname should not normally have a CNAME alongside A, AAAA, or another CNAME record. Multiple MX and TXT records can be valid, but they should have distinct purposes and match the provider's instructions.

TTL and propagation

TTL, or time to live, tells recursive DNS resolvers how long they may cache a response. A shorter TTL can make planned changes easier to revise, while a longer TTL can reduce repeated DNS queries during stable operation. TTL does not force every resolver to update immediately. Cached responses may remain visible until their previous TTL expires, and different resolvers may refresh at different times.

For a planned migration, lower the relevant TTL in advance if your DNS provider allows it, prepare the new destination, make the change during a monitored window, and keep the old service available until traffic is consistently reaching the new one. Avoid repeatedly changing records while waiting; capture the time of each change instead.

SSL and application configuration

DNS does not issue or install an SSL certificate by itself. After pointing a domain to a new host, confirm that the hosting platform has the domain attached, the certificate covers the root and required subdomains, and the CMS uses the intended HTTPS URL. Test redirects, login pages, forms, APIs, and asset URLs.

Verification from more than one location

Use DNS lookup tools or command-line utilities such as dig and nslookup to inspect A, AAAA, CNAME, MX, and TXT responses. Compare results from more than one resolver when diagnosing propagation. Then test the actual website or email workflow, because a correct DNS response does not guarantee that the host, CMS, firewall, or mail service is configured correctly.

Common mistakes

• Editing the wrong provider: Confirm authoritative nameservers before changing records.
• Adding the domain twice: A DNS panel may automatically append the domain name. Check whether the name field expects www or the full hostname.
• Using an IP in a CNAME: Use A for IPv4, AAAA for IPv6, and CNAME for another hostname.
• Deleting email records during a website change: Website DNS and email DNS can coexist. Change only the records required for the website.
• Ignoring an existing AAAA record: Some visitors may use IPv6. If the AAAA destination is incorrect, IPv6 users can experience failures even when the A record works.
• Expecting instant propagation: Check TTLs, resolver results, and the time of the change before assuming the setup failed.
• Forgetting the hosting control panel: DNS may point correctly while the host has not added the domain, configured the document root, or enabled HTTPS.
• Changing nameservers without exporting the zone: Before delegation, document website, email, verification, and subdomain records so they can be recreated safely.

For ongoing reliability, pair DNS checks with a broader website uptime and performance monitoring checklist. Monitoring can help distinguish a DNS issue from an application, server, or network problem.

When to revisit

Revisit your DNS record inventory before seasonal planning cycles, major campaigns, domain renewals, hosting changes, and email-provider changes. It is also worth reviewing records when a CMS is moved, a CDN is introduced, a staging environment becomes permanent, or a security and verification service is added.

Use this repeatable review:

1. Export or document the current DNS zone, including nameservers and TTLs.
2. Mark each record as website, email, verification, CDN, staging, or unknown.
3. Remove records that are confirmed to be obsolete, but retain a dated backup first.
4. Confirm that A, AAAA, CNAME, MX, and TXT records match active services.
5. Test the root domain, key subdomains, HTTPS, email sending and receiving, and verification workflows.
6. Record what changed, when it changed, and who should approve a rollback.

DNS is easiest to manage when treated as infrastructure documentation rather than a one-time setup task. Keep the inventory with your website or deployment notes, review it whenever workflows or tools change, and make one deliberate change at a time. If a website move is also changing the server environment, compare the operational differences in cloud hosting versus VPS hosting before finalizing the target configuration.