DNS Record Types Explained: A, AAAA, CNAME, MX, TXT, NS, and SRV

Overview

At a practical level, DNS is a distributed lookup system. It tells browsers, mail servers, and applications where to go when someone uses a domain name. Different DNS record types answer different questions. Some point traffic to an IP address. Some delegate authority. Some describe email routing. Others carry verification or policy data.

The reason record choice matters is simple: DNS is not interchangeable. An A record and a CNAME may both seem to “point” a hostname somewhere, but they do it in different ways and come with different constraints. The same is true for MX and TXT records in email setups, or NS records when you move a domain to a managed DNS provider.

Here is the short version:

• A: points a hostname to an IPv4 address.
• AAAA: points a hostname to an IPv6 address.
• CNAME: aliases one hostname to another hostname.
• MX: tells the internet where mail for your domain should be delivered.
• TXT: stores text-based metadata, often for verification and email authentication.
• NS: identifies the authoritative name servers for a domain or subdomain.
• SRV: defines the hostname and port for specific services.

For most business websites and developer workflows, these records cover the majority of day-to-day DNS tasks. If you are connecting a domain to cloud hosting, configuring website hosting with SSL, setting up a domain and hosting package, or using a managed DNS platform, understanding these seven record types will prevent many common mistakes.

A useful way to think about DNS is this: each record answers one narrow routing question. Good DNS management means choosing the record type that matches the exact job, keeping the zone tidy, and revisiting settings when infrastructure changes. If you are making changes and want a deeper look at caching and timing, see DNS Propagation Explained: Typical Timelines and How to Check Status.

How to compare options

The easiest way to compare DNS record types is to ignore the acronyms at first and ask what problem you are solving. In practice, most DNS decisions come down to five questions.

1. Are you pointing to an IP address or to another hostname?

If you know the destination server IP, you are usually choosing between an A record and an AAAA record. If the destination is another hostname controlled by a provider, you are usually looking at a CNAME.

This is the core of the common A record vs CNAME question. Use an A record when you want direct control over an IPv4 destination. Use a CNAME when the target may change behind the scenes and the provider expects you to follow their hostname.

2. Is the record for web traffic, email, or internal service discovery?

Web and application traffic commonly use A, AAAA, and CNAME. Email uses MX and often TXT alongside it for authentication and verification. Service discovery may use SRV if a client or platform expects it.

Separating these use cases matters because an otherwise correct record may be useless for the wrong protocol. For example, a CNAME does not replace an MX record for mail routing.

3. Who controls the destination?

If your team runs the host directly on cloud hosting or business web hosting infrastructure, A and AAAA records often make sense. If a SaaS platform, CDN, or managed service gives you a target hostname, CNAME is often the cleaner fit because the provider can change the underlying IPs without forcing you to update DNS manually.

This is especially relevant for scalable hosting and fast web hosting setups where back-end endpoints can change over time.

4. Does the hostname need to coexist with other records?

Some record choices affect what else can exist at the same name. The classic example is that a CNAME generally should not sit alongside other record types at the same hostname. That constraint alone can determine your design. It is one reason teams sometimes use a CNAME on a subdomain like www while keeping the root domain on A or AAAA records.

5. How often will the destination change?

If the destination may move often, a hostname-based indirection model can be easier to maintain than hard-coded IPs. If the target is stable and fully under your control, direct A or AAAA records can be simpler and clearer.

When comparing records, avoid focusing only on syntax. Think in terms of control, change frequency, protocol, and compatibility. That is usually enough to identify the right record type before you open a DNS editor.

Feature-by-feature breakdown

This section walks through each major record type, what it does well, and where teams commonly get tripped up.

A record

An A record maps a hostname to an IPv4 address. It is one of the most common records in DNS and the default choice when you want a domain or subdomain to resolve directly to a server.

Best use cases:

• Pointing a root domain to a web server
• Directing a subdomain to a fixed IPv4 endpoint
• Connecting a domain to a load balancer or reverse proxy that exposes a stable IPv4 address

Advantages:

• Simple and explicit
• Works well when you control the destination infrastructure
• Easy to understand during troubleshooting

Watch for:

• If the server IP changes, you must update the record
• Some hosted platforms prefer hostname-based targets instead of direct IP mapping

If your site lives on cloud hosting with a stable endpoint, A records are often the cleanest answer.

AAAA record

An AAAA record does the same job as an A record, but for IPv6 addresses. If you have ever asked, what is AAAA record, the simple answer is: it points a hostname to an IPv6 destination.

Best use cases:

• Publishing IPv6 reachability for websites or services
• Dual-stack deployments where you want both IPv4 and IPv6 support

Advantages:

• Supports modern network environments
• Can improve compatibility in IPv6-capable networks

Watch for:

• Only publish AAAA records if the destination is correctly configured for IPv6
• Misconfigured IPv6 can cause intermittent or confusing access issues

For many teams, AAAA records are a maturity step rather than a day-one requirement. If your hosting provider supports IPv6 well, publishing both A and AAAA records can be sensible.

CNAME record

A CNAME creates an alias from one hostname to another hostname. It does not point directly to an IP address. Instead, it says that one DNS name should resolve through another.

Best use cases:

• Pointing www to a provider-managed hostname
• Connecting subdomains to SaaS services
• Following platform targets that may change over time

Advantages:

• Good for vendor-managed endpoints
• Reduces manual maintenance if underlying IPs change
• Useful in developer hosting tools and modern deployment workflows

Watch for:

• A CNAME should not generally share a name with other record types
• It can be the wrong choice at the zone apex depending on your DNS provider’s capabilities

In the A record vs CNAME comparison, the main difference is directness versus indirection. Choose A for a known IP you control. Choose CNAME when a provider gives you a canonical hostname and expects that alias model.

MX record

MX records define where incoming email for a domain should be delivered. They point to mail server hostnames and include priority values so mail transfer agents know which destination to try first.

Best use cases:

• Connecting a domain to a business email platform
• Maintaining primary and secondary mail delivery routes

Advantages:

• Purpose-built for mail routing
• Supports prioritized failover paths

Watch for:

• MX records point to hostnames, not raw email addresses
• Correct MX alone is not enough for modern email deliverability

When setting up email, MX is only part of the picture. You will often also need TXT records for verification, SPF, DKIM, or DMARC-related configurations. That is why many admins look for an MX TXT NS record guide rather than treating each record in isolation.

TXT record

TXT records hold text data associated with a name. They are widely used for domain ownership verification, email authentication, and security-related policy publishing.

Best use cases:

• Domain verification for external services
• Email authentication and anti-spoofing policies
• Human-readable metadata where a service expects TXT content

Advantages:

• Flexible and broadly supported
• Essential in many SaaS, SSL, and email setups

Watch for:

• Exact syntax matters
• Multiple TXT records can become hard to audit over time
• Poorly documented records often get left behind after migrations

TXT records are common in SSL hosting workflows too, especially where DNS-based validation is used. If certificate changes are part of your workflow, see How to Renew an SSL Certificate Without Breaking Your Website.

NS record

NS records specify which name servers are authoritative for a domain or delegated subdomain. They are foundational to DNS itself because they tell resolvers where the authoritative answers live.

Best use cases:

• Setting the authoritative DNS provider for a domain
• Delegating a subdomain to another DNS zone or team

Advantages:

• Enables delegation and separation of control
• Central to managed DNS migrations

Watch for:

• Changing NS records can affect the entire domain
• Registrar-side name server updates and zone content must stay aligned

If you are switching DNS hosting provider or moving domain management between platforms, NS records deserve extra care. Related reading: Domain Transfer Checklist: How to Move a Domain Without Downtime.

SRV record

SRV records advertise the location of specific services, including hostname and port, and may include priority and weight values. They are less common in basic website hosting but important in certain communication, authentication, and service discovery scenarios.

Best use cases:

• Applications that discover services by protocol
• Voice, messaging, directory, and other service-aware clients
• Internal environments where clients expect SRV lookups

Advantages:

• Supports richer service discovery than A or CNAME alone
• Encodes service-specific routing details

Watch for:

• Only useful when the client or application is designed to query SRV
• Formatting and naming conventions must be exact

SRV is a good example of why DNS record types exist as distinct tools. It solves a different problem than ordinary web record routing.

Best fit by scenario

If you do not want to memorize every record, use scenarios instead.

You are pointing a website to your server

Use A for IPv4 and AAAA if you also support IPv6. This is typical for domain hosting on infrastructure you control directly.

You are connecting a subdomain to a SaaS platform or CDN

Use CNAME if the provider gives you a target hostname. This is common with managed services, staging environments, and some fast web hosting or edge delivery tools. For more on adjacent performance decisions, see CDN vs Cloud Hosting: What Each One Does for Speed, Cost, and Reliability.

You are setting up business email

Use MX for inbound mail routing and TXT for verification and email authentication-related settings. In real setups, email almost always depends on both.

You are moving DNS to another provider

Use NS records to delegate the domain to the new authoritative name servers. Plan and verify carefully, especially if uptime matters. DNS changes affect the entire resolution path.

You are publishing service discovery details for a protocol-aware app

Use SRV if the application expects it. Do not substitute A or CNAME unless the application documentation explicitly allows a simpler pattern.

You are deciding between A and CNAME for www

In many environments, CNAME is a practical choice for www because it lets the destination hostname change without forcing you to edit your zone. If you need direct control or must target a known static endpoint, A may be better.

You are auditing a domain after migration

Check that your A, AAAA, CNAME, MX, TXT, and NS records all still match the current architecture. Old TXT verifications, stale MX values, and leftover aliases are common after website migration hosting projects. A related checklist can help: Website Migration Checklist: Moving Hosting Providers With Minimal Risk.

When to revisit

DNS is not a set-and-forget system. The right record type today can become the wrong one after a platform change, email migration, hosting redesign, or security update. Revisit your DNS records when any of the following happens:

• You change cloud hosting, web hosting, or load balancing architecture
• You move email providers or update authentication requirements
• You transfer a domain or switch managed DNS providers
• You introduce IPv6 support
• You adopt a new SaaS platform that requires verification or aliasing
• You clean up old staging environments or retired services

A practical review process looks like this:

1. Export the current zone so you have a readable snapshot.
2. Group records by purpose: website, email, verification, delegation, service discovery.
3. Mark ownership for each record: who added it, what service depends on it, and whether it is still active.
4. Check for duplication or conflict, especially around CNAME usage and stale TXT entries.
5. Lower TTLs before planned changes when appropriate, then restore normal values after the cutover.
6. Validate externally with multiple resolvers and confirm both expected and fallback behavior.

It is also worth revisiting DNS whenever reliability becomes a higher priority. DNS is tightly connected to uptime, failover behavior, SSL validation, and service reachability. If you are reviewing the broader reliability side of your stack, see Website Uptime Monitoring: What to Track and Which Alerts Matter Most and How to Read a Hosting SLA: Uptime Guarantees, Credits, and Common Gaps.

The useful habit is not memorizing every DNS edge case. It is building a simple decision rule: choose the record that matches the protocol, destination type, and control model you actually have. For most teams, that is enough to handle DNS records for beginners and advanced environments alike. Keep this page as a reference, and revisit it whenever your infrastructure, providers, or security requirements change.