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

Overview

DNS management is the process of maintaining the records that tell the internet where a domain’s services are located. A browser may use DNS to find a web server, while an email provider uses it to identify mail servers and verify that a message is authorized. Development platforms, analytics tools, certificate systems, and other services may also ask you to publish DNS records.

Before changing anything, identify the authoritative DNS provider. This is usually the service associated with the domain’s nameservers, not necessarily the company providing web hosting or domain registration. If the domain uses nameservers from one provider but you edit records at another, your changes will not affect live traffic.

Keep a simple inventory of each record’s purpose, value, owner, and date of change. A spreadsheet, infrastructure repository, or access-controlled operations document can help. Avoid storing passwords or private keys in that inventory.

Core DNS record types

• A: Points a hostname to an IPv4 address. For example, example.com might point to 192.0.2.10. Use an A record when the destination is an IPv4 address.
• AAAA: Points a hostname to an IPv6 address. It follows the same general purpose as an A record but uses an IPv6 destination.
• CNAME: Points one hostname to another hostname, such as www.example.com to example.com. The destination is a name, not an IP address. A CNAME usually should not be placed at the zone apex, such as the bare example.com, unless the DNS provider supports a provider-specific alias feature.
• MX: Specifies which mail servers receive email for a domain. MX records include a priority value; lower numbers generally indicate higher preference when multiple records are published.
• TXT: Stores text associated with a domain. Common uses include service verification, SPF sender authorization, and other email or security policies. The exact syntax is determined by the service requesting the record.
• NS: Identifies the nameservers responsible for a domain or delegated subdomain. NS records are central to delegation and should be changed cautiously.
• TTL: Time to live is not a record type. It tells resolvers how long a DNS answer may be cached before they request it again. A shorter TTL can make planned changes easier to observe, while a longer TTL can reduce repeated DNS queries.

Checklist by scenario

Publishing or moving a website

1. Confirm the hosting provider’s required destination. It may provide an IPv4 address, IPv6 address, hostname, or a combination.
2. Decide how the root domain and www hostname should behave. A common arrangement uses an A or provider-supported alias record for the root and a CNAME for www, but follow the hosting provider’s instructions.
3. Remove only obsolete records. Do not delete email, verification, or subdomain records simply because they are not related to the website.
4. Check for conflicting records. A hostname should not normally have a CNAME alongside other address records for the same name.
5. After saving, test the root domain, www, key subdomains, redirects, and HTTPS. DNS pointing alone does not prove that the web server, application, or SSL certificate is configured correctly.

If you are changing hosts, document the old and new values first. A staged migration can reduce risk: lower the relevant TTL ahead of the cutover when practical, prepare the new hosting environment, verify it directly where possible, then update DNS and monitor both endpoints. For a broader process, see the website migration checklist.

Configuring email and MX records

1. Copy the mail provider’s MX hostnames and priority values exactly. Do not substitute an IP address unless the provider specifically instructs you to.
2. Remove obsolete MX records when moving providers, unless the provider documents a deliberate mixed-mail configuration.
3. Publish the provider’s requested TXT records for SPF, DKIM, or domain verification. Treat each service’s syntax as authoritative.
4. Check whether your DNS editor automatically appends the domain name. Entering a fully qualified hostname in a field that expects only a host label can create an unintended name.
5. Send test messages to and from more than one mailbox, then inspect delivery results and authentication indicators where available.

Changing MX records affects where new mail is delivered; it does not automatically migrate existing mailboxes or messages. Plan mailbox creation, data migration, aliases, forwarding, and mobile or desktop client settings separately.

Adding a verification or service record

1. Record the exact hostname, record type, and value supplied by the service.
2. Preserve punctuation, quotation marks where required, underscores, and capitalization-sensitive tokens. Many DNS values are technically case-insensitive, but verification tokens should still be copied exactly.
3. Check for an existing TXT record at the same hostname. Multiple TXT strings may be valid, but combining unrelated values into one string can break verification.
4. Wait for the record to become visible to the service, then complete verification in that service’s dashboard.
5. Remove temporary verification records only when the provider confirms they are no longer needed. Some services use them for ongoing domain control checks.

Delegating a subdomain

Use NS records when a separate DNS system should manage a subdomain, such as dev.example.com. Confirm the child zone exists at the delegated provider before publishing delegation. A missing child zone or incorrect nameserver pair can make every name beneath that subdomain fail to resolve. Delegation is different from adding an A or CNAME record for one hostname, so use it only when separate administration is intentional.

What to double-check

• Authoritative nameservers: Query or inspect the domain’s delegation to confirm which DNS provider is answering for it.
• Host field format: Some control panels expect @ for the root, while others expect a blank field or the full domain. Follow that panel’s convention.
• Trailing dots: DNS interfaces vary in how they display fully qualified names. A destination entered without the expected format may be treated as relative to the current domain.
• Record conflicts: Look for duplicate A, AAAA, CNAME, or MX records that send traffic to unintended destinations.
• TTL and caching: A saved change may not appear everywhere immediately because recursive resolvers and local systems can retain earlier answers until their cache expires.
• DNS versus application issues: If a name resolves correctly but returns an error, redirect loop, certificate warning, or blank page, investigate hosting, web server, application, or SSL configuration as well.
• Security and access: Limit who can edit DNS, enable available account protections, and review changes through the provider’s audit history when available.

For DNS propagation troubleshooting, compare results from more than one resolver and location. Useful checks include querying the record type directly, confirming the authoritative answer, and testing the actual service separately. Do not rely only on one office network, browser cache, or local hosts file.

Common mistakes

• Editing the wrong DNS zone: A domain may have records in a hosting panel, registrar panel, CDN, and third-party DNS platform. Only the authoritative zone controls public answers.
• Replacing all records during a website change: Website migration does not usually require deleting MX, TXT, or unrelated subdomain records.
• Using a CNAME where an A record is required: A CNAME targets a hostname, while an A record targets an IPv4 address. Use the type requested by the receiving platform.
• Publishing several SPF records: SPF-related authorization should be consolidated according to the email provider’s instructions. Multiple competing SPF policies can cause validation problems.
• Assuming propagation is instant: Local and recursive caches can continue showing an earlier value. Check TTLs and authoritative responses before repeatedly editing the record.
• Forgetting the root and subdomain distinction: example.com, www.example.com, and mail.example.com are separate hostnames and may require separate records.
• Changing nameservers without preparation: When nameservers change, the new DNS provider must contain every required record before delegation is updated.

When to revisit

Review this DNS checklist before a hosting migration, email-provider change, domain transfer, major application release, CDN rollout, or new third-party integration. Revisit it during seasonal planning cycles if traffic, teams, vendors, or infrastructure routinely change.

It is also worth reviewing DNS after an incident, an unexpected certificate or email-delivery problem, a change in administrative ownership, or the retirement of a service. Remove stale records only after confirming that no application, mailbox, verification process, or delegated zone still depends on them.

For a practical maintenance routine, keep an approved record inventory, review DNS access periodically, test important website and email paths after planned changes, and record the reason for each edit. When a problem appears, start with the authoritative nameservers and the exact hostname involved, then work outward through caching, hosting, application, and security layers. This disciplined sequence makes DNS management safer and gives future administrators a clear trail to follow.