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

Overview

At a high level, DNS is the system that maps human-friendly names like example.com to the services behind them. A browser, mail server, or app asks DNS for instructions, and DNS responds with the record data it needs.

The most useful way to understand DNS records is by the job each one performs:

• A record: Points a hostname to an IPv4 address.
• AAAA record: Points a hostname to an IPv6 address.
• CNAME record: Points one hostname to another hostname.
• MX record: Tells the internet which mail servers receive email for your domain.
• TXT record: Stores text-based information, often for verification, email authentication, or service configuration.
• NS record: Declares which name servers are authoritative for a domain or subdomain.
• SRV record: Specifies the hostname and port for particular services.

Before working with any of them, keep four DNS basics in mind:

1. Hostnames matter. The root domain, a subdomain, and a service-specific host are all different labels. example.com, www.example.com, and mail.example.com are separate DNS names.
2. One wrong character can break a working setup. A missing dot, an extra subdomain, or the wrong priority value can be enough to cause failures.
3. DNS changes are not always instant. Records can update quickly or take time to be seen consistently due to caching and TTL behavior.
4. DNS and hosting are related, but not the same. Your domain registration, DNS management, and web hosting may live with different providers. If you are moving sites between shared hosting, managed WordPress hosting, VPS hosting, or cloud hosting, DNS is often the final step that makes the new environment live.

Here is a short reference you can bookmark:

A record

Use an A record when a hostname should resolve directly to an IPv4 address, such as 203.0.113.10. This is common when pointing a website to a server, load balancer, or cloud server for website hosting.

Typical use: Point example.com or app.example.com to a server IP.

AAAA record

Use an AAAA record when a hostname should resolve to an IPv6 address. If your provider supports IPv6, this record lets clients connect over IPv6 instead of IPv4.

Typical use: Add IPv6 support alongside existing A records.

CNAME record

Use a CNAME when a hostname should alias another hostname rather than point directly to an IP. For example, www.example.com can point to sites.hostingplatform.net.

Typical use: Connect subdomains to hosted services, CDNs, SaaS tools, or managed platforms.

Important: A CNAME generally should not coexist with other record types on the same hostname.

MX record

Use MX records to direct inbound email for a domain. Mail providers typically give you one or more mail server hostnames and a priority value.

Typical use: Receive email at addresses like name@example.com.

TXT record

Use TXT records for ownership verification and service metadata. Many email-related settings also depend on TXT records, including SPF, DKIM, and DMARC.

Typical use: Verify a domain with a provider, authorize outbound email senders, or publish mail policy.

NS record

Use NS records to define which name servers answer for a domain. Your registrar may show delegation settings separately from your zone file, so it is important to know whether you are changing the domain's delegation or only editing records within an existing DNS provider.

Typical use: Point a domain to a different DNS host or delegate a subdomain.

SRV record

Use SRV records when a service requires not only a host, but also a port and priority details. These are common in voice, messaging, directory, and other application-specific setups.

Typical use: Configure service discovery for applications that expect SRV support.

Checklist by scenario

Use this section as a working checklist before you change records. The right record type becomes much clearer once you match it to the task.

1. Point a website to a new server or cloud hosting environment

If you are launching a new site, switching business web hosting, or moving to scalable hosting, these are the usual steps:

• Use an A record for the root domain if your provider gives you an IPv4 address.
• Use an AAAA record as well if your provider gives you an IPv6 address and supports it cleanly.
• Use a CNAME for www if your provider recommends aliasing it to another hostname.
• Confirm whether your host expects the root domain and www to resolve the same way or differently.
• Check SSL issuance after DNS changes, especially if the host provisions SSL automatically after validation.

This is common during a migration from shared hosting to VPS hosting or cloud hosting. If you are preparing a transfer, it helps to separate the hosting move from the domain move. For a domain move workflow, see How to Transfer a Domain Name Without Downtime.

2. Connect a subdomain to a hosted app or managed platform

Hosted services often want a subdomain such as app.example.com, shop.example.com, or blog.example.com.

• Use a CNAME record if the service gives you a target hostname.
• Use an A record only if the service explicitly gives you an IP address.
• Make sure the exact hostname matches the provider instructions. app is not the same as www.app.
• Check whether the provider also requires a TXT record for verification.

This is often the cleanest approach for external tools because the service can change its own underlying IPs while your CNAME continues to work.

3. Set up business email

Email delivery depends on more than one record type. The minimum working setup usually includes:

• MX records for inbound mail routing.
• TXT records for SPF and often DMARC.
• A provider-specific TXT or CNAME for domain verification.
• Additional records such as DKIM, which many providers publish through TXT or CNAME depending on their system.

If your website and email live with different providers, be careful not to overwrite working mail records while updating web records. That is one of the most common domain and hosting mistakes during migrations.

4. Verify domain ownership for third-party services

Many services ask you to prove you control a domain before they will issue SSL, send email, or enable platform features.

• Most often, you will add a TXT record with a token string.
• Some providers use a CNAME record instead.
• Enter the hostname exactly as requested. A token for the root domain may differ from a token for a subdomain.
• Keep the verification record in place if the provider says ongoing validation depends on it.

5. Change DNS providers or delegate name servers

This is where NS records matter most, but there are two different tasks people often mix up:

• Changing the domain's authoritative name servers at the registrar. This switches DNS hosting to another provider.
• Editing NS records inside a zone. This usually delegates a subdomain, not the whole domain.

Checklist:

• Export or copy all existing records before changing providers.
• Recreate website, email, verification, and custom records in the new DNS zone before switching delegation.
• Verify MX and TXT records carefully. Email is often the first thing to break when DNS is incomplete.
• Lower TTL in advance if you want a faster cutover, when your provider allows it.

6. Configure service-specific apps such as VoIP, chat, or directory tools

If a product asks for SRV records, capture every required field:

• Service name
• Protocol
• Priority
• Weight
• Port
• Target hostname

SRV records are less common in standard website hosting, but they appear often enough in business IT setups that they deserve a place in any reusable DNS reference.

What to double-check

Most DNS issues come from implementation details rather than from choosing the wrong record family. Before saving any change, review this short list.

Hostname and zone context

DNS control panels do not all display hostnames the same way. Some expect only the label, such as www. Others show the full domain automatically. If you enter the full name where only the label is expected, you can accidentally create a malformed record like www.example.com.example.com.

Record conflicts

The classic example is A record vs CNAME. A hostname generally cannot be both a CNAME and also have separate A, MX, or TXT records attached to that same label. If you use a CNAME for www, keep other records off that same www label unless your provider explicitly supports a special behavior.

TTL values

TTL controls how long resolvers may cache a record. Lower TTLs can help during planned changes, but they are not magic. Caches may still delay what users see. For stable records, a moderate TTL is often simpler to manage. For migrations, many teams lower TTL ahead of time, make the change, then raise it later.

Priority values for MX and SRV

With MX records, lower priority numbers are usually preferred first. If you mistype priority order, mail may route differently than intended. SRV records have both priority and weight, so review all values carefully.

Root domain vs subdomain behavior

Some platforms are designed around www as a CNAME and handle the apex domain separately. Others support direct A or AAAA records at the root. Know what your provider expects before you change anything.

Email authentication records

TXT records can look deceptively simple, but SPF, DKIM, and DMARC have formatting rules. Extra spaces, quotation behavior, multiple SPF records, or missing semicolons can cause problems. If email matters to your business, review these entries line by line.

Name server location

If you changed records in one dashboard and nothing happens, confirm you edited the active DNS provider. This issue is common after domain transfer, DNS migration, or registrar changes. The panel you can log into is not always the panel that is authoritative.

Common mistakes

If you are troubleshooting a broken setup, start here. These mistakes show up repeatedly across website launches, email migrations, and domain registration changes.

• Using a CNAME at the wrong place. This often happens at the root domain or on a hostname that already needs other record types.
• Deleting old MX records before the new provider is ready. Web traffic might be fine while email quietly fails.
• Adding multiple SPF TXT records. A domain should generally publish one combined SPF policy rather than several separate SPF records.
• Editing the wrong DNS zone. This is common when registrar DNS and hosting DNS both exist.
• Ignoring IPv6. If AAAA records exist but the service is not configured correctly, some users may have issues even when IPv4 works.
• Copying examples too literally. Placeholder domains, trailing dots, and quoted strings may need adaptation to your DNS provider's format.
• Changing NS records without replicating all existing records first. Website and email outages often start here.
• Assuming propagation is the only issue. Waiting longer does not fix a malformed record.

DNS problems often surface during broader infrastructure changes. If you are comparing environments before moving a site, Shared Hosting vs VPS vs Cloud Hosting: A Practical Comparison Guide can help you decide what is changing on the hosting side. If you are running WordPress, Managed WordPress Hosting vs Regular Web Hosting: What Actually Changes? is a useful companion read before you update DNS to point at a new platform.

When to revisit

DNS documentation is most useful right before you make a change. Revisit this checklist whenever one of these events happens:

• You launch a new website or move to a new web hosting provider.
• You start using a new email platform.
• You add a CDN, app platform, or external service on a subdomain.
• You transfer a domain to a different registrar or DNS host.
• You introduce IPv6 support.
• You add ecommerce, staging, API, or support subdomains.
• You change workflows, automation, or infrastructure tools.
• You are preparing for a seasonal promotion, product launch, or traffic spike and want to reduce avoidable DNS risk.

A practical habit is to keep a simple DNS inventory for each domain:

1. List every active hostname.
2. Note which record types each hostname uses.
3. Document which provider is authoritative for DNS.
4. Record which services depend on TXT verification or mail authentication.
5. Review TTL strategy before planned migrations.
6. Test website resolution, SSL, and email flow after each change.

If you are still early in the domain lifecycle, you may also find these guides helpful: How to Choose a Domain Name for Your Business and Domain Extensions Explained: .com vs .net vs .org vs New TLDs. They pair well with DNS planning because naming, registration, and DNS management are easiest when treated as one system rather than separate tasks.

Final action checklist before any DNS change:

• Confirm the exact hostname you are editing.
• Confirm you are in the authoritative DNS provider.
• Choose the record type that matches the task, not just the example you found first.
• Check for conflicts, especially A record vs CNAME issues.
• Review mail records separately from web records.
• Save a backup or screenshot of current settings.
• Validate the result after the change instead of assuming it worked.

That habit alone will prevent a large share of avoidable DNS incidents.