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

Overview

If you manage a domain, DNS is the control panel behind almost every connection your site and services depend on. When someone visits your website, sends email to your domain, or uses a service that needs domain verification, DNS records tell the internet where to go and how to handle that request.

Here is the simplest way to think about the main DNS record types:

• 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 instead of directly to an IP address.
• MX record: tells the internet which mail servers receive email for your domain.
• TXT record: stores text-based instructions or verification data, often used for email authentication and domain verification.
• NS record: defines which nameservers are authoritative for a domain or subdomain.
• SRV record: specifies the host and port for certain services.

These records solve different problems. The mistake many people make is assuming DNS is one generic setting. In practice, each record type has a narrow role, and using the wrong one can break only part of your setup: web traffic may work while email fails, or the root domain may resolve while www does not.

Below is a practical reference for each record type.

A record

An A record maps a hostname like example.com or app.example.com to an IPv4 address such as 203.0.113.10. This is one of the most common records in a domain DNS setup guide because it is often how a domain points to a web server.

Use an A record when your hosting provider gives you a direct IPv4 address and tells you to point a hostname there.

Typical use cases:

• Pointing the root domain to a web server
• Pointing a subdomain to an application server
• Connecting a self-managed VPS or cloud instance

AAAA record

An AAAA record works like an A record, but for IPv6 addresses. If your hosting stack supports IPv6, you may be asked to create this record alongside or instead of an A record.

Typical use cases:

• Enabling IPv6 access to a website
• Supporting modern hosting environments with dual-stack networking

CNAME record

A CNAME record maps one hostname to another hostname. For example, www.example.com might point to sites.provider.net. This is common with website builders, SaaS platforms, CDNs, and managed hosting platforms that want you to target a provider-controlled hostname.

This is where the common A record vs CNAME question matters. An A record points directly to an IP. A CNAME points to another name, which then resolves further.

Typical use cases:

• Pointing www to a hosting platform hostname
• Connecting a subdomain to a CDN or app deployment platform
• Simplifying changes when the provider updates underlying IPs

One important limitation: many DNS providers do not allow a CNAME at the root domain apex because other records are usually required there. Some providers work around this with alias-style records, but the exact label varies by platform.

MX record

The MX record meaning is straightforward: it tells mail senders where to deliver email for your domain. If you use a hosted email provider, they will usually give you one or more MX records with priority values.

Typical use cases:

• Receiving email at addresses like you@example.com
• Switching from one email provider to another

MX records do not send email by themselves. They only control incoming mail routing. Outbound email trust usually depends on TXT records such as SPF, DKIM, and DMARC.

TXT record

A TXT record for domain settings can carry several kinds of text instructions. This is one of the most overloaded DNS record types because many services use it for verification or security.

Typical use cases:

• Domain verification for search tools, email providers, and SaaS platforms
• SPF records that help define allowed mail senders
• DKIM public keys used for email signing
• DMARC policies for email authentication reporting and handling

When a provider asks you to add a TXT record, pay close attention to the host value and whether they want the record at the root, at a subdomain, or with a selector-like prefix.

NS record

NS records specify which nameservers are authoritative for a domain. In simple terms, they determine where DNS is managed. If your registrar points to one nameserver provider but you edit records somewhere else, your changes will not take effect.

Typical use cases:

• Delegating the whole domain to a DNS provider
• Delegating a subdomain to a separate DNS zone
• Moving DNS management during a hosting migration

NS records are foundational. If these are wrong, every other record can appear correct in the wrong place and still not work publicly.

SRV record

SRV records are less common for basic websites but still important in technical environments. They define the hostname and port for specific services. Some communications, directory, or application services may require them.

Typical use cases:

• Voice or messaging services
• Directory or authentication services
• Custom apps that discover services through DNS

SRV records are more structured than basic records, so they are easier to misconfigure. The service name, protocol, priority, weight, port, and target all need to match the provider instructions exactly.

Checklist by scenario

Use this section as a before-you-click checklist. The goal is not just to know the DNS record types, but to choose the right one for the task in front of you.

1. Pointing a website to a hosting server

• Confirm whether your host gave you an IPv4 address, an IPv6 address, or a provider hostname.
• If you were given an IPv4 address, use an A record.
• If you were given an IPv6 address, use an AAAA record.
• If you were given a target hostname, use a CNAME for the relevant subdomain.
• Check whether the root domain and www need separate records.
• Confirm whether your host expects proxying, CDN integration, or direct DNS resolution.

If you are still choosing infrastructure, compare DNS flexibility alongside hosting features. Related reading: Best WordPress Cloud Hosting Providers Compared for Speed, Support, and Price and CDN vs Web Hosting: What Each One Does and When You Need Both.

2. Connecting a website builder or hosted platform

• Read the provider instructions carefully because website builders often use a combination of A records and CNAME records.
• Check whether the platform wants the root domain connected directly and www redirected, or the reverse.
• Make sure no old A or CNAME records conflict with the new setup.
• Verify SSL issuance after DNS updates complete.

If you are deciding between platforms before touching DNS, see Website Builder vs WordPress: Which Platform Fits Your Site in 2026? and Best Website Builder for Small Business: Ease of Use, SEO, and Cost Compared.

3. Setting up business email

• Add the provider’s MX records exactly as given, including priority values.
• Remove old MX records if you are fully migrating to a new email provider.
• Add required TXT records for SPF, DKIM, and possibly DMARC.
• Confirm whether autodiscover or mail subdomains also need records.
• Test both receiving and sending mail after propagation.

Email DNS is one of the easiest places to create partial failures. Your website can look fine while messages silently route to the wrong provider or fail authentication checks.

4. Verifying a domain with a third-party service

• Use the exact TXT record name and value provided.
• Check whether the host should be blank, @, or a specific label, depending on your DNS provider.
• Avoid adding extra quotes or spaces unless the interface adds them automatically.
• Do not delete the verification record immediately after success unless the service explicitly says it is temporary.

This scenario is common with analytics platforms, email tools, and webmaster products. If you are preparing a site for launch, keep verification records organized alongside your other launch tasks: Website Launch Checklist: Everything to Set Up Before You Go Live and Website Launch Checklist for Small Business Sites: Domains, Hosting, SSL, SEO, and Analytics.

5. Moving DNS to a new provider

• Export or document all existing records before changing nameservers.
• Recreate every required A, AAAA, CNAME, MX, TXT, and SRV record in the new DNS zone first.
• Only then update the domain’s NS records at the registrar.
• Keep a rollback plan in case a critical record was missed.
• Check TTL settings in advance if you want changes to become visible sooner.

Changing NS records is not just another edit. It changes where the entire zone is served from, so preparation matters more than speed.

6. Creating a subdomain for an app or tool

• Decide whether the subdomain points to an IP address or a provider hostname.
• Use an A or AAAA record for direct IP targets, or a CNAME for hostname targets.
• Check whether the service also needs TXT verification.
• Confirm that SSL covers the new subdomain.
• Review whether the subdomain should be isolated in its own DNS zone with delegated NS records.

This comes up often for staging sites, status pages, APIs, and app deployments. For deployment context, see Best App Deployment Platforms for Small Teams and Solo Developers.

What to double-check

Most DNS issues come from small mismatches rather than big conceptual errors. Before saving a record, verify these details:

• Host or name field: Is the record for the root domain, www, or another subdomain?
• Value or target: Did you paste the correct IP address, hostname, or text string?
• Record type: Did you choose A when the provider asked for A, or did you accidentally create TXT or CNAME instead?
• TTL: Lower TTLs can help during migrations, but consistency matters more than chasing instant updates.
• Conflicts: Is there an old record with the same host that would override or conflict with the new one?
• Provider syntax: Some DNS panels automatically append the domain name; others require the full hostname.
• Root domain limitations: If you want to point the apex to another hostname, confirm whether your provider supports alias-style behavior.

After making changes, allow time for caches to expire and verify propagation from more than one network. If you need a refresher on timing, see DNS Propagation Checker Guide: How Long DNS Changes Really Take.

Common mistakes

Knowing the main dns record types is helpful, but avoiding a few predictable errors is what saves time.

Using CNAME where an A record is required

If a provider gives you a direct IP address, use an A or AAAA record. A CNAME is only for pointing to another hostname.

Leaving old MX records in place during an email migration

Mixed MX records can send mail to multiple providers in ways that are hard to troubleshoot. If the migration is complete, remove stale entries.

Editing records in the wrong DNS provider

This happens when the registrar, hosting provider, and CDN all have DNS interfaces. The authoritative nameservers determine where edits must be made.

Forgetting about the root domain and www

These are separate hostnames in many setups. One can work while the other fails.

Breaking email authentication while changing web hosting

Website changes usually affect A, AAAA, or CNAME records. Email depends on MX and TXT records. Review all service-related records before deleting anything that looks unfamiliar.

Assuming propagation is the only problem

Propagation does matter, but many issues are simply misconfiguration. If a record is wrong, waiting longer will not fix it.

When to revisit

DNS should not be treated as a one-time setup. Revisit your records any time the underlying service map changes, especially in these moments:

• Before migrating to new cloud web hosting or managed hosting
• Before changing registrars, nameservers, or CDN providers
• When switching email platforms
• When launching a new subdomain, app, or regional site
• When adding verification for analytics, SEO, or security tools
• When seasonal planning or release cycles introduce new platforms and workflows
• When you inherit a domain with undocumented records

A practical habit is to maintain a simple DNS inventory with five fields: host, record type, value, purpose, and owner. That turns DNS from tribal knowledge into an operational checklist. Before any change, compare the provider instructions against that inventory, reduce TTLs if appropriate, take screenshots or exports, and test after each step rather than batching everything at once.

If you want one final reusable action list, use this:

1. Identify the service you are connecting.
2. Confirm the exact DNS record type required.
3. Document the current record before editing.
4. Check for conflicts on the same host.
5. Apply the change in the authoritative DNS provider.
6. Wait, verify, and test the actual service—not just the record.
7. Update your DNS inventory so the next change is easier.

That process is simple, but it prevents most avoidable DNS problems. And because domains, providers, and workflows change over time, it is worth coming back to these record definitions whenever you are connecting something new.