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

Overview

If you have ever opened your domain settings and seen a list of record types without much context, you are not alone. DNS can look abstract until you map each record to a real task. In practice, most website owners only need a small set of records, but they need to use the right one in the right place.

Here is the simplest way to think about the main record types:

• A record: points a hostname to an IPv4 address.
• CNAME record: points one hostname to another hostname.
• MX record: tells the internet where to deliver email for your domain.
• TXT record: stores text-based instructions or proof of ownership, often for verification and email authentication.
• NS record: defines which nameservers are authoritative for the domain or a delegated subdomain.
• SRV record: provides service-specific connection details such as host and port for certain apps.

That basic map answers most of the question behind “dns records explained.” The more useful question is when to use each one. For example, if you need to connect a domain to web hosting, the choice is usually between an A record and a CNAME. If you need email to work, you almost always need MX and usually TXT records too. If you are moving DNS management between providers, nameserver records become the key decision.

One more principle makes DNS much easier to manage: a record type is not just a label. It reflects the job the record is designed to do. If you choose the record based on the job, setup becomes much more predictable.

Before you make changes, note your current settings, especially if the domain is already live. DNS updates can affect website uptime, email delivery, and service verification. If you are planning a move, it also helps to understand typical propagation behavior before you start. See How Long Does DNS Propagation Take? A Practical Timeline by Record Type for a practical overview.

Checklist by scenario

Use this section as a working reference. Start with the outcome you want, then match it to the record type and the checks that matter.

1. Point a domain to a website or server

Use: usually an A record for the root domain, and either another A record or a CNAME for subdomains such as www.

Typical use case: you buy domain name and web hosting separately and need to connect them.

• Use an A record when you have a server IP address.
• Use a CNAME when your provider gives you a hostname instead of an IP.
• For the apex or root domain, many DNS providers expect an A record.
• For www, a CNAME to the root domain or to a provider hostname is common.

Quick checklist:

• Confirm whether your hosting provider gave you an IP address or a target hostname.
• Decide which hostnames should work: root domain, www, or both.
• Add the A record for the root if needed.
• Add the www CNAME if needed.
• Check your web server or hosting control panel so it knows the domain is attached.
• Test both versions in a browser after propagation.

This is the most common setup for domain and hosting, especially for a new business website setup or an instant website launch.

2. Understand A record vs CNAME

This is one of the most common points of confusion in DNS management.

Choose an A record when:

• You need to point directly to an IPv4 server address.
• You are connecting the root domain to a server.
• You want a simple direct mapping with no hostname alias in between.

Choose a CNAME when:

• You want one hostname to follow another hostname.
• A SaaS platform gives you a target like sites.provider.example.
• You want a subdomain such as blog or shop to inherit changes from another hostname automatically.

Rule of thumb: if the destination is an IP, use A. If the destination is another hostname, use CNAME.

Be careful not to place a CNAME where other record types are already needed for the same hostname. That is one reason root-domain setups often use A records instead.

3. Set up email for your domain

Use: MX records, usually with supporting TXT records.

Typical use case: your website runs on one host, but your business email runs through a separate provider.

• MX records tell senders which mail servers accept email for your domain.
• Priority values help define the order mail servers should be tried.
• TXT records are commonly used for SPF, DKIM, or domain verification required by the email provider.

Quick checklist:

• Get the exact MX records from your email provider.
• Remove old MX records that conflict, unless your provider explicitly says to keep them.
• Add required TXT records for verification and authentication.
• Check whether you also need records for subdomains or autodiscovery features.
• Send a test email in and out after changes settle.

If your email breaks after a hosting change, the cause is often not web hosting itself but missing or overwritten MX and TXT records. This happens often when people switch nameservers or import DNS zones without reviewing mail settings.

4. Verify a domain with a service

Use: usually a TXT record, sometimes a CNAME depending on the service.

Typical use case: proving ownership to analytics, search tools, email platforms, CDN services, or third-party apps.

Quick checklist:

• Copy the verification value exactly as provided.
• Confirm whether the host should be the root, a subdomain, or a provider-specific label.
• Use a TXT record unless the service specifically asks for a CNAME.
• Wait for propagation, then run the provider’s verify action again.
• Do not delete the verification record unless you are sure the service no longer needs it.

This is where txt record verification matters most. Many website owners accidentally place the value on the wrong host or add extra quotation marks in the wrong place.

5. Change DNS providers or connect a domain to a new nameserver setup

Use: NS records at the registrar level, or NS records for subdomain delegation in advanced setups.

Typical use case: you register domain and hosting in different places, or you want DNS management in one platform and hosting elsewhere.

• Nameserver changes move authority for the entire zone to a new DNS provider.
• NS records inside the zone can delegate a subdomain such as dev.example.com to another DNS setup.

Quick checklist:

• Build the full DNS zone at the new provider before changing nameservers.
• Copy website, email, TXT verification, and any special records first.
• Change nameservers only when the new zone is ready.
• Keep a backup of the old zone.
• Monitor website and email closely during the transition.

This is the heart of a practical nameserver records guide: NS records are not content records like A or MX. They decide who controls the answers for your domain.

6. Configure app-specific services

Use: SRV records when a service explicitly requires them.

Typical use case: voice tools, messaging systems, directory services, game servers, or other software that needs host and port details.

Quick checklist:

• Follow the provider format exactly, including service name, protocol, port, priority, and weight.
• Confirm whether the target hostname already has an A or AAAA record.
• Test with the application, not just a browser.

Many website owners never need SRV records for a basic site launch. But if you run specialized services, SRV becomes important and is worth documenting carefully.

7. Launch a new website without breaking existing services

Use: usually a mix of A or CNAME for the site, plus MX and TXT for email and verification.

Quick checklist:

• List every service using the domain before making changes.
• Separate website records from email records so you do not assume one controls the other.
• Update only the hostnames involved in the website launch.
• Check whether SSL provisioning depends on DNS being correct first.
• Test site, email, and verification tools after launch.

If you are still choosing the domain itself, these guides may help: Domain Registration Cost Guide: First-Year vs Renewal Pricing by Domain Type and Best Domain Extensions for Small Business Websites in 2026.

What to double-check

Even when you know which record type to use, small input errors can cause slow troubleshooting. Before saving any DNS change, run through these checks.

• Host value: Are you editing the root domain, www, or another subdomain? Many mistakes come from entering the right record on the wrong host.
• Destination format: Is the target an IP address or a hostname? That usually decides A record vs CNAME.
• Conflicts: Make sure you are not creating duplicate or contradictory records for the same hostname.
• Mail safety: If you are changing nameservers, confirm MX and TXT records are copied before the switch.
• TTL: A lower TTL can help before planned changes, but remember to increase it later if appropriate for your setup.
• Trailing dots and interface quirks: Different DNS dashboards display values differently. Follow the provider’s examples closely.
• Proxy or CDN settings: If a DNS provider offers traffic proxying, be sure that feature is appropriate for the record and service.
• Verification timing: Some services need you to wait, then retry verification rather than editing the record again.

It also helps to keep a simple DNS inventory: record type, host, value, purpose, and who requested it. This turns DNS from a mystery into a maintainable list and is especially useful when multiple tools are attached to one domain.

Common mistakes

Most DNS problems are not caused by obscure technical failures. They come from a short list of repeatable mistakes.

• Using a CNAME where an A record is required. This often happens at the root domain.
• Forgetting that website DNS and email DNS are separate. Changing web hosting does not mean you should replace mail records.
• Replacing nameservers without copying the full zone first. This can break website access, mail flow, and third-party verifications at the same time.
• Leaving old MX records in place. Mixed mail routes can cause inconsistent delivery.
• Putting TXT verification on the wrong host. A token for the root domain is not the same as a token for _acme-challenge or another label.
• Ignoring subdomains. Your root site may work while www, shop, or blog still points elsewhere.
• Testing too early and changing too much. DNS updates take time. Multiple edits in quick succession can make troubleshooting harder.
• Not documenting why a record exists. Later, someone removes a record that looked unnecessary but was still in use.

A calm process helps more than speed. Take a snapshot of the current zone, make one logical change at a time, and verify the affected service before moving on to the next task.

When to revisit

DNS is not something you configure once and forget forever. Revisit your records whenever the underlying services change.

Review DNS before these moments:

• Moving to new web hosting or changing website hosting plans
• Starting or replacing business email
• Launching a new subdomain, landing page platform, or store
• Migrating a website and trying to preserve uptime
• Switching DNS providers or registrar settings
• Adding SSL automation, CDN services, or verification tools
• Seasonal planning cycles when traffic, campaigns, or launch workflows change

Practical action list for your next review:

1. Export or copy your current DNS records.
2. Label each record by function: website, email, verification, delegation, or app service.
3. Remove only records you can confidently identify as unused.
4. Confirm that the root domain and key subdomains resolve where you expect.
5. Send and receive a test email if your domain is used for mail.
6. Check ongoing TXT-based verifications for tools you still use.
7. Update your internal DNS notes so the next change is easier.

If you manage domains as part of a broader launch process, this article works best as a pre-change checklist. Come back to it whenever you need to connect domain to hosting, compare an A record vs CNAME decision, complete MX record setup, confirm TXT record verification, or understand whether nameserver changes are the right move. DNS becomes much less confusing once each record type is tied to a clear job.