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

Overview

If you have ever bought a domain name, set up web hosting, or tried to connect email to a custom domain, you have interacted with DNS whether you meant to or not. DNS, or the Domain Name System, translates human-readable domain names into the technical destinations that browsers, mail servers, and other services need.

The confusion usually starts because DNS records all live in the same zone file or dashboard, but they solve different problems. An A record points a name to an IPv4 address. An AAAA record does the same for IPv6. A CNAME record aliases one hostname to another. MX records tell the world which mail servers should receive email for your domain. TXT records carry text-based instructions or proof, often for email authentication and service verification. NS records define which nameservers are authoritative for the domain or a delegated subdomain.

If you remember one rule, make it this: choose the record type based on the job you need done, not on what a provider's setup screen happens to highlight first.

Here is the short version:

• A: use when a hostname should resolve directly to an IPv4 address.
• AAAA: use when a hostname should resolve directly to an IPv6 address.
• CNAME: use when one hostname should follow another hostname.
• MX: use when setting where inbound email is delivered.
• TXT: use for verification, SPF, DKIM, DMARC, and other text-based DNS policies.
• NS: use to define authoritative nameservers or delegate a subdomain.

TTL, or time to live, matters too. TTL controls how long resolvers may cache a record before checking again. A lower TTL can help before a migration or planned change. A higher TTL can reduce query traffic once your setup is stable. DNS changes are often described as taking time to propagate, but in practice the delay is usually a mix of TTL settings, cached responses, and provider update timing.

For broader context on connecting a domain to a hosting account, see Connect Your Domain to Web Hosting: DNS Records Explained for Real Setups.

A record

An A record maps a hostname to an IPv4 address. This is one of the most common DNS records and often the right choice when your hosting provider gives you a fixed server IP.

Use it for: root domains like example.com, subdomains like app.example.com, and simple direct routing to a server.

Example: point example.com to 203.0.113.10.

AAAA record

An AAAA record maps a hostname to an IPv6 address. It serves the same role as an A record but for IPv6 networking.

Use it for: environments where your host or infrastructure supports IPv6 and you want direct IPv6 resolution.

Example: point example.com to 2001:db8::10.

CNAME record

A CNAME record makes one hostname an alias of another hostname. Instead of pointing directly to an IP address, it says in effect, “this name should resolve wherever that other name resolves.”

Use it for: subdomains such as www, docs, shop, or app when a provider gives you a target hostname rather than a fixed IP.

Example: point www.example.com to hosting.provider.net.

One important limitation: you generally should not use a CNAME at the zone apex, meaning the bare root domain like example.com, unless your DNS provider explicitly supports an apex alias feature under a different implementation name.

MX record

MX records specify which mail servers accept inbound email for your domain. They do not send email themselves; instead, they tell other mail systems where to deliver mail addressed to you.

Use it for: business email, hosted email suites, and any domain that should receive mail.

Example: route mail for example.com to mail1.provider.net and mail2.provider.net with different priorities.

TXT record

TXT records store text values. They are flexible and widely used for ownership verification, anti-spam policies, and service configuration.

Use it for: SPF policies, DKIM public keys, DMARC policies, search console verification, SaaS verification, and other provider-specific instructions.

Example: publish an SPF statement or add a verification token provided by an email or analytics platform.

NS record

NS records specify which nameservers are authoritative. At the domain level, they usually come from your registrar or DNS hosting provider. Within a zone, NS records can also delegate a subdomain to another DNS provider.

Use it for: changing DNS providers or splitting control of a subdomain such as dev.example.com to a separate team or platform.

Example: delegate blog.example.com to a managed blogging platform's nameservers.

Checklist by scenario

Use this section as a reusable pre-flight checklist. Start with the outcome you want, then confirm the record type, hostname, and destination before saving anything.

1. Point a website to a hosting server

• If your host gives you an IP address, use an A record for IPv4 and AAAA if they also support IPv6.
• If your host gives you a target hostname, use a CNAME for the relevant subdomain.
• For the root domain, confirm whether your DNS provider supports an apex alias feature if you need hostname-based routing there.
• Decide whether www should be the primary hostname or redirect to the root domain.
• Lower TTL ahead of a migration if you want faster changeover.

This is a common step when you launch a website or switch domain and hosting providers. If you are still choosing infrastructure, compare tradeoffs in Shared Hosting vs Cloud Hosting vs VPS: Which Option Fits Your Website in 2026?.

2. Connect a subdomain to a platform

• Use a CNAME when the platform provides a hostname target.
• Use an A record only if the provider explicitly tells you to point to a fixed IP.
• Check whether the platform also requires a TXT record for verification.
• Confirm SSL provisioning requirements, since some platforms issue certificates only after DNS resolves correctly.

3. Set up business email on your domain

• Add the provider's MX records exactly as specified, including priority values.
• Add required TXT records for SPF and any domain verification.
• Add DKIM TXT or CNAME records if your email provider uses them.
• Add a DMARC TXT record to define your policy and reporting preferences.
• Remove conflicting old MX records if you are replacing a previous mail provider.

Email setups often fail not because MX is wrong, but because old SPF records, duplicate TXT entries, or leftover providers create conflicts.

4. Verify domain ownership for a service

• Most services use a TXT record with a token value.
• Some use a CNAME challenge instead; follow the provider's exact instruction.
• Publish the record on the correct hostname. Many verification failures happen because the token is added at the root when the service expects a subdomain, or vice versa.
• Wait for DNS cache expiry before retrying verification.

5. Migrate a website with minimal disruption

• Reduce TTL well before the move if your current provider allows it.
• Build and test the new hosting environment first.
• Update the necessary A, AAAA, or apex alias record only when ready.
• Keep the old environment available during the transition window.
• Verify SSL, redirects, and application behavior after the DNS cutover.

If the move also involves your registrar, use a separate operational checklist like Domain Transfer Checklist: How to Move Your Domain Without Downtime.

6. Delegate a subdomain to another team or service

• Use NS records on the parent zone to delegate the subdomain.
• Confirm the child zone exists and is fully configured at the destination provider first.
• Document ownership clearly, especially in teams managing multiple staging and production environments.
• Test directly against the delegated nameservers if troubleshooting becomes necessary.

7. Prepare a new domain before launch

• Set the website routing with A, AAAA, or CNAME.
• Set up MX and email authentication records if the domain will send or receive mail.
• Add verification TXT records for analytics, search tools, or SaaS platforms.
• Confirm nameserver settings are final so you are not editing the wrong DNS zone.
• Check that SSL issuance succeeds once records resolve publicly.

If you are still at the beginning of the process, see How to Register a Domain Name: Step-by-Step Checklist for First-Time Buyers and Best Domain Registrars Compared: Pricing, Renewal Rates, Privacy, and DNS Features.

What to double-check

Before you save a DNS change—or before you assume a change failed—run through these checks. They prevent most avoidable mistakes.

• Are you editing the authoritative DNS provider? If your domain uses external nameservers, changes made at the registrar's default DNS panel may have no effect.
• Did you enter the correct hostname? Root, @, blank host field, and fully qualified names are handled differently across dashboards.
• Is the record type correct? A provider may support multiple methods, but they are not interchangeable.
• Is there a conflicting record? A hostname usually cannot have a CNAME alongside other records of the same name.
• Did you copy the target exactly? Extra spaces, missing dots, and partial hostnames can break resolution.
• Is TTL appropriate? A long TTL may make a recent change seem delayed. A short TTL is often useful before planned maintenance.
• Are old records still present? Legacy MX, SPF, or stale verification records can cause hard-to-trace behavior.
• Does the destination service expect additional setup? Many services need both DNS and an in-app confirmation step.
• Does SSL depend on DNS being correct first? A valid certificate often cannot be issued until the hostname resolves publicly.

For hosted applications such as WordPress, DNS is only one layer of the launch process. Hosting choice, SSL handling, backups, and caching all affect reliability and performance. Related reading: Best Hosting for WordPress Sites: Speed, Support, Backups, and Scalability Compared.

Common mistakes

These are the recurring errors behind many support tickets and launch delays.

Using a CNAME where an A record is required

If your provider gives you a server IP, use an A record. If they give you a hostname target, use a CNAME for the subdomain. Treating these as interchangeable can break routing or create unexpected dependencies.

Putting a CNAME at the root domain without confirming support

The zone apex has special rules. Many DNS systems do not allow a normal CNAME there because the root domain also needs other records such as NS and often SOA. If you need root-domain alias behavior, use a provider-supported apex alias feature.

Leaving old MX or SPF records in place

Email migrations often stumble because old records remain active. Multiple SPF records are a common problem; mail providers generally expect a single effective SPF policy, not several separate ones.

Editing DNS in the wrong account

A domain registrar, DNS hosting provider, CDN, and web host may all present DNS-related settings. Only the authoritative zone matters for public resolution. Verify nameservers first.

Confusing website DNS with email DNS

Pointing your website to a new host does not automatically move email. Website traffic and mail delivery often use separate records and separate providers.

Ignoring TTL before a migration

If you wait until the moment of cutover to lower TTL, the earlier longer cache may still govern many resolvers. Plan ahead when timing matters.

Assuming DNS alone completes a launch

Correct DNS does not guarantee the application is ready. You still need to verify SSL, redirects, origin health, firewall rules, and expected content at the destination.

Not documenting record purpose

Months later, a random TXT token or delegated subdomain can look safe to delete when it is not. If your DNS platform allows comments or labels, use them.

When to revisit

DNS should be revisited whenever the underlying service behind a hostname changes. This is what makes a record reference worth bookmarking: the exact values may change, but the decision framework stays the same.

Recheck your DNS records in these situations:

• Before a website migration: confirm current records, TTL, and cutover plan.
• When changing web hosting or cloud hosting: new providers may require different record targets.
• When adding or replacing email hosting: update MX, SPF, DKIM, and DMARC together.
• When launching a new subdomain: decide whether to use A, AAAA, CNAME, or NS delegation.
• When a service asks for verification: add TXT or CNAME records exactly as instructed.
• During annual infrastructure reviews: remove unused records, stale verification tokens, and abandoned delegations.
• Before seasonal planning cycles: lower TTL and review dependencies if you expect launches, campaigns, or platform changes.
• When workflows or tools change: DNS needs often shift when teams adopt a new CDN, email platform, CI preview environment, or security layer.

To make DNS maintenance practical, keep a lightweight operating checklist:

1. List every active hostname and what it is for.
2. Record which provider is authoritative for DNS.
3. Note which records support web, email, verification, and delegated subdomains.
4. Review TTL settings before any planned change.
5. Test resolution and application behavior after updates.
6. Remove obsolete records after the transition is complete.

DNS is easy to overlook because it sits between systems rather than inside one of them. But that is exactly why a clear checklist matters. When you know what each record type does and when to use it, launching a site, connecting a domain to hosting, or setting up email becomes far more predictable.

If you are evaluating the broader cost and setup side of a new launch, you may also want to review Web Hosting Pricing Guide: Intro Rates, Renewal Costs, and Hidden Fees to Watch.