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

Overview

At a basic level, DNS is the system that tells the internet where to send traffic for your domain. When someone types your domain into a browser, sends email to your address, or a tool checks ownership of your site, DNS records provide the instructions.

The reason DNS causes so much confusion is that the records are simple in isolation but easy to mix up in real setups. A website might use an A record at the root domain, a CNAME for www, MX records for email, TXT records for verification and sender authentication, and NS records if DNS is hosted somewhere else entirely.

Here is the short version:

• A record: points a name to an IPv4 address.
• CNAME record: points one hostname to another hostname.
• MX record: tells email where inbound mail should go.
• TXT record: stores text used for verification, email authentication, and other settings.
• NS record: defines which nameservers are authoritative for the domain.

If you remember only one principle, make it this: every DNS record should have one job, and you should know which provider is responsible for that job before editing anything.

A record: when you need a direct IP address

An A record connects a hostname to an IPv4 address. It is commonly used to point a domain or subdomain to a web server.

Typical use cases:

• Pointing example.com to a hosting server IP
• Pointing a subdomain like shop.example.com to a specific server
• Routing traffic to a static infrastructure endpoint

Use an A record when your hosting provider gives you a specific IP address and tells you to point the domain there. This is one of the most common setups for traditional hosting, VPS hosting, and some cloud deployments.

CNAME record: when one hostname should follow another

A CNAME record makes one hostname an alias of another hostname. Instead of pointing to an IP directly, it points to a domain name.

Typical use cases:

• Sending www.example.com to example.com or to a platform hostname
• Connecting a subdomain to a website builder or SaaS product
• Managing services that want flexibility behind the scenes without exposing a fixed IP

This is where many readers search for a record vs cname. The practical difference is simple: use an A record when you have an IP address, and use a CNAME when the provider gives you another hostname.

One important limitation: the root domain often has special rules and, depending on your DNS provider, may not support a standard CNAME the way subdomains do. Some providers offer alternatives such as flattened or alias-style behavior, but the name and implementation vary. Always follow your DNS provider's documented method for the apex or root domain.

MX record: when you want email to arrive

MX stands for mail exchange. These records tell other mail servers where to deliver incoming email for your domain.

Typical use cases:

• Connecting Google Workspace, Microsoft 365, Zoho Mail, or another business email host
• Moving email from one provider to another
• Separating website hosting from email hosting

MX records do not control your website. They only affect email delivery. That is why website changes can work fine while email fails, and vice versa.

TXT record: verification, SPF, and other text-based settings

TXT records are flexible and widely used. They can prove domain ownership, support email sender authentication, or store other service-specific data.

Typical use cases:

• Domain verification for analytics, search tools, CDNs, and SaaS platforms
• SPF policies for outbound email
• DKIM public keys, depending on provider format
• DMARC policy records, usually published as a TXT record on a special subdomain

If you have ever been asked to paste a token into DNS, you were probably adding a TXT record. This is why txt record verification is such a common task during setup.

NS record: who is in charge of DNS

NS records indicate which nameservers are authoritative for the domain. In practical terms, they answer the question, “Which system holds the active DNS zone?”

Typical use cases:

• Keeping DNS at your domain registrar
• Moving DNS management to your web host, CDN, or specialist DNS provider
• Switching control during a migration

NS changes are high-impact because they can shift your entire DNS zone from one provider to another. If the target nameservers do not contain all the right records, your website, email, and verification records can all break at once.

If you are still deciding how your domain and hosting should work together, our guide on how to buy a domain and hosting together without overpaying is a useful companion before you start editing DNS.

Checklist by scenario

Use this section as a working checklist. Start with the scenario that matches your task, then confirm the record type, target value, and where the change should be made.

1. Pointing a domain to a website host

Usually needed: A record, sometimes CNAME for www

• Find out whether your host gave you an IP address or a hostname.
• If you got an IP address, use an A record.
• If you got a hostname for a subdomain, use a CNAME where appropriate.
• Decide how both example.com and www.example.com should behave.
• Confirm whether redirects are handled in DNS or at the hosting/application layer.
• Check that SSL is provisioned after DNS points correctly.

This is common for shared hosting, VPS, cloud hosting, and many WordPress setups. If you are still evaluating providers, you may want to compare your options in best web hosting for small business websites or best WordPress hosting for beginners, bloggers, and small stores.

2. Connecting a site builder or SaaS platform

Usually needed: CNAME for a subdomain, sometimes A record or provider-specific root domain instructions

• Read the platform's domain connection instructions carefully.
• Check whether the platform wants the root domain, the www subdomain, or both.
• Use the exact target hostname provided.
• Do not leave old conflicting A or CNAME records in place for the same hostname.
• Verify whether the platform requires an additional TXT record for ownership confirmation.

This comes up often when using website builders. If you are comparing platforms before connecting a domain, see best website builders for small business in 2026 and website builder vs WordPress.

3. Setting up business email

Usually needed: MX records, often TXT records too

• Collect the full MX record list from your email provider.
• Enter priority values exactly as given.
• Remove old MX records if the provider instructs you to replace them.
• Add SPF, DKIM, and DMARC-related TXT records if recommended.
• Test inbound and outbound email after propagation.
• Check spam folder placement and authentication results if sending matters to your workflow.

This is the classic mx record setup situation. Be especially careful during migrations, because a site can stay online while email delivery quietly breaks.

4. Verifying a domain with a third-party tool

Usually needed: TXT record, sometimes CNAME

• Copy the verification value exactly, with no extra spaces.
• Confirm the correct host field. Some providers want the root, others a specific subdomain.
• Do not delete the record immediately after verification unless the service explicitly says it is temporary.
• Keep a note of what service the record belongs to.

Search consoles, analytics tools, CDNs, email providers, and marketing platforms often use this method.

5. Moving DNS to a new provider

Usually needed: NS record update at the registrar, plus a complete DNS zone at the new provider

• Export or manually document all existing records before changing nameservers.
• Recreate A, CNAME, MX, TXT, and any other required records at the new DNS provider.
• Only update NS records after the new zone is complete.
• Check email-related records carefully, especially SPF, DKIM, and DMARC.
• Monitor the website and email after the switch.

This is where many avoidable outages happen. A nameserver move is not just one setting change; it is a handoff of authority.

6. Transferring a domain to a new registrar

Usually needed: no record type change by default, but DNS location must be confirmed

• Find out whether DNS is hosted at the current registrar, the web host, a CDN, or another DNS provider.
• Make sure the transfer will not unintentionally replace nameservers.
• Take a complete record backup before the transfer starts.
• Verify that DNS remains unchanged after completion.

A registrar transfer and a DNS change are not the same thing, but they often get mixed together. Before moving a domain, use the domain transfer checklist: how to move a domain without downtime.

What to double-check

Before saving any DNS change, pause and run through these checks. They prevent most routine mistakes.

Know where DNS is actually managed

Your domain registrar may not be the place where active DNS lives. If your nameservers point to a hosting company, CDN, or dedicated DNS provider, changes made elsewhere will do nothing. Check the current nameservers first.

Confirm the host or name field

Different dashboards display hostnames differently. Some expect the full hostname; others want only the relative label such as www or @ for the root. A correct value in the wrong host field is still wrong.

Avoid conflicting records

A hostname should not have a CNAME plus other incompatible records attached to that same label. Conflicts are a common cause of broken integrations.

Check TTL, but do not overthink it

TTL controls how long resolvers may cache a record. Lower TTLs can help before planned changes, but they do not eliminate propagation time or provider caching behavior. For most routine edits, the main priority is accuracy, not chasing the lowest possible TTL.

Copy values exactly

DNS is unforgiving about typos. One missing dot, one extra quote, or one wrong character in a verification token can stop a setup from working. Paste carefully and review before saving.

Keep a record inventory

A simple spreadsheet or text document listing each record, purpose, and service owner is worth maintaining. This becomes especially useful during renewals, redesigns, migrations, or staff handoffs.

For teams building a site from scratch, it also helps to align DNS planning with domain selection and branding. See how to choose a domain name for SEO, branding, and trust.

Common mistakes

Most DNS problems are not advanced technical failures. They are small mismatches between intention and implementation.

Using an A record when the provider asked for a CNAME

If a service gives you a hostname target, use the record type it requested. Substituting an A record because it feels simpler can break failover or future provider-side changes.

Changing nameservers without recreating the zone

This is one of the highest-risk DNS mistakes. If you point the domain to new nameservers before all records are copied, the new provider becomes authoritative immediately, even if the zone is incomplete.

Forgetting that website and email are separate

Switching hosts does not automatically move email, and changing email providers does not automatically affect your website. Treat web and mail as separate systems with separate records.

Deleting verification or authentication TXT records too early

Some records are needed only once, but many should remain in place for ongoing verification or sender reputation. If you are not sure, leave the record until the service documentation clearly says it can be removed.

Editing DNS in the wrong account

Agencies, former employees, hosting migrations, and registrar changes can leave domains spread across multiple vendors. Always verify who controls the active zone before troubleshooting.

Assuming DNS changes are instant everywhere

Some updates appear quickly; others take longer depending on caching and resolver behavior. Plan changes with a buffer, especially for launches, email moves, and live-site migrations.

If your DNS work is part of a broader hosting move, it helps to understand your hosting model first. Our guide to shared vs VPS vs cloud hosting provides the context many site owners need before making infrastructure changes.

When to revisit

DNS is not a one-time setup task. Revisit your records whenever the underlying services or ownership details change. A quick review at the right time can prevent downtime, email failures, and hard-to-trace SEO issues.

Review DNS when:

• You launch a new website or redesign
• You change web hosts or move to a new platform
• You set up or migrate business email hosting
• You add a CDN, security layer, or third-party verification tool
• You transfer the domain to a new registrar
• You notice website downtime, SSL issues, or missing email
• You begin seasonal campaigns and need all web and mail systems working cleanly
• Your team, workflows, or vendors change

A practical DNS review routine:

1. List every active service tied to the domain: website, email, CDN, analytics, search tools, and marketing platforms.
2. Compare that list to your live DNS records.
3. Label each record by purpose so old entries stand out.
4. Remove obsolete records only after confirming they are unused.
5. Document any change you make, including date and reason.

If you are evaluating hosting changes as part of that review, it can also help to understand the longer-term cost side. See web hosting renewal prices compared: what you will actually pay after year one.

The simplest way to think about dns records explained is this: A and CNAME help visitors reach your website, MX helps email reach your inbox, TXT helps services trust your domain, and NS decides which provider is in control. If you know those roles and check them carefully before editing, DNS becomes much easier to manage—and far less intimidating when something needs fixing.