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

Overview

The Domain Name System, or DNS, translates human-readable names such as example.com into technical destinations such as IP addresses, hostnames, and mail servers. Your domain registrar may provide DNS management, or your domain may use nameservers operated by a separate hosting, cloud, CDN, or DNS provider.

Before changing a record, identify two things: which provider is authoritative for the domain and what service the record needs to support. The authoritative provider is determined by the domain's NS records. Editing DNS at the wrong provider will not change the live configuration, even if the record appears correct in a different control panel.

DNS records commonly include these fields:

• Name or host: The domain label the record applies to. The root domain may be shown as @, left blank, or written as the full domain, depending on the control panel.
• Type: The purpose of the record, such as A, CNAME, MX, TXT, or NS.
• Value or target: The IP address, hostname, mail server, or verification text.
• TTL: How long resolvers may cache the answer before asking again.
• Priority: Used by some record types, especially MX records, to establish an order of preference.

DNS is separate from web hosting. A domain can point to a cloud server while its email remains with another provider. It can also use a CDN or reverse proxy in front of the origin host. For a broader launch sequence, see How to Launch a Website: A Complete Domain, Hosting, DNS, and SSL Checklist.

DNS record types at a glance

• A record: Points a hostname directly to an IPv4 address. A common use is pointing example.com or www.example.com to a web server. Use the IPv4 address supplied by your hosting or infrastructure provider.
• AAAA record: Performs a similar job for an IPv6 address. Add one only when the destination is configured to accept IPv6 traffic and the address is correct.
• CNAME record: Points one hostname to another hostname, such as www.example.com to app.hosting-provider.example. The destination hostname can change its underlying address without requiring you to edit the CNAME.
• MX record: Identifies the mail servers responsible for receiving email for a domain. MX values usually include a mail hostname and a priority number. Lower numbers commonly indicate higher preference, but follow the email provider's instructions.
• TXT record: Stores text used for domain verification, email authentication, and other service configuration. SPF, DKIM-related information, and DMARC policies are commonly published through TXT records, although the exact setup depends on the mail provider.
• NS record: Identifies the nameservers authoritative for a domain or delegated subdomain. NS changes affect where the DNS zone is managed and should be treated as a high-impact change.

Some providers use additional records, such as CAA, SRV, or ALIAS-style records. Their availability and behavior vary by provider, so use the service's current documentation when those records are required.

Checklist by scenario

Point a domain to a website

1. Confirm the correct authoritative DNS provider by checking the domain's nameservers.
2. Ask the hosting provider whether it expects an A record, AAAA record, CNAME, or a provider-specific target.
3. Point the root domain, commonly shown as @, to the supplied destination.
4. Configure www separately if the provider requires it. A CNAME to the root domain or hosting target is common, but do not create a CNAME where another record already exists.
5. Keep any required records for verification, redirects, or other services.
6. Confirm that the hosting platform recognizes the domain and has issued or enabled an SSL certificate.

DNS alone does not configure the web server. The domain must also be added to the hosting account, and the server must be prepared to answer for that hostname. For a step-by-step connection workflow, read How to Connect a Domain to Cloud Hosting: DNS Records, SSL, and Troubleshooting.

Set up email hosting

1. Record the existing MX entries before making changes.
2. Add the email provider's MX records exactly as supplied, including priorities.
3. Add the provider's TXT records for domain verification and sender authentication.
4. Check whether DKIM uses a TXT record or a CNAME selector record.
5. Publish a DMARC record only after understanding the requested policy and reporting address.
6. Test both incoming and outgoing mail using more than one mailbox when possible.

Do not assume that changing MX records moves existing mail. Mailbox data, user accounts, forwarding rules, and archives must be handled within the email service. See How to Set Up Professional Email on Your Domain for the wider setup process.

Verify a third-party service

1. Choose the verification method specified by the service, usually a TXT record, CNAME, or file-based method.
2. Use the exact host name and value. Preserve punctuation, underscores, and capitalization where the provider requires them.
3. Do not remove an existing TXT record unless you know what it supports. Multiple TXT records may be valid.
4. Wait for the record to become visible, then use the service's verification control.
5. Remove temporary verification records only if the service confirms they are no longer needed.

Troubleshoot a DNS change

1. Check the authoritative nameservers first.
2. Query the exact hostname and record type you changed.
3. Compare results from your local resolver with an independent DNS lookup tool.
4. Check for conflicting records, incorrect trailing dots, duplicated host labels, or an old destination.
5. Confirm the application, web server, SSL certificate, or email service is configured for the same domain.

What to double-check

Root and subdomain formatting: A control panel may automatically append your domain. Entering www.example.com in a field that expects only www can produce an unintended name. Check the provider's field examples.

Record conflicts: A hostname generally should not have a CNAME alongside other record types at the same name. An existing A record can also make a new CNAME impossible or ineffective. Review the complete zone before adding records.

TTL planning: A shorter TTL can make planned changes easier to roll back, but it does not force every resolver to refresh immediately. After a change is stable, a longer TTL may reduce repeated DNS queries. Follow the provider's guidance and use a consistent approach.

Nameserver changes: Replacing NS records changes the DNS authority for the zone. Recreate all required website, email, verification, security, and subdomain records at the new provider before switching authority.

Email continuity: MX changes can affect delivery. Keep a written copy of the previous configuration, schedule changes carefully, and verify that SPF, DKIM, and DMARC records match the active sending services.

Security and access: Protect the registrar and DNS provider accounts with strong, unique credentials and available multi-factor authentication. Limit who can edit DNS, because a mistaken or malicious change can redirect traffic or disrupt email.

Common mistakes

• Editing the wrong DNS panel: The registrar may not host the authoritative zone. Check NS records before editing.
• Replacing the entire zone: Adding website records does not require deleting unrelated records. Preserve email, verification, and service entries.
• Using an IP address in a CNAME: CNAME targets are hostnames. Use an A or AAAA record when the provider gives you an IP address.
• Adding duplicate SPF records: SPF is published as TXT, but multiple competing SPF policies can cause inconsistent results. Follow the mail provider's instructions for combining authorized senders.
• Expecting instant propagation: Cached answers can remain available until their TTL expires, and different resolvers may update at different times.
• Testing only from one network: A local cache can hide the public result. Check from multiple resolvers and test the actual application.
• Assuming DNS fixes an SSL error: The certificate and hosting configuration must include the hostname, and the site must serve the certificate correctly.

When to revisit

Review your DNS documentation before a website launch, hosting migration, domain transfer, email-provider change, CDN rollout, or major infrastructure update. Seasonal planning cycles are also a useful time to confirm that renewal contacts, registrar access, monitoring, and backup records are current.

Revisit the zone whenever workflows or tools change. A new deployment platform may require a CNAME, a new email sender may require authentication updates, and a security service may introduce verification or certificate-related records. Record the reason, date, owner, and rollback plan for every significant change.

Keep a simple DNS inventory with the hostname, type, target, purpose, provider, TTL, and responsible owner. Before editing, export or copy the current zone where the provider supports it. After editing, verify the public result, confirm website and email behavior, and monitor for failures rather than relying only on a successful save message.

Use this guide as a pre-change checklist: identify authority, document the current state, make the smallest necessary change, allow for caching, test from outside your local network, and update the inventory. That workflow reduces avoidable outages while keeping DNS manageable as your domain and hosting setup evolve.