DNS Records Explained: A, CNAME, MX, TXT, NS

Learn how A, CNAME, MX, TXT, and NS records work, then follow a practical workflow to configure, verify, and troubleshoot DNS.

DNS records connect a domain name to websites, email services, verification systems, and other internet resources. This guide explains what A, CNAME, MX, TXT, and NS records do, then provides a repeatable workflow for configuring them, checking propagation, and troubleshooting common failures.

Overview

When someone visits example.com, their device uses the Domain Name System (DNS) to find the service responsible for that name. DNS is distributed: your domain is delegated to authoritative nameservers, and those nameservers publish records that tell resolvers where to send web traffic, email, or verification requests.

The most useful records for day-to-day DNS management are:

A record: Points a hostname to an IPv4 address, such as 203.0.113.10. It is commonly used for a website or server.
AAAA record: Points a hostname to an IPv6 address. Use it only when the destination is correctly configured for IPv6.
CNAME record: Points one hostname to another hostname, such as www.example.com to example.com or a provider-specific target.
MX record: Specifies which mail servers receive email for a domain. MX records include a priority value; lower numbers generally indicate higher preference.
TXT record: Stores text used for domain verification, email authentication, and other service configuration. SPF, DKIM, and some ownership checks use TXT records.
NS record: Identifies the authoritative nameservers for a DNS zone. NS changes are usually made at the registrar or parent DNS provider, not as an ordinary record in the zone you are editing.

A DNS record has more than its type and value. Pay attention to the name or host field, the TTL, and, where relevant, priority. Control panels may expect only the host portion—for example, www rather than the full domain—or may represent the root domain with @. Check the panel's field guidance before saving.

Step-by-step workflow

1. Map the service you are connecting

Start with a written target list. For a website, record the hosting provider's required A, AAAA, or CNAME destination. For a custom email domain, record every MX hostname and priority supplied by the email provider. For verification, copy the exact TXT name and value. Do not substitute an IP address for a hostname unless the provider specifically instructs you to do so.

Also identify where DNS is currently hosted. The company where you completed domain registration may not be the authoritative DNS provider. If you are unsure, review the domain's NS records or use a DNS lookup tool.

2. Confirm nameserver control

Before changing records, sign in to the control panel that hosts the active DNS zone. If the domain uses registrar nameservers, edit records there. If it uses managed DNS or hosting-provider nameservers, make changes in that provider's DNS interface instead. Editing an inactive zone will not affect public DNS.

For a deeper comparison of these responsibilities, see Nameservers vs DNS Records: Which Should You Change and When and Managed DNS vs Registrar DNS.

3. Add the website record

For an IPv4 web server, a typical record might look like this:

Type: A
Name: @
Value: 203.0.113.10
TTL: Provider default

To make www.example.com resolve to the root domain, you might add:

Type: CNAME
Name: www
Value: example.com
TTL: Provider default

Use the exact destination supplied by your host. Do not create a CNAME for a hostname that already has A, AAAA, MX, or other conflicting data. A hostname generally should not have a CNAME alongside other record types.

4. Add email and verification records

For email, remove obsolete MX records only after confirming that the domain no longer depends on the previous mail service. Then add the new provider's MX records exactly as documented. A simplified example is:

Type: MX
Name: @
Priority: 10
Value: mail.example-provider.test

Real providers may require multiple MX records. Preserve each required entry and its priority. For TXT records, copy the complete value, including punctuation and quotation marks where the control panel requires them. A verification record may look like:

Type: TXT
Name: @
Value: provider-verification=replace-with-issued-token

Do not combine unrelated TXT values into one entry unless the provider's instructions explicitly allow it. Email authentication records have strict formatting requirements, so use the provider's current documentation for SPF and DKIM values rather than relying on an old record from another service.

5. Save, document, and test

Record the change, including the date, hostname, old value, new value, and reason. This small change log makes future website migrations and email troubleshooting much easier. Then test from a DNS lookup tool, a command-line utility such as dig or nslookup, and the destination service itself.

Tools and handoffs

A reliable DNS workflow usually involves several handoffs:

Registrar: Controls domain registration, renewal, and often nameserver delegation.
DNS provider: Publishes the authoritative zone and manages records.
Hosting provider: Supplies web destinations and may require domain verification.
Email provider: Supplies MX, SPF, DKIM, and sometimes DMARC instructions.
Monitoring and lookup tools: Show what public resolvers can currently see.

Use lookup tools to distinguish a DNS problem from an application problem. If an A record returns the expected address but the site does not load, investigate hosting, firewall rules, web-server configuration, redirects, or SSL certificates. For redirect behavior across HTTP, HTTPS, www, and non-www versions, see How to Set Up Redirects Correctly.

DNS is also only one part of availability. Pair record checks with an uptime monitor and review alerts for both the domain and the application. The Website Uptime Monitoring Guide provides a useful framework for deciding what to track.

Quality checks

Check the authoritative answer: Query the nameservers listed for the domain, not only a local resolver. This confirms whether the active zone contains the intended record.
Check multiple resolvers: Different networks may retain older answers until the previous TTL expires. This is why DNS propagation can appear inconsistent.
Check for conflicts: Look for duplicate A records, an unwanted AAAA record, conflicting CNAME data, or old MX records.
Check the hostname format: A provider may require a trailing dot in a fully qualified target, while a control panel may add it automatically. Avoid accidentally creating www.example.com.example.com.
Check email separately: Confirm that MX records point to the intended provider, then send and receive test messages. A working website does not prove that email is configured.
Check SSL after DNS: Once the hostname resolves to the correct service, confirm that the certificate covers the exact domain and that HTTPS loads without a warning.
Check TTL before major changes: A shorter TTL can make planned changes easier to roll back, but it does not instantly remove cached answers already held by resolvers.

The most common mistakes are editing the wrong DNS provider, entering a full domain where only a host label is expected, leaving old MX records in place, copying an incomplete TXT value, and assuming that a saved record is immediately visible everywhere.

When to revisit

Revisit this DNS record inventory whenever you move a website, change email providers, add a subdomain, enable a verification service, change nameservers, or migrate hosting. Review it before a domain transfer as well, because DNS may remain with a separate provider and should not be assumed to move with the registration.

Keep a current export or written record of important entries, but do not treat a backup as a substitute for testing. Provider interfaces, required verification records, email-authentication guidance, and hosting targets can change. Before each planned migration, lower TTLs only if the change plan benefits from it, confirm rollback values, and note which provider is authoritative.

As a practical final checklist: identify the active nameservers, document the intended records, change one service at a time where possible, query authoritative and public resolvers, test the website and custom email, then monitor the result. For broader website connection steps, use How to Connect a Domain to Your Hosting Provider. A disciplined DNS management process turns a confusing set of fields into a controlled, repeatable part of website operations.