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

Overview

If you have ever bought a domain name, pointed it to a host, or configured email, you have already used DNS whether you meant to or not. DNS, or the Domain Name System, maps human-friendly names like example.com to the services that actually answer requests.

The easiest way to think about DNS records is this: each record type answers a different question.

• A record: Which IPv4 address should this name use?
• AAAA record: Which IPv6 address should this name use?
• CNAME record: Is this name an alias of another hostname?
• MX record: Which servers handle email for this domain?
• TXT record: What text-based instructions or proofs should be attached to this name?
• NS record: Which nameservers are authoritative for this zone?
• SRV record: Which host and port provide a specific service?

That sounds simple, but DNS problems usually come from using the right record in the wrong place, mixing providers, or updating one layer of DNS while forgetting another. A domain may be registered at one company, use nameservers from another, point web traffic to a third, and route email through a fourth. That is why it helps to treat DNS as a system rather than as isolated entries.

Before editing anything, confirm three basics:

1. Where the DNS zone is actually hosted. Your registrar may not be the place where you edit records. If your domain uses third-party nameservers, that third party is usually where DNS changes belong.
2. Which hostname you are changing. The root domain, often shown as @, is not the same as www, mail, or app.
3. What the destination service expects. Hosts, email providers, and website builders usually publish exact values. Follow those values literally, including dots, priorities, or verification strings.

A quick note on nameservers vs DNS records: nameservers tell the internet which DNS provider is authoritative for your domain, while DNS records are the actual instructions inside that DNS zone. Confusing these two is one of the most common causes of failed setups.

If you are still choosing a registrar or reviewing how your domain is billed over time, it is worth reading Best Domain Registrars Compared: Pricing, Privacy, Transfers, and Renewal Fees and Domain Name Cost Guide: Registration, Renewal, Transfer, and Hidden Fees before making changes that might tie you to a provider.

A record

An A record points a hostname to an IPv4 address, such as 203.0.113.10. This is still the most common record used to connect a domain or subdomain to a web server.

Use an A record when your hosting provider gives you a specific IPv4 address for your site, app, or service. A typical example is pointing the root domain example.com to a shared hosting account or VPS.

Typical use: root domain to web server.

Common mistake: entering an IP address into a CNAME field, or adding an A record for the wrong hostname.

AAAA record

An AAAA record works like an A record, but for IPv6 addresses. If your host supports IPv6, you may be asked to add one alongside your A record.

Typical use: enabling IPv6 access to a website or service.

Common mistake: publishing an outdated IPv6 address after a migration, which can create inconsistent behavior for some visitors.

CNAME record

A CNAME record makes one hostname an alias of another hostname. For example, www.example.com may be a CNAME to example.hostingplatform.com.

CNAME is commonly used for subdomains and works well when the destination provider may change underlying IPs. It is often the preferred method for website builders, SaaS tools, and CDN-related subdomains.

Typical use: point www, blog, or shop to another hostname.

Common mistake: trying to place a CNAME at the root domain when your DNS provider does not support that pattern.

MX record

MX records define which mail servers receive email for your domain. They include both a target hostname and a priority value. Lower priority numbers are usually preferred first.

If you use email hosting for a custom domain, your provider will usually give you two or more MX entries plus supporting TXT records for authentication.

Typical use: route email for @example.com to your mail provider.

Common mistake: forgetting to remove old MX records during a migration, causing mail to be split or delivered unpredictably.

TXT record

TXT records store text values used for verification and email authentication. They are extremely common in modern DNS. You will often use them for SPF, DKIM, DMARC, domain ownership checks, and third-party service verification.

Typical use: verify a domain with an external service or publish anti-spoofing email policy.

Common mistake: adding duplicate SPF records instead of maintaining a single valid SPF policy.

NS record

NS records specify which nameservers are authoritative for the zone. At the registrar level, changing nameservers usually hands control of your DNS to another provider.

Typical use: delegate DNS to a hosting company, managed DNS provider, or security platform.

Common mistake: changing nameservers without recreating existing records first.

SRV record

SRV records identify the host and port for a specific service, along with priority and weight. They are less common in simple website setups but still matter for some communication platforms, directory services, and application protocols.

Typical use: service discovery for apps that need more than just a hostname.

Common mistake: incorrect formatting of service name, protocol, port, or target.

Checklist by scenario

Use this section as a working checklist before you edit DNS. The goal is not just to know what each record means, but to know which one to reach for in a real setup.

Scenario 1: Point a domain to a web host

1. Confirm whether you are connecting the root domain, www, or both.
2. Check whether your host gave you an IP address or a hostname.
3. If you received an IPv4 address, use an A record.
4. If you received an IPv6 address, add an AAAA record if appropriate.
5. If you received a hostname for a subdomain like www, use a CNAME.
6. Make sure www and the root domain both resolve in a way that matches your preferred site URL.
7. Verify SSL after DNS settles, because certificate issuance often depends on correct DNS routing.

If you are at the beginning of that process, How to Buy a Domain Name: Beginner Checklist Before You Register and Best Domain Extensions for Business, Blogs, Stores, and Personal Sites can help with the earlier naming and setup choices.

Scenario 2: Connect a domain to a website builder or SaaS platform

1. Read the provider instructions carefully; these setups often require a mix of A, CNAME, and sometimes TXT verification records.
2. Check whether the provider wants the root domain pointed directly or only wants www connected.
3. Do not leave old records in place if the provider says to replace them.
4. After adding records, confirm that redirects between example.com and www.example.com behave as intended.

This is a common case where a user thinks they need to change nameservers, but in many setups they only need to add or update a few DNS records.

Scenario 3: Set up email for a custom domain

1. Add the exact MX records supplied by your email host.
2. Add all required TXT records for verification and email authentication.
3. Check whether the provider expects a single SPF record or asks you to merge mechanisms into an existing one.
4. Remove old MX entries if you are replacing a previous mail provider.
5. Test both inbound and outbound email after changes propagate.

For many teams, email trouble comes less from MX alone and more from incomplete TXT configuration. If a provider gives you MX, SPF, DKIM, and DMARC instructions, treat them as one package rather than separate tasks.

Scenario 4: Move DNS to a new provider

1. Export or document all current records before making any change.
2. Recreate the full DNS zone at the new provider first.
3. Double-check less obvious entries such as TXT, SRV, and service-specific subdomains.
4. Only then update your NS records or nameservers at the registrar.
5. Monitor website, email, and verification services after the cutover.

This is the safest way to avoid a silent outage where the website works but email breaks, or where a forgotten verification record interrupts a third-party service.

Scenario 5: Troubleshoot a DNS issue

1. Confirm which DNS provider is authoritative now.
2. Check the exact hostname that fails.
3. Compare your live records with the provider's expected values.
4. Look for duplicate or conflicting records, especially mixed A and CNAME entries on the same name where unsupported.
5. Allow for propagation time, but do not use propagation as a catch-all explanation for a wrong value.
6. Test from more than one resolver if results appear inconsistent.

What to double-check

These details are easy to overlook and are often the difference between a clean setup and an afternoon of troubleshooting.

Hostnames and record names

A record entered for @ affects the root domain. A record entered for www affects only www.example.com. Many mistakes come from updating the wrong label.

TTL values

TTL, or time to live, controls how long resolvers may cache a record. Lower TTLs can help before a planned migration, while higher TTLs can reduce query traffic in stable setups. TTL does not fix incorrect values, but it does influence how quickly changes are seen.

Priority on MX and SRV records

MX and SRV records often rely on priority values. If your provider specifies them, use those values exactly. A correct target with the wrong priority may still create delivery or routing issues.

Root domain limitations

Some DNS providers do not allow a plain CNAME at the zone apex, meaning the root domain. If a service asks for a CNAME at the root, check whether your DNS provider offers an aliasing feature for apex records or whether the service provides an A/AAAA alternative.

Trailing dots and formatting

Different DNS interfaces display or handle hostnames differently. Some add the domain automatically, some expect a fully qualified name, and some tolerate both. If a record resolves to an unexpected doubled name, formatting may be the reason.

Mail authentication records

When setting up email, check whether SPF, DKIM, and DMARC are all present and syntactically valid. A working MX record alone does not guarantee healthy outbound delivery or proper spoofing resistance.

Conflicting legacy records

Old records are often left behind during migrations. Remove entries you no longer need once the new service is confirmed. This matters most for MX, TXT verification records, and stale subdomain aliases.

Common mistakes

Most DNS problems are not exotic. They are usually ordinary configuration mismatches.

• Changing nameservers instead of records. If a service only asks for an A or CNAME record, switching nameservers can move the whole zone unexpectedly.
• Editing DNS at the registrar when DNS is hosted elsewhere. The interface may accept the change, but it will have no effect if the domain uses third-party nameservers.
• Using multiple SPF TXT records. In many cases, SPF should be a single consolidated policy, not several separate records.
• Leaving old MX records active. This can split inbound mail between old and new providers.
• Putting a CNAME where another record already exists on the same name. Many DNS systems do not allow that combination.
• Ignoring IPv6. If an old AAAA record remains while your A record was updated, some users may still hit the wrong server.
• Assuming propagation is the only issue. A typo, wrong hostname, or bad priority value will not fix itself with time.
• Skipping a record inventory before migration. The website may survive, but forgotten TXT or SRV entries can break email or app integrations.

If you are planning a registrar move as part of cleanup, review the administrative side as well as the DNS side. Articles like Best Domain Registrars Compared: Pricing, Privacy, Transfers, and Renewal Fees can help you think through portability, while Domain Name Cost Guide: Registration, Renewal, Transfer, and Hidden Fees helps you avoid solving a technical problem by creating a billing one.

When to revisit

DNS should not be edited casually, but it should be reviewed on a schedule and whenever the underlying service changes. A short recurring checklist prevents slow drift and forgotten dependencies.

Revisit your DNS records in these situations:

• Before moving hosting providers. Confirm whether your A, AAAA, or CNAME records will change.
• Before switching email platforms. Stage MX and TXT changes carefully to avoid mail loss.
• Before changing nameservers. Rebuild the zone elsewhere before delegation changes.
• When launching a new subdomain. Decide whether it should use A, AAAA, CNAME, or a service-specific record set.
• When SSL issuance fails. DNS mismatches are often part of the problem.
• When verification breaks for a third-party tool. Recheck TXT records and expiration of old assumptions.
• During routine maintenance. Review legacy records, stale subdomains, and mail authentication entries at least periodically.

A practical review routine looks like this:

1. List every active hostname you care about: root, www, mail, app, blog, shop, support, and any API or staging names.
2. For each one, document the expected destination and record type.
3. Compare your current zone against that expected state.
4. Remove records that are clearly obsolete only after confirming they are unused.
5. Test website, email, and third-party integrations after each meaningful DNS change.

If you do that consistently, DNS becomes less mysterious. It turns back into what it should be: a small, clear map of where each part of your domain is supposed to go.

Keep this page as a reference whenever you need to answer three questions: what kind of service am I connecting, which hostname am I changing, and which record type matches that job? That framing alone resolves a surprising number of DNS issues before they start.