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

Overview

At a high level, DNS turns human-readable names into service endpoints. When someone visits a website, sends an email, or connects an app to a hostname, DNS helps direct that request to the right destination.

The easiest way to understand DNS record types is to think in terms of intent:

• A and AAAA point a name to an IP address.
• CNAME points one name to another name.
• MX tells the internet where to deliver mail for a domain.
• TXT publishes text-based assertions, commonly for verification and email security.
• NS declares which name servers are authoritative for a zone.
• SRV advertises the host and port for a specific service.

These records often work together. A company website might use an A or AAAA record for the main site, a CNAME for www, MX records for email, TXT for SPF or domain verification, and NS records at the registrar to delegate the whole zone to a DNS provider.

If you are new to changing DNS at the registrar or hosting provider, see How to Point a Domain to Your Hosting Provider: DNS Records Step by Step. If you are deciding where to keep your domain registration and DNS, Domain Registrar Comparison: Pricing, WHOIS Privacy, Transfers, and Renewal Costs is a useful companion.

One more concept matters before comparing record types: TTL, or time to live. TTL is how long resolvers are allowed to cache a DNS answer. A shorter TTL can help changes propagate more quickly, while a longer TTL can reduce query volume and stabilize traffic patterns. TTL does not change what a record means, but it changes how quickly updates are seen.

How to compare options

The quickest way to choose the right DNS record is to ask four questions: what are you pointing to, who controls the destination, whether multiple records can coexist, and how future changes should be handled.

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

If your hosting provider gave you an IPv4 address, you usually need an A record. If they gave you an IPv6 address, you need an AAAA record. If a SaaS platform or CDN gave you a target hostname instead, you are usually looking at a CNAME.

This is the core of the common “a record vs cname” question. Use A or AAAA when you have the address. Use CNAME when you are aliasing one DNS name to another DNS name.

2. Is the name the zone apex or a subdomain?

The apex is the bare domain, such as example.com. A subdomain is something like www.example.com or app.example.com. This matters because many DNS setups allow CNAME records on subdomains but not at the apex when other required records already exist there.

That practical limitation influences many domain and hosting setups. It is common to place an A or AAAA record on the apex and a CNAME on www. Some DNS providers offer non-standard flattening or alias-like behavior at the apex, but those features are provider-specific. When you want a durable, portable setup, know whether you are using a standard DNS record or a provider convenience feature.

3. Does the record need to support multiple targets or priorities?

Some records are straightforward one-to-one mappings. Others are designed for more structured routing. MX records include priority values so multiple mail servers can be listed in order. SRV records can include priority and weight, along with the destination port. If a service expects failover behavior or service discovery, the record type matters.

4. Who owns change management over time?

If a vendor may change underlying infrastructure, a CNAME can be easier to maintain than hard-coding an IP address in an A record. If you control the server directly in cloud hosting or VPS hosting, an A or AAAA record may be the simpler and clearer choice. This tradeoff matters for scalable hosting, website migration to cloud hosting, and environments where services may move behind load balancers or global server hosting layers.

As a rule, prefer the record type recommended by the service you are integrating. DNS is less about personal preference than matching the protocol and operating model expected by the destination system.

Feature-by-feature breakdown

This section is your reference hub for common dns record types, including what each one does, where it is commonly used, and where mistakes happen.

A record

Meaning: Maps a hostname to an IPv4 address.

Typical use: Pointing a domain or subdomain to a web server, load balancer, reverse proxy, or firewall endpoint that has an IPv4 address.

Example use cases:

• Point example.com to a cloud hosting instance.
• Direct app.example.com to a VPS hosting node.
• Assign a subdomain to a dedicated service with a fixed IPv4 address.

Strengths: Simple, direct, universally understood.

Watch for: If the IP address changes, the record must be updated. That can make A records less convenient for platforms that abstract infrastructure behind hostnames.

Best mental model: An A record is a hard address entry for IPv4.

AAAA record

Meaning: Maps a hostname to an IPv6 address.

Typical use: The same role as an A record, but for IPv6-capable environments.

Example use cases:

• Publishing IPv6 reachability for a website.
• Supporting modern dual-stack infrastructure.
• Serving applications in networks where IPv6 connectivity matters.

Strengths: Enables IPv6 access and future-friendly networking.

Watch for: Do not publish AAAA records unless the service is actually reachable and configured over IPv6. Broken IPv6 can create confusing user experience and intermittent failures.

Best mental model: AAAA is the IPv6 version of A.

CNAME record

Meaning: Makes one hostname an alias of another hostname.

Typical use: Connecting subdomains to managed services, CDNs, website builders, or vendor platforms that want control over the final destination.

Example use cases:

• Point www.example.com to a hosting platform target.
• Connect docs.example.com to a documentation service.
• Map a branded subdomain to a third-party application endpoint.

Strengths: Easier maintenance when the vendor can update the underlying records without asking you to track IP changes.

Watch for: A CNAME should generally not coexist with other record types at the same name. Also be careful at the zone apex, where standard DNS constraints often make CNAME unsuitable.

Best mental model: CNAME says “this name should follow that other name.”

MX record

Meaning: Specifies which mail servers accept email for a domain.

Typical use: Routing inbound email to your mail provider.

Example use cases:

• Using a hosted email service for example.com.
• Setting backup or lower-priority mail exchangers.
• Migrating mail while keeping the same domain.

Strengths: Built for mail flow, with priority values to control preference order.

Watch for: MX records point to hostnames, not raw IP addresses. Those hostnames should resolve correctly with A or AAAA records. Also remember that email reliability often depends on matching MX with proper TXT records for SPF, DKIM, or DMARC, depending on your mail setup.

Best mental model: MX tells other mail systems where to deliver messages for your domain.

TXT record

Meaning: Publishes arbitrary text strings in DNS.

Typical use: Domain verification, email authentication, and service ownership checks.

Example use cases:

• Verifying domain ownership with a SaaS platform.
• Publishing an SPF policy for outbound mail sources.
• Adding a DMARC policy or verification token.

Strengths: Flexible, widely supported, essential for many modern integrations.

Watch for: TXT records are simple in concept but easy to break through formatting errors, quoting issues, line splitting, or duplicate conflicting policies. For email especially, do not treat TXT as “just text.” It can directly affect deliverability and trust.

Best mental model: TXT is the proof-and-policy drawer of DNS.

NS record

Meaning: Declares which name servers are authoritative for a zone or delegated subdomain.

Typical use: Pointing your domain at a DNS provider, or delegating a subdomain to another DNS authority.

Example use cases:

• Changing authoritative DNS when moving providers.
• Delegating dev.example.com to a separate team-managed DNS environment.
• Splitting authority between primary domain operations and a specialized subdomain service.

Strengths: Foundational to DNS control and delegation.

Watch for: NS changes are high impact. A mismatch between registrar-level delegation and zone contents can make the domain appear broken even if the records inside the zone look correct. This is one of the most common causes of confusion during migrations.

Best mental model: NS records decide who is in charge of answering for the zone.

SRV record

Meaning: Specifies the target host and port for a named service, often with priority and weight.

Typical use: Service discovery for protocols and applications that are built to query SRV records.

Example use cases:

• Voice, messaging, directory, or custom internal services.
• Applications that must discover both a host and a port through DNS.
• Environments where multiple service endpoints need weighted selection.

Strengths: More expressive than A or CNAME for service-aware clients.

Watch for: Only use SRV when the client or protocol explicitly supports it. A browser looking up a normal website does not use SRV to find https destinations in the everyday way people often assume.

Best mental model: SRV is DNS for “this specific service lives over there on that port.”

Quick comparison table in words

• If you need a website to point at a server IP: use A or AAAA.
• If you need a subdomain to follow a vendor-managed hostname: use CNAME.
• If you need mail delivery: use MX, usually alongside TXT.
• If you need domain verification or email policy: use TXT.
• If you need to change who runs DNS for the domain: use NS at the delegation level.
• If an application asks for service discovery with port and priority: use SRV.

Best fit by scenario

These practical patterns help connect record types to real hosting and domain workflows.

Scenario: Pointing a domain to web hosting or cloud hosting

If your provider gives you an IP address for the main site, use an A record for IPv4 and AAAA if you also run IPv6. If the provider gives you a hostname instead—common with CDNs, some managed WordPress hosting setups, and certain application platforms—use a CNAME on a subdomain such as www.

If you are still deciding among hosting models, How to Choose Between Shared Hosting, VPS, Cloud Hosting, and Dedicated Servers can help frame the infrastructure side before you finalize DNS.

Scenario: Running the bare domain and www cleanly

A common setup is:

• example.com → A/AAAA to the primary web endpoint
• www.example.com → CNAME to the canonical hostname

This keeps the apex compatible with standard DNS rules while letting www follow platform-managed changes if needed.

Scenario: Moving email without moving the website

Leave A, AAAA, or CNAME records for the website alone, and update MX records to the new mail provider. Then add or adjust the required TXT records for verification and email policy. This is one reason DNS management deserves careful change review: the website and email layers are independent, but they share the same zone.

Scenario: Verifying ownership for SaaS, SSL, or security services

Most ownership checks rely on TXT records. The service gives you a token and asks you to publish it under the domain or a special validation hostname. Read the hostname carefully. Adding the right value in the wrong place is a very common error.

For broader secure web hosting concerns, including certificates and service trust, your DNS hygiene matters. Small errors in validation records can delay SSL issuance or security onboarding even when the application itself is ready.

Scenario: Delegating a subdomain to another team or platform

Use NS records to delegate that subdomain. This is often cleaner than trying to recreate every needed record manually in one place, especially when a separate platform needs to manage dynamic entries under that subdomain.

Scenario: Troubleshooting a record that “looks right” but does not work

Check these in order:

1. Are you editing the authoritative DNS provider for the domain?
2. Is the hostname exact, including whether it is the apex or a subdomain?
3. Is the record type the one the service expects?
4. Are there conflicting records at the same name?
5. Has the TTL or cache window expired?
6. Are you changing the website path, the mail path, or zone delegation?

Many DNS issues are not about syntax. They come from changing the right value in the wrong zone, or the wrong record type at the right zone.

When to revisit

DNS is not something you configure once and forget. Revisit your records when the underlying services, providers, or operational needs change.

Review your DNS setup when:

• You migrate to new web hosting, VPS hosting, or cloud hosting.
• You add a CDN, email platform, security service, or external SaaS tool.
• You change domain registrar or authoritative DNS provider.
• You enable IPv6 and need to publish AAAA records.
• You split environments into production, staging, and development subdomains.
• You delegate part of the namespace to another team or vendor.
• You see email delivery, SSL validation, or intermittent reachability problems.

A simple practical routine is to keep a DNS inventory with four columns: hostname, record type, destination, and owner. Add notes for why a record exists and which service depends on it. That makes future changes safer and much easier to review.

For teams managing a growing infrastructure footprint, this is also where DNS intersects with broader hosting choices. Record sprawl often reflects architecture sprawl. If you are rationalizing providers or comparing setups for a small business site, Best Web Hosting for Small Business Websites: Updated Comparison Guide and The All‑in‑One Hosting Stack: Benefits, Risks, and How to Avoid Vendor Lock‑in are useful next reads.

Before making a DNS change, take these action steps:

1. Confirm which DNS provider is authoritative via NS delegation.
2. Document the current records before editing anything.
3. Lower TTL in advance if a planned cutover needs faster propagation.
4. Make one logical change set at a time.
5. Test from multiple resolvers or networks after the update.
6. Record the final state and the reason for the change.

If you remember only one rule from this guide, make it this: choose the record type based on what you are trying to express. A and AAAA express addresses, CNAME expresses aliasing, MX expresses mail routing, TXT expresses proof or policy, NS expresses authority, and SRV expresses service discovery. Once that mental model is clear, most DNS configurations become much easier to reason about and maintain.