DNS Records Guide: A, AAAA, CNAME, MX, TXT, NS, and When to Use Each

Overview

DNS records tell the internet where your website, email, and domain-related services live. If your domain name is the label people type into a browser, DNS is the directory that translates that label into the correct destination.

Most domain owners only need to work with a small group of records:

• A record: points a name to an IPv4 address.
• AAAA record: points a name to an IPv6 address.
• CNAME record: points one hostname to another hostname.
• MX record: tells email where to go.
• TXT record: stores text-based instructions, usually for verification and email security.
• NS record: defines which nameservers are authoritative for the domain or a delegated subdomain.

Before changing anything, it helps to understand three basic DNS ideas:

1. Host or name: the part of the domain you are editing, such as @, www, mail, or blog.
2. Value or target: where that host should point, such as an IP address, another hostname, or a mail server.
3. TTL: time to live, which affects how long resolvers may cache the record before refreshing it.

A few quick conventions make DNS easier to read:

• @ usually means the root domain, also called the apex, such as example.com.
• www usually means www.example.com.
• A “hostname” is a domain-style name like app.hostingprovider.com.
• An “IP address” is a numeric address like 203.0.113.10 or an IPv6 equivalent.

The most common confusion is not technical complexity. It is simply choosing the right record type for the job. If you remember one rule, make it this: use A or AAAA when you have an IP address, use CNAME when you have another hostname, use MX for email delivery, use TXT for verification and email policy, and use NS when changing or delegating DNS authority.

If you are still at the stage of connecting a new domain to a website, this companion guide may help: How to Connect Your Domain to Web Hosting: DNS Records Explained Simply.

A record

An A record maps a hostname to an IPv4 address. This is one of the most common records in website setup.

Use it when:

• Your hosting provider gives you an IPv4 address.
• You want the root domain, such as example.com, to load your website.
• You need a subdomain like shop.example.com to point directly to a server IP.

Example: @ → 203.0.113.10

Do not use it when: your provider gives you a hostname target instead of an IP. In that case, CNAME may be the better fit.

AAAA record

An AAAA record does the same job as an A record, but for IPv6.

Use it when:

• Your host or server supports IPv6 and provides an IPv6 address.
• You want a hostname to resolve over IPv6.

Example: @ → 2001:db8::10

Practical note: only add an AAAA record if you are sure the destination is configured correctly for IPv6. A misconfigured AAAA record can create hard-to-diagnose access issues for some visitors.

CNAME record

A CNAME record aliases one hostname to another hostname. It does not point to an IP address.

Use it when:

• Your platform tells you to point www to a hostname like sites.provider.net.
• You want a subdomain such as blog.example.com to follow another hostname.
• You prefer a layer of indirection so a provider can change its underlying IPs without asking you to update DNS repeatedly.

Example: www → yoursite.hostplatform.com

Important limitation: a CNAME generally should not be used at the root domain if your DNS provider does not support root-level aliasing features. Some providers offer ALIAS, ANAME, or flattened CNAME-style behavior at the apex, but those are provider-specific features rather than standard DNS record types.

MX record

MX records define which mail servers receive email for your domain.

Use it when:

• You want to receive email at addresses like hello@example.com.
• You are moving business email hosting from one provider to another.

Example: @ → mail.provider.com with a priority value

Important detail: MX records point to hostnames, not raw email addresses. They often use multiple entries with different priorities.

TXT record

TXT records carry text values used for ownership verification, email authentication, and other service instructions.

Use it when:

• You need to verify a domain with a website builder, CDN, analytics platform, or business tool.
• You are setting up SPF, DKIM, or DMARC for email protection.
• A service asks you to paste a token into DNS.

Examples:

• Site verification token
• SPF policy indicating which systems can send mail on behalf of your domain
• DMARC policy describing how unauthenticated mail should be handled

Practical note: many TXT mistakes come from formatting problems, duplicate values, or placing the record on the wrong host.

NS record

NS records specify which nameservers are authoritative for a domain or subdomain.

Use it when:

• You are changing the domain to use a different DNS provider.
• You are delegating a subdomain to another system or team.

Example: the domain uses nameservers from your registrar, hosting company, or DNS platform.

Caution: nameserver changes affect the whole zone when applied at the domain level. They are not the same as adding a single website record. If you replace nameservers, you must make sure all required records exist on the new DNS provider before the change goes live.

Checklist by scenario

Use this section as a quick decision tool before you edit DNS.

1. You want your domain to load a website

• If your host gives you an IPv4 address, add an A record for @.
• If your host gives you an IPv6 address, add an AAAA record if you know IPv6 is configured correctly.
• If your host says point www to this hostname, add a CNAME for www.
• Decide whether example.com or www.example.com will be the preferred version and redirect the other.
• Confirm that SSL is provisioned after DNS resolves correctly.

If you are comparing hosting setups first, these may help: Best Web Hosting for Small Business Websites, Shared Hosting vs VPS vs Cloud Hosting, and Managed WordPress Hosting vs Shared Hosting.

2. You want to connect a subdomain

• Use an A record if the destination is an IP address.
• Use a CNAME if the destination is another hostname.
• Name the host carefully: blog, shop, members, and mail all create different subdomains.
• Check whether the destination platform expects you to verify ownership with a TXT record too.

3. You want to receive email on your domain

• Add the provider’s required MX records.
• Add any required TXT records for SPF, DKIM, and DMARC.
• Remove old MX records if you are fully switching providers and the new provider instructs you to do so.
• Double-check that you are editing the correct DNS zone and not a parked or duplicate domain.
• Test both receiving and sending after propagation.

4. A service asks you to verify your domain

• Most of the time, this means adding a TXT record.
• Copy the token exactly as provided.
• Place it on the exact host requested, often @ or a service-specific subdomain.
• Wait for propagation before clicking verify again.

5. You are moving DNS to a new provider

• Export or document every current record first.
• Recreate all critical records on the new provider: website, email, verification, redirects, and subdomains.
• Only then update the NS records at the registrar.
• Keep a rollback plan in case something is missing.

If the move is part of a registrar change, review How to Transfer a Domain Name Without Downtime and Best Domain Registrars Compared.

6. You are troubleshooting “site works without www” or “www works but root does not”

• Check whether the root domain has an A or AAAA record.
• Check whether www has a CNAME or equivalent record.
• Confirm your hosting platform supports both hostnames.
• Set a preferred canonical version and redirect the other one consistently.

7. You are launching a new domain from scratch

• Choose the domain and registrar first. If needed, review Domain Name Search Tips, Best TLDs for Small Business Websites, and Domain Registration Cost Guide.
• Point the website with A, AAAA, or CNAME as instructed.
• Set up email with MX and supporting TXT records if needed.
• Add verification TXT records for any external tools.
• Confirm SSL, redirects, and live page loading before you publish publicly.

What to double-check

Most DNS problems come from small errors rather than major misunderstandings. This is the pre-save checklist worth using every time.

• Are you editing the right DNS provider? If the domain uses external nameservers, changes made at the registrar may do nothing.
• Are you editing the right host? @, blank host, and full domain entry can behave differently depending on the control panel.
• Did you use the correct record type? If the destination is an IP, do not paste it into a CNAME.
• Did you copy the value exactly? Extra spaces, missing dots, or broken quotation marks can matter.
• Are there conflicting records? A hostname should not usually have both a CNAME and other record types attached to it.
• Did you leave old records in place? Old MX, TXT, or A records can create partial failures and inconsistent behavior.
• Is TTL reasonable? A shorter TTL can help before planned changes, but it will not force instant propagation everywhere.
• Is the destination ready? DNS can be correct while the server, app, or mail service itself is still not configured.
• Are you waiting long enough? DNS changes are often visible quickly in some places and slower in others.

One especially useful habit is to record every change you make: date, record type, host, old value, new value, and why you changed it. That single step makes rollback and troubleshooting much easier later.

Common mistakes

If DNS feels unpredictable, it is often because one of these mistakes is in play.

Using CNAME at the wrong place

The classic A record vs CNAME mistake is trying to use a standard CNAME at the root domain when the provider does not support it. If the website platform requires hostname pointing, check whether your DNS provider offers an apex alias feature or whether the platform provides an IP-based option for the root.

Pointing email with the wrong record type

Email delivery uses MX records. Adding an A record for mail does not by itself route incoming mail for the whole domain. If you are changing email providers, follow their MX and TXT instructions exactly.

Forgetting TXT records after email setup

MX records get mail delivered, but TXT records often help prove which systems are allowed to send on your behalf and how receiving servers should treat unauthenticated mail. Skipping them can lead to deliverability problems even when mailboxes appear to work.

Changing nameservers before copying the zone

When NS records change, the active DNS zone changes too. If the new provider does not already have your website, email, and verification records, things can break all at once.

Editing a stale or duplicate zone

This is common in migrations. You make the “right” record change, but in the wrong dashboard. Always verify where the authoritative DNS is hosted before editing.

Mixing temporary and permanent records

People sometimes leave old verification tokens, outdated subdomain records, test entries, or past mail settings in place. Over time, the zone becomes harder to trust. Keep records documented and remove what is no longer needed.

Assuming propagation is the only issue

Propagation is real, but it is not always the reason something fails. A record can resolve correctly while the web server returns an error, SSL is missing, or the application is not connected to that hostname.

When to revisit

DNS is not a one-time setup. It is a system you should revisit whenever your underlying tools or workflows change. Use this practical review list before making updates and during routine maintenance.

• Before launching a redesign or new hosting environment: confirm website records, redirects, and SSL behavior.
• Before switching email providers: document old MX and TXT values and schedule the cutover carefully.
• Before transferring a domain or changing nameservers: export the full zone and rebuild it elsewhere first.
• When adding a new platform: many site builders, newsletter tools, and CDNs require TXT or CNAME verification.
• When traffic patterns or site structure change: review subdomains, staging environments, and unused records.
• During seasonal planning cycles: audit DNS before major launches, campaigns, or product releases.
• When team ownership changes: make sure account access, documentation, and recovery methods are current.

A simple recurring DNS review can be done in fifteen minutes:

1. List all active website, email, and verification services tied to the domain.
2. Compare that list to your current DNS records.
3. Remove obviously unused records only if you are sure they are no longer needed.
4. Confirm the root domain, www, and key subdomains resolve as intended.
5. Test email send and receive if the domain is used for business communication.
6. Save a dated snapshot of the zone for future reference.

If you want a final rule of thumb to keep handy, use this one: A and AAAA send names to IP addresses, CNAME sends a name to another name, MX handles incoming mail, TXT handles verification and email policy, and NS decides who controls DNS.

That framework is enough for most practical DNS setup tasks. Keep this page bookmarked, and use it as your pre-change checklist anytime you connect domain and hosting, add business email hosting, verify a service, or clean up a legacy DNS setup.