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

Overview

If you have ever opened a DNS dashboard and faced a table full of hostnames, values, priorities, and TTL settings, you already know the problem: DNS management is simple in concept but easy to get wrong in practice. A single misplaced record can break a production site, stop email delivery, or leave a service half-configured for hours.

At a high level, DNS translates human-readable names into the information internet services need. Different record types answer different questions:

• A record: points a name to an IPv4 address.
• AAAA record: points a name to an IPv6 address.
• CNAME record: aliases one name to another name.
• MX record: tells the internet which mail servers receive email for your domain.
• TXT record: stores text-based data, often for verification, SPF, DKIM, and other email or service settings.
• NS record: identifies the authoritative nameservers for a zone or delegated subdomain.
• SRV record: specifies the host and port for certain services.

Here is the practical way to think about them:

• Use A and AAAA when you know the server IP.
• Use CNAME when a provider tells you to point one hostname to another hostname.
• Use MX for inbound mail routing.
• Use TXT for verification and email authentication.
• Use NS when changing DNS authority or delegating a subdomain.
• Use SRV for applications that need service discovery beyond a simple hostname.

Below is a working reference for each record type.

A record

An A record maps a hostname to an IPv4 address. This is one of the most common records in website deployment. If you launch an app on a VPS hosting instance or cloud server and your provider gives you an IPv4 address, the root domain or a subdomain will often use an A record.

Example use: pointing example.com to 203.0.113.10.

Common use cases: root domain for a website, direct server mapping, temporary migrations where traffic must go to a known IP.

AAAA record

An AAAA record does the same job as an A record, but for IPv6. Not every deployment uses IPv6, but when your cloud hosting environment supports it, adding AAAA can help modern network compatibility.

Example use: pointing example.com to an IPv6 address.

Common use cases: dual-stack hosting, IPv6-ready applications, infrastructure modernization.

CNAME record

A CNAME maps one hostname to another hostname instead of to an IP address. This is useful when the target may change behind the scenes and the provider wants to manage that change. Many CDNs, managed platforms, and SaaS tools use CNAMEs for custom domains.

Example use: pointing www.example.com to app.hostingplatform.net.

Common use cases: www aliases, custom domains for hosted apps, CDN integrations.

A record vs CNAME is a common point of confusion. If you have an IP address, use an A or AAAA record. If you have a target hostname, use a CNAME—assuming the DNS provider and the specific hostname allow it.

MX record

MX records define which mail servers accept email for your domain. They do not control where your website points. Each MX record usually has a priority value, and lower numbers generally mean higher preference.

Example use: routing mail for example.com to your email provider’s mail servers.

Common use cases: business email setup, email provider migration, backup mail routing.

MX records usually work together with TXT records for SPF, DKIM, and sometimes DMARC. If your mx record setup is correct but authentication records are missing, email may still be unreliable.

TXT record

TXT is the most flexible record type in everyday DNS management. It can hold ownership verification strings, SPF policies, DKIM public keys, domain verification codes for SaaS products, and other text-based instructions.

Example use: adding a TXT verification token for a cloud service or publishing an SPF rule.

Common use cases: domain verification, email authentication, site ownership confirmation, service onboarding.

Because many services rely on TXT records, it is common to have several at the same hostname. This is why careful naming and documentation matter.

NS record

NS records define which nameservers are authoritative for a domain or delegated part of it. At the registrar level, changing nameservers is often how you move DNS management from one provider to another. Inside a zone, NS records can also delegate a subdomain.

Example use: sending app.example.com to a separate DNS provider via delegation.

Common use cases: managed DNS migration, subdomain delegation, separating environments or teams.

If you are asking what is NS record in practical terms, the short answer is: it tells the internet who is in charge of answering DNS questions for that domain or subdomain.

SRV record

SRV records are less common in basic website launches but important in some application and communications setups. They specify a service name, protocol, target host, port, priority, and weight.

Example use: directing clients to a service like SIP, XMPP, LDAP, or certain game and internal application services.

Common use cases: voice services, chat systems, service discovery, enterprise application configuration.

For many small business websites, SRV will not appear often. For developers and IT teams, it becomes relevant when a tool or protocol specifically asks for it.

Checklist by scenario

Use this section as a quick decision guide before you add or edit anything in DNS.

1. Pointing a root domain to a server or VPS

• Confirm whether your hosting provider gave you an IPv4 address, an IPv6 address, or both.
• Create an A record for the root domain if you have IPv4.
• Create an AAAA record if you also use IPv6.
• Make sure no conflicting old A or AAAA records remain for the same hostname.
• If you use a reverse proxy, load balancer, or firewall layer, verify that the IP is the correct public endpoint.
• After DNS is active, complete SSL setup for the domain on the server or hosting platform.

This is the most common path when you host a website with a custom domain on cloud infrastructure.

2. Pointing a subdomain to a managed platform

• Check whether the platform requires a hostname target rather than an IP.
• Create a CNAME record for the subdomain, such as www, app, or docs.
• Do not mix a CNAME with other record types at the same hostname unless your provider supports a special flattened behavior.
• Verify the destination hostname exactly as given by the platform.
• Complete any required TXT verification records before expecting traffic to work fully.

This is common when connecting a domain to a static hosting service, application platform, or CDN.

3. Setting up business email

• Add the MX records provided by your email service.
• Remove old MX records if you are fully replacing the previous provider.
• Add the required TXT records for SPF.
• Add DKIM TXT records exactly as instructed, often at a selector-based hostname.
• If your provider recommends it, add a DMARC TXT record as well.
• Test both sending and receiving after propagation.

If email matters to your operations, treat this as a controlled change. Website DNS and mail DNS often change together during launches, but they should be checked separately.

4. Verifying a domain for a third-party service

• Read whether the provider wants a TXT record, CNAME, or both.
• Use the exact hostname requested. Some dashboards expect the root, while others require a prefixed host such as _acme-challenge or _service.
• Paste the token exactly, without trimming characters.
• Wait for propagation before retrying verification.
• Document whether the record must stay permanently or can be removed later.

This is one of the most common uses of txt record DNS entries outside email.

5. Changing DNS providers or moving domain management

• Export or document all existing records first.
• Recreate the zone at the new provider before changing nameservers.
• Compare A, AAAA, CNAME, MX, TXT, NS, and SRV records line by line.
• Lower TTL values in advance if you control the timing.
• Change registrar-level nameservers only when the new zone is complete.
• Monitor website, API, and email behavior after the cutover.

For a deeper operational process, pair this with a full nameserver change guide or a domain transfer checklist.

6. Delegating a subdomain to another team or service

• Decide which subdomain will be delegated, such as dev.example.com or mail.example.com.
• Add NS records for that subdomain in the parent zone.
• Confirm the child zone exists and is authoritative on the target nameservers.
• Do not leave duplicate conflicting records for the same delegated hostname in the parent zone.
• Test resolution against the delegated nameservers directly if needed.

This pattern is useful when different teams manage production, staging, or specialized applications separately.

What to double-check

Most DNS issues come from small mismatches rather than major design mistakes. Before saving or troubleshooting, run through this short review list.

• Hostname scope: Are you editing the root domain, a subdomain, or a service-specific prefixed host?
• Target type: Did the provider give you an IP address or a hostname? That determines whether you need A/AAAA or CNAME.
• Record conflicts: Are there older records at the same hostname that will override or conflict with the new one?
• TTL: Is the TTL reasonable for the change window? Lower TTLs can help planned migrations, though they do not remove all caching delays.
• Priority values: For MX and some SRV records, are the priority numbers correct?
• Copy accuracy: TXT values, DKIM keys, and verification strings are easy to break with a missing quote or extra space.
• Registrar vs DNS host: Are you editing the place that actually hosts your DNS? This is a common issue when domain registration and DNS management are split across providers.
• Propagation expectations: Have you allowed enough time for caches to update before declaring the change broken?

When you connect a domain to hosting, it also helps to verify the application side: virtual hosts, SSL certificates, redirect rules, and firewall settings. DNS may be correct while the server remains unprepared.

If you are still deciding where to keep your domain and DNS, see Best Domain Registrars for Developers and Small Businesses and Domain Registration Pricing Guide: First-Year vs Renewal Costs by Registrar. A cleaner control panel and predictable renewal terms can reduce future DNS friction.

Common mistakes

This section is intentionally practical. These are the errors that repeatedly slow down launches and troubleshooting.

Using a CNAME at the wrong place

Many providers suggest CNAME because it is convenient, but not every hostname can use it safely in every DNS setup. The root domain is a frequent source of confusion. If your DNS provider offers special support for root alias behavior, follow its implementation carefully. Otherwise, use the record type your provider explicitly recommends.

Leaving old MX records in place

During an email migration, old and new MX records can coexist in a way that produces inconsistent delivery. If you are replacing a provider rather than running a deliberate split setup, remove the previous MX entries once the transition plan allows it.

Assuming TXT means “just one record”

A domain may need multiple TXT records for SPF, DKIM, verification, and policy controls. The mistake is not having many TXT records; the mistake is losing track of which one belongs to which service and whether it is still required.

Editing records in the wrong dashboard

If your domain registration is with one company, your managed DNS with another, and your cloud hosting elsewhere, it is easy to update the wrong panel. First identify where the authoritative nameservers point. That tells you which DNS zone actually matters.

Forgetting IPv6

If your infrastructure publishes AAAA records but the application is not truly reachable over IPv6, some users may experience intermittent failures. Either support IPv6 correctly or avoid publishing AAAA until the stack is ready.

Expecting DNS to fix application issues

DNS only gets traffic to the right place. It does not install SSL, open ports, fix redirects, or start a broken service. After you deploy an app on a cloud server, DNS is only one part of the launch path.

Making changes without a snapshot

Before any significant DNS change, export the zone or copy all current records into a versioned document. That simple habit makes rollback much easier.

For adjacent planning, readers working on brand and naming decisions may also find these useful: How to Choose a Domain Name for a Startup, SaaS, or Side Project and New Domain Extension Guide: Which TLDs Are Worth Buying?.

When to revisit

DNS records are not something you configure once and forget. Revisit this checklist whenever the underlying service, ownership, or traffic path changes.

• Before launching a new website or application: confirm A, AAAA, or CNAME targets and certificate readiness.
• Before moving hosting providers: audit all records tied to the current infrastructure.
• Before changing email platforms: review MX, SPF, DKIM, and any existing verification records.
• Before transferring a domain or changing nameservers: inventory the entire zone and verify the destination setup first.
• When adding a new SaaS tool: check whether it requires TXT, CNAME, or SRV-based verification.
• During seasonal planning cycles: confirm that key vendors, domains, and subdomains still reflect current business and technical needs.
• When workflows or tools change: update documentation so the next DNS edit is faster and safer.

A simple recurring action plan works well:

1. List your active domains and subdomains.
2. Map each one to its purpose: website, app, API, email, staging, verification, or delegated service.
3. Review record accuracy against the current provider instructions.
4. Remove obsolete records that no longer serve a purpose.
5. Document ownership so future changes are not blocked by guesswork.

If you want DNS management to feel less fragile, the goal is not memorizing every edge case. It is building a repeatable review habit: identify the hostname, choose the right record type, check for conflicts, validate the target, and confirm the outcome after propagation. That process will solve most day-to-day DNS tasks, whether you are connecting a new domain, cleaning up old records, or preparing for a hosting change.