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

Overview

If you manage a domain, DNS is the control panel behind your website, email, and many third-party services. When someone types your domain into a browser, sends mail to your team, or verifies ownership with a SaaS platform, DNS tells the internet where that request should go.

The challenge is not just knowing the names of the records. It is knowing when to use each one, what it can safely point to, and what should be left alone. A small DNS change can fix a launch in minutes—or break email for a full workday if you overwrite the wrong record.

Here is the short version:

• A record: points a hostname to an IPv4 address.
• CNAME record: points one hostname to another hostname.
• MX record: tells email where to be delivered for your domain.
• TXT record: stores text used for verification, email authentication, and policy signals.
• NS record: defines which nameservers are authoritative for the domain or a delegated subdomain.

Think of them as different routing instructions. They are not interchangeable, even when a dashboard makes them look similar.

Before editing anything, keep three principles in mind:

1. Know the exact hostname you are editing. The root domain, www, and subdomains like app or mail are separate DNS names.
2. Know which service owns the destination. Your website host, cloud load balancer, email provider, and CDN may all require different records.
3. Check the full set of existing records first. DNS errors often happen because a new record replaces an older one that was still needed.

If you are still connecting a new domain to hosting, see How to Connect a Domain to Your Website: DNS Steps for Any Host. If your DNS work is part of a move between providers, pair this guide with Website Migration Checklist: Moving Your Site to a New Host Without Breaking SEO.

A record: when you have an IP address

Use an A record when a hostname should resolve directly to an IPv4 address. This is common when your root domain points to a web server, VPS, or load balancer with a fixed public IP.

Typical use: example.com -> 203.0.113.10

Choose an A record when your provider gives you an IP and explicitly tells you to point the domain there. This is common with traditional web hosting, some cloud hosting environments, and certain self-managed deployments.

Good fit for:

• Root domain pointing to a server IP
• Subdomain pointing to a dedicated service IP
• Simple website setups without hostname-based routing requirements

Watch for: If the provider may change the backend IP, a CNAME or provider-managed alias may be safer for subdomains.

CNAME record: when you have a hostname

Use a CNAME when one hostname should point to another hostname rather than an IP address. This is common for www, app subdomains, SaaS integrations, and CDN endpoints.

Typical use: www.example.com -> example.hostingplatform.com

This is the core of the “A record vs CNAME” decision: if the destination is an IP, use A; if the destination is another hostname, use CNAME.

Good fit for:

• www pointing to a hosting platform endpoint
• Subdomains such as shop, blog, or app pointing to external services
• Service-specific setups where the provider manages failover behind a hostname

Watch for: A CNAME generally should not coexist with other record types at the same hostname. If blog.example.com has a CNAME, do not also place TXT, A, or MX records on that exact same name unless your DNS provider explicitly supports a special-case feature.

MX record: when you want email to arrive

MX records tell other mail servers where to deliver email for your domain. If you use business email, your provider will supply one or more MX entries, often with priority values.

Typical use: mail for @example.com goes to the mail servers defined in MX records.

Good fit for:

• Google Workspace, Microsoft 365, Zoho Mail, Fastmail, and similar providers
• Custom email hosting for business domains
• Any domain receiving mail at its own address

Watch for: MX records do not make mail secure or authenticated on their own. They only route delivery. You usually also need TXT records for SPF, DKIM, and sometimes DMARC policy.

TXT record: when a service asks you to verify or publish a policy

TXT records are flexible and widely used. They often prove domain ownership, publish email authentication rules, or store provider-specific metadata.

Common uses:

• Domain verification for SaaS tools
• SPF email policy
• DKIM public keys
• DMARC policy
• Various platform-specific checks

Good fit for:

• Proving you control a domain before using a platform
• Improving email delivery and reducing spoofing risk
• Publishing machine-readable rules without changing web routing

Watch for: TXT record names can be unintuitive. Some providers want the record at the root, some under a subdomain, and some under names like _dmarc or selector._domainkey. Copy the host field carefully.

NS record: when you delegate DNS authority

NS records define which nameservers are authoritative for a domain. At the registrar level, they decide which DNS provider controls the whole zone. Within a zone, they can also delegate a subdomain to another DNS setup.

Good fit for:

• Pointing your domain to your DNS provider's nameservers
• Moving DNS hosting from one provider to another
• Delegating a subdomain like dev.example.com to a separate environment

Watch for: Changing nameservers is a bigger move than editing a single record. It can affect the entire DNS zone if the destination provider does not already contain all required records.

Checklist by scenario

Use this section as your working reference before making changes. Start with the scenario, then verify the exact record type and hostname.

1. Point a website to a server or host

• If your host gives you an IP address, use an A record.
• If your host gives you a target hostname, use a CNAME for the relevant subdomain.
• If you want both example.com and www.example.com to work, decide which is primary and redirect the other at the web server or platform level.
• Do not assume the root and www are automatically linked. They usually need separate DNS entries.

For a full domain-to-hosting walkthrough, see How to Connect a Domain to Your Website: DNS Steps for Any Host.

2. Add business email to your domain

• Add the MX records exactly as your email provider specifies.
• Add any required TXT records for SPF, DKIM, and DMARC.
• Remove obsolete MX records from previous providers unless you intentionally run a mixed setup.
• Test both inbound and outbound email after changes.

If you are evaluating hosting bundles that include mail, review the tradeoffs in your broader infrastructure choices, not just the DNS screen. Related planning articles include Best Hosting for Small Business Websites: What to Look for Before You Buy and Shared Hosting vs VPS vs Cloud Hosting: Which Should You Choose in 2026?.

3. Verify a domain with a third-party service

• Most services use a TXT record.
• Some use a CNAME for verification or branded services.
• Confirm whether the record belongs at the root or at a specific subdomain.
• Keep existing records unless the provider explicitly tells you to replace one.

This is where many TXT record verification issues come from: the value is correct, but the hostname is wrong.

4. Set up a subdomain for an app, shop, or support center

• If the provider gives a hostname target, use a CNAME.
• If it gives a fixed IP, use an A record.
• Do not place unrelated records on the exact same hostname if you use CNAME there.
• Document who owns the subdomain and where it points.

5. Move DNS to a new provider

• Export or inventory all current records first.
• Recreate A, CNAME, MX, TXT, and any other active records at the new provider before changing NS.
• Lower TTL values in advance if you expect a cutover and your current provider allows it.
• Change the registrar nameservers only after the new zone is complete.

If this DNS move is part of a domain change, bookmark Domain Transfer Checklist: How to Move a Domain Without Downtime or Lost Email.

6. Launch a WordPress or business site on a new host

• Confirm whether the host expects an A record, CNAME, or nameserver change.
• Make sure SSL provisioning is compatible with the hostname you point.
• Check whether email remains elsewhere; website hosting and email hosting do not need to be with the same provider.
• Preserve any TXT records used for verification, SPF, DKIM, or DMARC.

Related reading: Managed WordPress Hosting vs Standard Web Hosting: Features, Speed, and Cost Tradeoffs and Web Hosting Pricing Guide: What You Really Pay for Storage, Bandwidth, Backups, and SSL.

What to double-check

Most DNS issues are not caused by a lack of knowledge about record types. They come from small implementation errors. Before saving a change, run through this checklist.

• Hostname vs full domain: Some control panels want www; others want www.example.com. Enter the format your DNS provider expects.
• Root domain vs subdomain: A record changes at the root do not automatically update www, mail, or app.
• Trailing dots and auto-appended domains: DNS panels vary. If you paste a full hostname into a field that auto-appends your zone, you may create the wrong target.
• TTL value: A shorter TTL can help during planned changes, but once stable, a more relaxed TTL may reduce repeated lookups. Use your provider's guidance and your operational needs.
• Existing mail setup: Before editing MX or TXT records, confirm what currently handles inbound mail and what sends outbound mail.
• Conflicts at the same name: A CNAME at a hostname often blocks other record types there.
• Provider instructions: DNS providers and application vendors label fields differently. Read the host, type, value, and priority requirements as separate inputs.
• Propagation expectations: Some changes appear quickly, but caches can delay what different networks see. Verify from more than one location or tool before assuming failure.

If you are also reviewing security settings before launch, a useful companion is WHOIS Privacy and Domain Protection: What to Enable Before You Launch.

Common mistakes

This is the section to skim when something should work but does not.

Using a CNAME at the wrong place

One of the most common DNS record type mistakes is adding a CNAME where a root-domain A record or provider-supported alias is required. Many hosting dashboards assume users know the difference, but the destination format usually tells you: IP means A record; hostname means CNAME.

Replacing MX records by accident

When setting up a website, some users switch nameservers or import a new zone and forget to carry over existing MX records. The site comes online, but email stops arriving. Always inventory mail records before broader DNS changes.

Adding duplicate or conflicting TXT records

TXT records are easy to accumulate over time. Old verification values may be harmless, but email authentication records deserve closer review. If multiple SPF records exist as separate TXT entries for the same hostname, mail handling may become unreliable. Keep them intentional and documented.

Editing the wrong DNS provider

If your registrar points the domain to third-party nameservers, editing records at the registrar's default DNS panel may do nothing. Confirm which nameservers are authoritative before troubleshooting the record itself.

Expecting DNS alone to handle redirects

DNS points names to destinations; it usually does not perform URL redirects like sending example.com to www.example.com/shop. That behavior is typically handled by your web server, application, CDN, or hosting platform.

Forgetting that migrations affect more than the website

DNS changes during a host migration can touch analytics verification, transactional email, support tools, staging environments, and CDN settings. If your move is broader than a single A record update, use a structured migration plan such as Website Migration Checklist: Moving Your Site to a New Host Without Breaking SEO.

When to revisit

DNS is not a set-it-and-forget-it task. This is the practical review schedule that keeps small record sprawl from becoming a launch-day problem.

• Before launching a new site or subdomain: confirm the correct A or CNAME records, SSL readiness, and whether www and the root behave as intended.
• Before changing hosts: inventory all existing records, especially MX and TXT entries tied to email and verification.
• Before switching email providers: review MX, SPF, DKIM, and DMARC together rather than one at a time.
• Before seasonal planning cycles or campaigns: check landing pages, tracking-related subdomains, and third-party verification records.
• When workflows or tools change: remove stale verification records and document new dependencies.
• After a domain transfer or nameserver change: compare the live zone against your expected record list and test website, email, and key integrations.

A simple ongoing process works well:

1. Create a DNS inventory with columns for hostname, record type, value, owner, and purpose.
2. Label critical records: website, email, CDN, verification, security, and delegated subdomains.
3. Review the inventory before every infrastructure change.
4. Delete only after confirming a record is no longer needed.
5. Retest website resolution, email flow, and service verification after updates.

If you are still at the domain-planning stage, it also helps to align DNS choices with the domain itself. See How to Choose a Domain Name for Your Business and Best Domain Extensions for Businesses, Startups, Portfolios, and Online Stores.

The most useful habit is simple: treat DNS as infrastructure, not just a settings page. When you know which record type solves which problem, changes become predictable. Use A for IPs, CNAME for hostnames, MX for mail routing, TXT for verification and policy, and NS for DNS authority. Then document every change so the next launch, migration, or verification request is routine instead of risky.