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

Overview

At a basic level, DNS is the system that tells the internet where services for your domain live. When someone visits your site, sends mail to your domain, or a third-party platform asks you to prove ownership, DNS records provide the answer.

For beginners, the fastest way to stay out of trouble is to think of each record type by its job:

• 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 instructions or verification data, often for email authentication or domain ownership checks.
• NS record: defines which name servers are authoritative for the domain or a DNS zone.

If you remember nothing else, remember this: different record types solve different routing problems. DNS issues often happen not because the platform is unreliable, but because the wrong record type was used for the task.

Here is the practical mental model:

• Use A and AAAA when you know the server IP.
• Use CNAME when a service tells you to point one hostname to another hostname.
• Use MX for inbound email delivery.
• Use TXT for verification, SPF, and other text-based policies.
• Use NS only when changing who controls DNS for the domain or a delegated subdomain.

That distinction matters whether you run a small brochure site on shared hosting plans, manage managed WordPress hosting, or move a production app to developer hosting on a VPS or cloud hosting platform.

What each record looks like in plain language

A record example: example.com -> 203.0.113.10. This means requests for the domain should go to that IPv4 address.

AAAA record example: example.com -> 2001:db8::10. Same idea, but for IPv6.

CNAME example: www.example.com -> app.hostplatform.com. This means www is an alias of another hostname.

MX example: example.com -> mail1.provider.com with a priority value. Lower priority numbers are generally preferred first.

TXT example: a verification token from a search engine, SaaS vendor, or an SPF record such as v=spf1 include:mailprovider.com ~all.

NS example: example.com -> ns1.dnsprovider.com and ns2.dnsprovider.com. This tells the domain which DNS provider is in charge.

Another helpful concept is the hostname or name field. DNS entries are usually created for the root domain, often shown as @, or for a subdomain such as www, blog, mail, or shop.

Checklist by scenario

Use this section as a pre-change checklist. Match the scenario to the record type, then confirm the details before you save anything.

1. Pointing a website to a hosting server

Typical records: A, AAAA, sometimes CNAME for www.

If your web hosting provider gives you an IP address, you will usually create an A record for the root domain and may also add an AAAA record if IPv6 is supported. A common pattern is:

• @ - A -> server IPv4 address
• www - CNAME -> example.com or another hostname given by the provider

Checklist:

• Confirm whether the host gave you an IP address or a hostname.
• If it is an IP, use A or AAAA.
• If it is a hostname, use CNAME where allowed.
• Check whether the root domain and www should both resolve.
• Make sure any old A, AAAA, or CNAME entries that conflict are removed.
• Verify the destination is correct before a migration from shared hosting to VPS or cloud hosting.

If you are changing providers, it helps to lower the TTL in advance where possible and keep a copy of the old values. If the move is part of a broader hosting migration, a separate migration checklist is worth following alongside the DNS update.

Related reading: When to Upgrade From Shared Hosting to VPS or Cloud Hosting and Cloud Hosting vs Shared Hosting: Which Is Better for Small Business Websites?.

2. Connecting a subdomain to an external service

Typical record: CNAME.

This is one of the most common DNS tasks. You might point blog.example.com to a hosted CMS, docs.example.com to a documentation tool, or status.example.com to a monitoring platform.

Checklist:

• Confirm the exact hostname you are creating, such as blog or shop.
• Use a CNAME only if the vendor tells you to point to another hostname, not an IP.
• Check whether the platform also needs a TXT record for verification.
• Make sure there is no existing A, AAAA, or TXT conflict on that same hostname where the provider warns against it.
• Confirm SSL support after the DNS change, especially if you expect hosting with free SSL or instant SSL hosting behavior.

3. Setting up business email

Typical records: MX, TXT, sometimes CNAME depending on the mail provider.

MX records are about where incoming mail goes. TXT records are often used for SPF, DKIM, or domain verification, which support deliverability and trust.

Checklist:

• Add all MX records exactly as provided by the email service.
• Preserve the priority values in the correct order.
• Remove old MX records if you are fully switching providers.
• Add any required TXT records for SPF or verification.
• If the provider uses DKIM or other email authentication, copy those records carefully.
• Do not assume your web hosting provider and mail provider are the same system.

This is where beginners often get tripped up. A website can work perfectly while email fails because MX and TXT records were never updated. When someone asks about the “mx record meaning,” the practical answer is simple: it is the record that tells other mail servers where to deliver your domain’s email.

4. Verifying a domain with a third-party platform

Typical record: TXT, occasionally CNAME.

Search tools, SaaS products, certificate providers, and collaboration platforms often ask for a verification record.

Checklist:

• Check whether the provider requires TXT or CNAME.
• Copy the value exactly, including punctuation.
• Confirm the hostname is correct—some verifications use the root domain, others a specific label.
• Leave the record in place if the service says it must remain for ongoing ownership checks.
• Document why the record exists so no one deletes it later.

For many teams, TXT record DNS changes become cluttered over time. Keeping notes is not busywork; it reduces the chance of breaking something during cleanup.

5. Changing DNS providers or delegating a subdomain

Typical record: NS.

NS changes are less frequent and more sensitive because they determine who is authoritative for the zone. You might update NS records when moving domain registration and DNS management to another provider, or when delegating a subdomain to a separate team or service.

Checklist:

• Confirm the new DNS zone is fully populated before changing NS.
• Compare old and new records side by side.
• Update registrar-level name servers only when you are ready for the whole domain to use the new DNS provider.
• Use subdomain delegation carefully if only part of the namespace is moving.
• Keep a rollback plan.

If a broader domain move is involved, see How to Transfer a Domain Name Without Downtime: Step-by-Step Checklist.

6. Supporting IPv6

Typical record: AAAA.

Not every site needs manual IPv6 work, but if your provider gives you an IPv6 address, the AAAA record is the mechanism that publishes it.

Checklist:

• Only add AAAA if the destination service is configured for IPv6.
• Confirm the web server, firewall, and application stack are listening correctly over IPv6.
• Do not publish an AAAA record that points to an address your service is not actually serving from.

This matters for fast web hosting and secure web hosting claims because a misconfigured AAAA record can create intermittent failures that are hard to spot if testing only happens over IPv4.

What to double-check

Before you click save, run through these checks. They prevent the majority of avoidable DNS errors.

Record name and scope

Know whether you are editing the root domain, a subdomain, or a mail-specific hostname. Confusing @ with www is one of the oldest DNS mistakes and still one of the most common.

Record type

Many “DNS records explained” articles stay too abstract here. In practice, the right question is: did the provider give you an IP or a hostname? If it is an IP, use A or AAAA. If it is a hostname, use CNAME where appropriate. If it is for mail delivery, use MX. If it is a token or policy string, use TXT.

TTL expectations

TTL controls how long resolvers may cache the record. A lower TTL can help before a planned cutover, but it does not guarantee instant change everywhere. Treat propagation as a window, not a switch.

Conflicting records

Some hostnames should not have conflicting records. For example, if a hostname is meant to be a CNAME, having other incompatible records on that same name can cause problems depending on the use case and DNS setup. When in doubt, check the provider’s instructions exactly.

Email side effects

Website changes do not automatically preserve mail behavior. Before updating DNS for a site migration, confirm whether any current MX, TXT, or mail-related CNAME records must remain untouched.

Control panel differences

An easy hosting control panel can still label fields differently. One provider may show “Host,” another “Name.” One may require a trailing dot in the target, another may add it automatically. Read the form as carefully as the vendor instructions.

Documentation and rollback

Export the existing zone if possible, or at minimum take screenshots and copy the current records into a working note. This is especially important for business web hosting environments, website hosting for agencies, and multi-service domains with many TXT records.

Common mistakes

The goal here is not to memorize DNS theory. It is to avoid the small operational mistakes that create hours of confusion.

• Using CNAME at the root when the provider expects A or ALIAS-style handling. If the instructions say to use an IP for the apex domain, use an A record.
• Leaving old MX records in place after switching email providers. This can split mail flow or cause inconsistent delivery.
• Replacing all TXT records with a new one. Domains often need multiple TXT records for different services.
• Editing NS records before rebuilding the new zone. This can disconnect live services.
• Publishing AAAA without actual IPv6 support. Some visitors may reach a broken path while others do not.
• Assuming propagation delay means failure. DNS changes can take time to appear across networks and caches.
• Forgetting the www version. A domain may work at the root but fail on www, or the reverse.
• Changing DNS during a broader hosting move without a checklist. DNS, SSL, redirects, email, and application configuration often interact.

Many of these issues show up during web hosting evaluations too. If you are comparing providers, an organized DNS workflow and clear migration guidance are worth weighing alongside pricing and performance. Related reading: Web Hosting Pricing Guide: What Costs Extra and How to Compare Plans Fairly and Best Web Hosting for WordPress Sites: What to Compare Before You Switch.

When to revisit

DNS is not something you set once and forget forever. Revisit your records when the underlying service map changes, especially before periods where downtime would be more costly.

Review DNS when:

• You change web hosting providers or move from shared hosting to cloud hosting.
• You transfer domain registration or switch DNS management providers.
• You adopt a new email service.
• You add a CDN, reverse proxy, security layer, or site acceleration service.
• You launch a new subdomain for an app, docs site, shop, or staging environment.
• You rotate verification methods for a third-party platform.
• You conduct seasonal planning, platform consolidation, or infrastructure cleanup.
• Your workflows or tools change and old records may no longer be needed.

Reusable pre-change checklist:

1. Identify the exact service you are changing: website, email, verification, or DNS authority.
2. List the current records and save a copy.
3. Match the task to the correct record type: A, AAAA, CNAME, MX, TXT, or NS.
4. Confirm the hostname, target value, and any priority setting.
5. Check for conflicting or duplicate records.
6. Decide whether TTL should be adjusted ahead of the change.
7. Make the update in one place only: your authoritative DNS provider.
8. Test the root domain, www, mail flow, and any affected subdomains.
9. Document why the record exists and when it was changed.
10. Schedule a follow-up review after propagation and again during your next planning cycle.

That final step is what turns DNS from a reactive task into a manageable system. Whether you buy domain online for a new project, transfer domain services during a migration, or maintain secure web hosting for production sites, a short DNS review habit can prevent avoidable outages.

If you want one takeaway to keep handy, it is this: choose the record type based on the job, not the interface in front of you. A record vs CNAME, MX record meaning, and TXT record DNS usage all become much simpler once you anchor them to the outcome you need.