DNS Record Types Explained: A, AAAA, CNAME, MX, TXT, SRV, and When to Use Them

Overview

If you have ever opened a DNS zone and seen a list of short labels with unfamiliar names, you are not alone. DNS can look simple at first—just point a domain somewhere—but each record type solves a different problem. Choosing the wrong one can break mail delivery, create avoidable redirects, or make a future migration harder than it needs to be.

At a high level, DNS records map names to destinations or instructions:

• A records point a hostname to an IPv4 address.
• AAAA records point a hostname to an IPv6 address.
• CNAME records make one hostname an alias of another hostname.
• MX records tell the internet which mail servers accept email for your domain.
• TXT records publish free-form text used for verification, email authentication, and service configuration.
• SRV records advertise a service, including host and port, for protocols that support service discovery.

The key idea is that DNS records are not interchangeable. An A record answers “what IP address should this name use?” A CNAME answers “what canonical hostname should this name follow?” An MX record answers “where should mail go?” Understanding that difference is more useful than memorizing definitions.

Before going deeper, two terms matter in almost every DNS setup:

• Hostname or name: the label you are configuring, such as @ for the root domain, www, mail, or app.
• TTL: time to live, or how long resolvers may cache an answer before checking again. A shorter TTL can help during migrations, while a longer TTL can reduce repeated lookups in stable setups.

If you are still getting comfortable with the basics of pointing a domain, see How to Point a Domain to Your Hosting Provider: A Complete DNS Setup Guide. If you make changes and do not see results immediately, DNS Propagation Explained: How Long It Takes and How to Check It is a useful companion reference.

How to compare options

The most useful way to compare DNS record types is not by technical definition alone, but by the question each one answers. When you know the job to be done, the right record type usually becomes obvious.

1. Ask what the destination really is

Use an A or AAAA record when the destination is a direct IP address. Use a CNAME when the destination is another hostname managed elsewhere. This is the heart of the common “A vs CNAME” decision.

Examples:

• If your cloud hosting provider gives you 203.0.113.10, that points to an A record.
• If your CDN or app platform gives you yourapp.provider.example, that usually points to a CNAME.

2. Ask whether the record is for web, email, or service verification

Web traffic often relies on A, AAAA, or CNAME. Email depends on MX plus supporting TXT records. Ownership checks for SaaS tools often use TXT or sometimes CNAME. A custom protocol may require SRV. Keeping those categories separate helps avoid the common mistake of putting web records where mail records belong, or vice versa.

3. Check whether the name is the root domain or a subdomain

The apex, zone root, or bare domain—usually shown as @—has special constraints in many DNS environments. Some providers do not allow a standard CNAME at the root because other records must coexist there. In practice, that means:

• Root domain: often uses A and AAAA records.
• Subdomains like www, blog, or shop: often use CNAME if the target is another hostname.

Managed DNS platforms may offer provider-specific ways to emulate root-level aliasing, but you should verify how your DNS hosting service handles apex records before copying a generic setup guide.

4. Consider future migrations

Sometimes the best record is the one that makes the next move easier. If a provider gives you a stable hostname target, a CNAME can reduce future maintenance because the provider can update the destination behind that hostname. If you hard-code an A record to an IP that later changes, you will need to update it yourself.

This becomes especially relevant during website moves. If you are planning a host change, pair your DNS planning with a migration checklist such as Website Migration Checklist: Move Hosting Providers Without Breaking SEO or Email.

5. Compare by operational risk

Some DNS mistakes are more disruptive than others:

• Wrong A or AAAA record: website may not load.
• Wrong CNAME: subdomain may resolve incorrectly or not at all.
• Wrong MX: incoming email can fail.
• Wrong TXT for SPF, DKIM, or verification: authentication or setup may break.
• Wrong SRV: service clients may fail to discover the right endpoint.

When the record affects email, production apps, or authentication, change one item at a time, document the previous value, and lower TTL in advance if your provider allows it.

Feature-by-feature breakdown

This section is the practical core of the guide: what each record does, where it fits, and when to avoid it.

A record

Purpose: Maps a hostname to an IPv4 address.

Use it when: Your hosting provider, server, load balancer, or firewall gives you an IPv4 address for a site or service.

Common examples:

• @ → 203.0.113.10 for the main website
• app → 203.0.113.20 for a self-managed application

Strengths: Simple, direct, widely supported, and usually the default choice for root domains.

Watch for: If the provider changes the IP later, you must update the record yourself. That is why A records are straightforward but not always the most flexible option for platforms that abstract infrastructure behind hostnames.

AAAA record

Purpose: Maps a hostname to an IPv6 address.

Use it when: Your infrastructure supports IPv6 and you want clients to resolve the service over IPv6 as well as, or instead of, IPv4.

Common examples:

• @ → 2001:db8::10
• api → 2001:db8::20

Strengths: Supports modern network compatibility and can be part of a dual-stack setup alongside A records.

Watch for: Do not publish AAAA records unless the target service is actually reachable and correctly configured over IPv6. A broken IPv6 path can create inconsistent user experience that is hard to diagnose.

CNAME record

Purpose: Makes one hostname an alias of another hostname.

Use it when: A service provider tells you to point a subdomain to a hostname instead of an IP address.

Common examples:

• www → yoursite.hostplatform.example
• docs → cname.docsprovider.example

Strengths: Flexible and migration-friendly. If the provider changes the underlying IPs, they can update the canonical hostname without requiring you to edit DNS again.

Watch for: A hostname with a CNAME generally should not also have other record types at the same name. Also, the root domain often cannot use a standard CNAME under traditional DNS rules. This is one of the main reasons people search for “a vs cname record.” The short answer is: use A for direct IP mapping, use CNAME when you need one hostname to follow another.

MX record

Purpose: Specifies which mail servers receive email for a domain.

Use it when: You want user@yourdomain.com to receive mail through your chosen provider.

Common examples:

• @ → mail1.provider.example with one priority
• @ → mail2.provider.example with another priority

Strengths: Built specifically for mail routing and supports multiple servers with priorities.

Watch for: MX records do not replace the need for supporting records. Modern email setups often also require TXT records for SPF, DKIM, and sometimes DMARC. If you change website hosting, do not assume mail should change too. Web and mail DNS can be separate. This is a common source of accidental downtime during domain transfer or hosting migration.

For broader launch planning that includes DNS and mail, see How to Launch a Small Business Website: Domain, Hosting, Email, SSL, and DNS Checklist.

TXT record

Purpose: Publishes text values used for verification, policy, or metadata.

Use it when: A provider asks you to verify domain ownership, configure email authentication, or publish a policy string.

Common examples:

• Domain verification tokens for SaaS products
• SPF policy strings for email sending authorization
• DKIM public key material
• DMARC policy instructions

Strengths: Flexible and widely used across services.

Watch for: TXT records are easy to add incorrectly because the values can be long, quoted, or split depending on provider requirements. Copy them exactly. Also, avoid deleting existing TXT records without confirming their purpose. A domain may use several TXT records for unrelated services at the same time.

SRV record

Purpose: Advertises a specific service, including protocol, port, priority, and target host.

Use it when: A service or protocol explicitly supports SRV-based discovery.

Common examples:

• Voice, messaging, directory, game, or other custom service discovery patterns
• Internal service documentation that tells clients to look up a named service under a domain

Strengths: More expressive than A or CNAME for service-aware clients because it can specify both host and port.

Watch for: SRV records only help if the client or application is built to query them. They are powerful, but not universal. If your platform documentation does not call for SRV, do not assume it is needed.

A quick comparison table in words

If you prefer a mental shorthand:

• A: “Send this name to this IPv4 address.”
• AAAA: “Send this name to this IPv6 address.”
• CNAME: “This name is really another hostname.”
• MX: “Mail for this domain goes to these mail servers.”
• TXT: “Publish this verification or policy text.”
• SRV: “This service is available on this host and port.”

Best fit by scenario

Most DNS questions become easier when tied to real configuration tasks. Here is the practical mapping for common situations.

Scenario 1: Pointing a root domain to a website

Usually use: A record, and AAAA if IPv6 is supported.

If your domain is example.com and your host gives you direct IPs, start here. This is the most common setup for self-managed servers, some VPS deployments, and many straightforward web hosting environments.

Scenario 2: Pointing www to a platform or CDN

Usually use: CNAME.

This is common for cloud web hosting, edge platforms, and managed application services that assign a provider hostname instead of a fixed customer IP. It is also one reason managed DNS and fast web hosting often go together operationally: DNS should be flexible enough to follow platform-managed endpoints cleanly.

Scenario 3: Setting up business email

Usually use: MX plus TXT.

The MX records route mail. TXT records usually handle sender authorization and signing. If you are moving only your website, leave mail records untouched unless you are also changing email providers.

Scenario 4: Verifying a domain with a third-party service

Usually use: TXT, sometimes CNAME.

Many tools ask you to place a verification token in DNS to prove domain control. These records may feel temporary, but they often remain necessary for ongoing service trust, so do not remove them casually after the initial setup succeeds.

Scenario 5: Publishing a custom application service

Usually use: SRV, sometimes alongside A or AAAA.

Use this when service discovery needs more than a hostname. Internal documentation should specify the required name format and the expected client behavior.

Scenario 6: Preparing for a hosting migration

Usually use: Existing records first, then a controlled change plan.

Before switching values, inventory everything in the zone: web, mail, verification, and custom services. Lower TTL in advance if possible. Change only the records related to the move. This prevents the classic mistake of treating DNS like a single website setting when it may also power email and external integrations.

If you are choosing where the site itself should live next, related reads include Shared Hosting vs Cloud Hosting for Small Business: Which Is Worth It in 2026? and Best Cloud Hosting for WordPress: Managed Options Compared by Speed, Support, and Cost.

When to revisit

DNS is not something you configure once and forget forever. The right setup can change as your hosting model, email provider, network stack, or security requirements change. This is when it makes sense to revisit your DNS records guide and audit the zone again.

• When you change hosting providers: Recheck A, AAAA, and CNAME targets.
• When you add or change email services: Review MX and TXT records together.
• When a platform updates setup instructions: Verify whether verification or aliasing requirements changed.
• When you enable IPv6: Add or validate AAAA records carefully.
• When you adopt a new service with domain verification: Confirm whether TXT or CNAME is required and document why it exists.
• When DNS features or provider policies change: Revisit any root-domain aliasing assumptions and TTL strategy.

A practical review routine looks like this:

1. Export or copy the current zone before editing.
2. Label each record by purpose: web, mail, verification, or app service.
3. Remove only records you can confidently attribute and retire.
4. Lower TTL ahead of planned cutovers, then raise it again after the change stabilizes if appropriate.
5. Test website resolution, email flow, and service verification separately.
6. Document the final state so the next migration is easier.

If you are also reviewing providers, DNS hosting performance, or failover features, Best Managed DNS Providers: Speed, Failover, DNSSEC, and Pricing Compared can help frame that next step.

The main takeaway is simple: DNS record types are easier to manage when you think in jobs, not jargon. Use A and AAAA for direct IP mapping, CNAME for hostname aliasing, MX for mail routing, TXT for verification and policy, and SRV for service-aware discovery. That model is stable enough to use whether you are launching a small site, running managed DNS for multiple apps, or planning your next domain and hosting migration.