DNS Records Explained: A, CNAME, MX, TXT, NS, AAAA, and When to Use Each

Overview

This article gives you a working reference for the DNS record types most site owners, developers, and IT admins use regularly. Instead of listing definitions only, it focuses on when to use each record, where people get stuck, and what to verify before saving changes.

At a high level, DNS translates human-readable domain names into the destinations and services your systems need. Some records point traffic to a web server. Some tell the internet where to deliver mail. Some verify ownership, support email security, or delegate control to another DNS provider.

Here is the short version:

• 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 mail systems where to deliver email for a domain.
• TXT record: stores text-based instructions or verification data, often for email DNS records and domain verification.
• NS record: defines which nameservers are authoritative for the domain or a delegated subdomain.

If you manage domain registration and web hosting in different places, DNS becomes the bridge between them. That is why changes to hosting, email providers, SSL validation, CDN setup, and website migration often start with the DNS zone.

A record

Use an A record when you need a hostname such as example.com or app.example.com to resolve directly to an IPv4 address. This is common when connecting a domain to shared hosting, VPS hosting, cloud hosting, or a dedicated application server.

Typical use: Point the root domain or a subdomain to a server IP.

Example: example.com -> 203.0.113.10

An A record is often the right choice when your host gives you a fixed IPv4 address and tells you to point the domain there.

AAAA record

An AAAA record works like an A record, but for IPv6. If your hosting environment supports IPv6, you may add AAAA records alongside A records.

Typical use: Publish IPv6 connectivity for a website or service.

Example: example.com -> 2001:db8::10

If you do not actively use IPv6, do not add AAAA records casually. A wrong IPv6 record can break reachability for visitors whose networks prefer IPv6.

CNAME record

A CNAME points one hostname to another hostname rather than to an IP address. It is useful when a service asks you to point a subdomain to a target they manage, such as a CDN, SaaS platform, or hosted app.

Typical use: Point www.example.com to hosting.provider.net.

Important rule: A CNAME generally should not coexist with other record types on the same hostname. It is also commonly restricted at the root domain, depending on your DNS provider.

This is the core of the common a record vs cname decision: use an A record when you have an IP address; use a CNAME when you are aliasing one hostname to another.

MX record

An MX record defines where incoming email for your domain should go. If your website is hosted with one provider and your email with another, your A or CNAME records may change without touching MX at all.

Typical use: Route email for @example.com to a business email hosting service.

Important rule: MX records point to hostnames, not IP addresses, and those hostnames should resolve correctly.

When people break email during a website migration, it is often because they changed nameservers or replaced the zone without re-adding the existing MX records.

TXT record

TXT records are flexible and widely used. You will often see them for domain verification, SPF, DKIM, DMARC, site ownership checks, and some SSL certificate validation workflows.

Typical use: Add proof that you control the domain, or publish email authentication rules.

Examples: SPF policy, DKIM public key, DMARC policy, verification token from a cloud provider.

Because TXT is so broadly used, it is one of the most important entries in any dns records explained reference. It is also one of the most frequently misconfigured records because small formatting mistakes matter.

NS record

NS records tell the internet which nameservers are authoritative for your domain. If you use your domain registrar for domain registration but a separate DNS host for DNS management, the NS records are what delegate authority.

Typical use: Point the whole domain to a DNS provider, or delegate a subdomain to another DNS service.

Important rule: Changing NS records is not the same as editing one record in your zone. It changes where the entire zone is managed.

This is why nameserver changes deserve extra care during a transfer domain process, a hosting migration, or a move to a new DNS platform. If you are preparing a broader change, see How to Connect a Domain to Web Hosting: DNS Steps for Every Setup.

Checklist by scenario

This section gives you a reusable checklist for the situations where specific DNS record types matter most.

1. Pointing a website to a hosting server

• Confirm whether your host provided an IPv4 address, an IPv6 address, or a target hostname.
• Use an A record for IPv4.
• Use an AAAA record for IPv6 only if you know the address is correct and active.
• Use a CNAME record if the provider instructs you to point a subdomain to another hostname.
• Decide how www should behave. Many setups point www via CNAME and the root domain via A record.
• Check whether existing MX, TXT, or other subdomain records must remain untouched.

If you are comparing infrastructure before you point anything, these guides may help: Shared Hosting vs VPS vs Cloud Hosting and Best Hosting for Small Business Websites.

2. Connecting a subdomain to an app or SaaS platform

• Verify the exact hostname the service expects, such as shop.example.com or help.example.com.
• Use a CNAME if the provider gives you a canonical target hostname.
• Make sure that hostname does not already have conflicting A, AAAA, TXT, or MX records.
• Check whether the service also requires a TXT record for verification.
• After propagation, test both DNS resolution and the application itself.

This scenario is where many people ask about a record vs cname. If the provider gives you an alias target, CNAME is usually the right tool for that subdomain.

3. Setting up business email hosting

• Collect the full mail setup from your email provider before making any changes.
• Add or replace the required MX records.
• Add all required TXT records for SPF, DKIM, domain verification, and DMARC if recommended.
• Do not remove website-related A or CNAME records unless the provider explicitly says to.
• Check whether your provider uses special subdomains for DKIM selectors.
• Test inbound and outbound mail after the change.

In practice, mx record and txt record dns changes often travel together. Mail delivery may appear to work before authentication is fully correct, so do not stop at basic sending and receiving tests.

4. Migrating a website without breaking email

• Export or document the current DNS zone before editing anything.
• Identify records related to the website separately from records related to email.
• Update only the web-facing A, AAAA, or CNAME records first.
• Keep existing MX and TXT mail records unless your email provider is changing too.
• Review SSL validation method if a certificate must be reissued.
• Test site response, redirects, forms, and mail flow after the cutover.

If the move involves WordPress, use WordPress Migration Checklist: Move Your Site Without Breaking SEO or Email as a companion.

5. Changing DNS providers or nameservers

• Understand that NS records move authority for the zone.
• Recreate the full zone at the new provider before changing nameservers.
• Confirm every critical record: A, AAAA, CNAME, MX, TXT, and any service-specific entries.
• Lower TTL values in advance if your workflow allows and timing matters.
• Change nameservers only after the new zone is complete.
• Monitor the website, mail, and third-party service verification after the switch.

This is also relevant if you are working through a registrar change. See Domain Transfer Checklist: How to Move a Domain Without Downtime and Domain Renewal Guide for adjacent operational details.

6. Publishing email authentication records

• Add or verify your SPF record as a TXT record.
• Add DKIM selector records exactly as provided, usually as TXT under a subdomain.
• Add a DMARC TXT record at the correct hostname.
• Check for formatting errors, missing semicolons, duplicate SPF entries, or wrong hostnames.
• Test with real mail flows after publishing.

For many domains, these records matter just as much as the mx record itself because they influence trust and delivery quality.

7. Verifying domain ownership for a service

• Read whether the provider wants a TXT, CNAME, or less commonly another record type.
• Add the record exactly as shown, including the correct host or name field.
• Keep the record in place until verification completes, and sometimes longer if the service requires it.
• Avoid editing quotation marks, spaces, or split values unless your DNS panel handles them automatically.

What to double-check

Before you click save, run through this short review. Most DNS problems come from a small mismatch rather than a complex technical failure.

• Correct hostname: Are you editing the root domain, www, or a specific subdomain?
• Correct record type: Did the provider ask for A, AAAA, CNAME, MX, TXT, or NS?
• Correct destination: IP address for A/AAAA, hostname for CNAME and MX, exact text for TXT.
• No conflicts: Is there already a record on that hostname that would conflict, especially with CNAME?
• Mail safety: If you are changing web hosting, did you preserve existing MX and email authentication records?
• TTL awareness: Do you understand that cached values may linger for some time after changes?
• Provider syntax: Does your DNS panel expect a bare hostname, full domain, or symbol like @ for the root?

It also helps to keep a plain-text copy of the old zone before any change. That habit reduces risk during migrations and makes rollback much easier.

Common mistakes

This section highlights the errors that repeatedly cause downtime, email disruption, or verification failures.

Using CNAME at the wrong place

A common mistake in the a record vs cname decision is using CNAME where an A record is required, or placing a CNAME on a hostname that already has other records. This often breaks not just web resolution but any other service using that same hostname.

Pointing MX to an IP address

MX records should point to a mail hostname, not directly to an IP address. If the target hostname does not resolve properly, mail delivery can fail even if the MX line itself appears to be present.

Overwriting email records during a web migration

When people connect domain to hosting, they sometimes replace the full zone with a basic template from the web host. That can remove MX, SPF, DKIM, and DMARC records. The website comes back, but email quietly stops working or loses authentication.

Adding a wrong AAAA record

If an incorrect IPv6 record exists, some users may be routed to the wrong destination even when the IPv4 A record is correct. Only publish AAAA records you actively intend to support.

Formatting TXT records incorrectly

TXT records are unforgiving. Problems include missing characters, duplicate SPF policies, wrong selector names for DKIM, and publishing DMARC on the wrong hostname.

Changing nameservers before rebuilding the zone

NS changes should be treated as a full DNS migration, not a single edit. If the new provider does not already have the complete zone, critical services may disappear after the delegation changes.

Ignoring registrar and DNS separation

Your domain registrar, DNS host, web hosting provider, and email provider may all be different companies. Confusing these roles leads to edits in the wrong control panel. If you recently completed domain registration, domain renewal, or a transfer, confirm where authoritative DNS is actually managed before you make any changes.

When to revisit

DNS is not a one-time setup. Revisit your records whenever the underlying services or workflows change. A short review at the right time can prevent avoidable downtime.

Review your DNS records in these situations:

• Before moving to new web hosting, cloud hosting, or VPS hosting.
• Before switching business email hosting providers.
• Before changing nameservers or DNS management platforms.
• Before a WordPress migration or major launch.
• When adding a CDN, security layer, SaaS app, or external service on a subdomain.
• When reissuing certificates or changing SSL validation methods.
• During seasonal planning cycles, launch windows, or infrastructure cleanup.
• Any time you notice email delivery problems, SSL warnings, or unexpected site routing.

A practical review routine looks like this:

1. List every active service tied to the domain: website, email, CDN, analytics verification, support tools, marketing platforms, and security tools.
2. Map each service to the DNS record types it depends on.
3. Export or document the current zone.
4. Remove only records you can confidently identify as obsolete.
5. Test resolution, website behavior, SSL status, and mail flow after changes.

If your stack is evolving, it is also worth reviewing related operational topics such as WordPress Hosting Comparison Guide and Whois Privacy vs Domain Ownership Transparency.

The goal is not to memorize every DNS detail. It is to know which record type solves which problem, and to have a checklist you trust before you edit live settings. If you keep that discipline, the main DNS record types—A, CNAME, MX, TXT, NS, and AAAA—become much easier to manage with confidence.