DNS Records Explained: A Practical Guide to A, CNAME, MX, TXT, and NS Records

Overview

The Domain Name System (DNS) translates human-readable names such as example.com into the destinations that computers use. When someone visits a website, sends an email, or verifies control of a domain, DNS records help direct that request.

DNS management is usually performed in the control panel of your domain registrar, web hosting provider, DNS hosting provider, or cloud platform. The exact interface varies, but the record types and core fields are broadly consistent: record type, host or name, value or target, and time to live (TTL).

Before changing anything, record the existing configuration. Export the DNS zone if your provider supports that option, or copy the records into a secure change log. This makes it easier to identify what changed and restore a previous value if a service stops working.

The five records to know

• A record: Points a hostname to an IPv4 address. Example: www.example.com to 203.0.113.10.
• CNAME record: Points one hostname to another hostname rather than directly to an IP address. Example: www.example.com to example.com.
• MX record: Identifies the mail servers responsible for receiving email for a domain. MX records include a priority value; lower numbers generally represent higher delivery priority.
• TXT record: Stores text associated with a domain. It is commonly used for domain verification, SPF email authorization, DKIM-related configuration, and other policy or ownership checks.
• NS record: Identifies the authoritative name servers for a domain or delegated subdomain. These servers publish the DNS zone that resolvers consult.

DNS records are separate from your web hosting plan. A domain can use one provider for registration, another for DNS management, and a third for website hosting or email. Keeping those roles documented prevents accidental changes in the wrong control panel.

Checklist by scenario

Pointing a domain to a website

1. Confirm whether the host requires an A record, a CNAME record, or both. Use the hosting provider's supplied destination rather than guessing an IP address.
2. For the root domain, often shown as @, add the required A record or provider-specific record.
3. For a subdomain such as www, add the requested CNAME or A record.
4. Remove only conflicting records. Do not delete email, verification, or unrelated subdomain records without confirming their purpose.
5. Check the site over both the root domain and the preferred www or non-www version.
6. After DNS resolves correctly, verify that the SSL certificate covers every hostname visitors use.

An A record might look like this:

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

Use documentation from the hosting provider for real values. The address above is an example placeholder, not a destination to copy.

Adding a subdomain

1. Choose a clear name, such as app, docs, status, or staging.
2. Confirm whether the destination is an IP address or another hostname.
3. Use an A record for a fixed IPv4 address, or a CNAME when the destination is a hostname managed elsewhere.
4. Confirm that the destination service is configured to accept the new hostname.
5. Test the subdomain independently. A working main website does not prove that the subdomain is configured correctly.

Configuring email

1. Obtain the complete MX record list from your email provider, including each server's priority.
2. Remove obsolete MX records only after confirming that no active mailbox depends on them.
3. Add the provider's required TXT records for SPF, domain verification, or other email policies.
4. Configure DKIM as instructed by the email provider. It commonly requires a TXT record at a selector-based hostname.
5. Send test messages to and from an external mailbox, then check delivery, replies, and authentication results where available.

Do not create multiple unrelated SPF records for the same domain. If several services need authorization, their mechanisms generally need to be combined into one valid SPF policy according to the provider instructions.

Verifying domain ownership

1. Copy the verification record exactly, including the host name and token.
2. Preserve quotation marks only when the DNS control panel or service specifically requires them.
3. Check whether the provider expects the full domain name or only the host portion. Some panels append the domain automatically.
4. Wait for the record to become visible, then run verification from the service that requested it.
5. Keep the record if the service may periodically recheck ownership.

Delegating DNS with NS records

NS changes are broader than ordinary website or email edits because they can move authority for an entire domain or subdomain. Before changing name servers, confirm that the new DNS provider has a complete zone: website records, MX records, TXT records, subdomains, redirects, and any records used by cloud or development tools. A partial zone can make a website appear to work while email or verification fails.

For a wider troubleshooting workflow, see How to Troubleshoot DNS Issues and DNS Propagation Explained.

What to double-check

• Record name: Determine whether the panel expects @, a short host such as www, or a fully qualified domain name.
• Destination format: A records require an IPv4 address. CNAME records require a hostname, not an IP address. MX records require a mail hostname and priority.
• Trailing dots: Some systems display fully qualified names with a trailing dot, while others add it automatically. Follow the provider's format.
• Duplicate or conflicting records: Multiple A records can intentionally distribute traffic, but an accidental mix of old and new destinations can produce inconsistent results.
• TTL: A lower TTL can make planned changes easier to adjust, but it does not guarantee instant worldwide updates. Use the provider default unless you have a reason to change it.
• Nameserver authority: Edit records where the domain's authoritative name servers point. Changing records in an inactive registrar panel has no effect.
• SSL coverage: DNS resolution and HTTPS are separate checks. A correct DNS record does not automatically issue or install an SSL certificate.
• Change timing: Test from more than one network or resolver when practical. Cached answers may differ while a change is being observed.

For important domains, use a written change procedure: identify the requested outcome, capture the current state, make the smallest possible edit, record the time and values, and define a rollback. This approach is useful whether the domain supports a small business website, WordPress hosting, a cloud application, or internal tools.

Common mistakes

Changing records at the wrong provider

Domain registration and DNS hosting may be separate. First identify the authoritative NS records, then make changes in the system that publishes the active zone.

Using a CNAME at the root without checking support

Traditional DNS rules treat the root of a domain differently from a subdomain. Some providers offer special alias or flattening features, while others require an A record. Use the hosting provider's documented method rather than assuming every panel handles root CNAMEs the same way.

Deleting records to “clean up”

Unfamiliar TXT, MX, or verification records may support email, security controls, analytics, or a SaaS integration. Identify each record before removal and keep a backup of the zone.

Expecting propagation to be immediate

Resolvers and applications can cache DNS answers according to TTL and their own behavior. If a change appears inconsistent, compare authoritative results with public resolver results and confirm that the edit was saved correctly.

Forgetting dependent services

Changing a hostname can affect SSL certificates, redirects, email links, API allowlists, monitoring checks, and deployment settings. Maintain a list of systems that use each important hostname.

When to revisit

Revisit your DNS records before a website migration, email provider change, hosting move, domain transfer, CDN rollout, or major application launch. Also review them before seasonal planning cycles if your organization regularly changes campaigns, landing pages, subdomains, or traffic-routing rules.

Schedule a periodic inventory of active records and compare it with current services. Confirm that every A, CNAME, MX, TXT, and NS record has an identified owner and purpose. Remove records that are demonstrably obsolete, but preserve the previous zone and document the reason for each deletion.

When workflows or tools change, update the checklist rather than relying on memory. A reliable final pass is simple:

1. Write down the intended outcome.
2. Identify the authoritative DNS provider.
3. Export or record the current zone.
4. Apply the smallest documented change.
5. Verify website, email, SSL, and affected subdomains.
6. Record the result and the rollback plan.

Used this way, DNS management becomes a controlled operational task instead of a last-minute troubleshooting exercise.