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 the destinations computers need to reach. Your domain registrar, DNS provider, or hosting control panel may provide the interface for managing these records. The interface can vary, but the core fields are usually the same: name or host, record type, value, and sometimes TTL.

DNS management is separate from web hosting. A domain can be registered with one company, use DNS servers operated by another, and point to a website hosted somewhere else. Before changing anything, identify which provider is authoritative for the domain. The authoritative provider is the system whose DNS zone contains the records that answer public queries.

Use this basic record reference:

• A record: Points a hostname to an IPv4 address. It is commonly used for a website or server.
• AAAA record: Points a hostname to an IPv6 address. It serves a similar purpose to an A record when IPv6 is configured.
• CNAME record: Makes one hostname an alias of another hostname. It is often used for subdomains, hosted services, and verification targets.
• MX record: Identifies the mail servers responsible for receiving email for a domain. MX records use a priority value so mail systems know which destination to try first.
• TXT record: Stores text used for verification and email security settings, including SPF, DKIM, and DMARC-related values supplied by a service.
• NS record: Identifies the authoritative nameservers for a domain or delegated subdomain. Changing nameservers can replace the DNS management location for the domain.

A useful distinction is that an A record contains an IP address, while a CNAME points to another hostname. Do not place a hostname in an A record or an IP address in a CNAME field. Also check whether your DNS provider supports a CNAME at the zone apex, sometimes called the root domain. If it does not, the root domain may require an A record or a provider-specific alias feature.

Checklist by scenario

To point a domain to web hosting

1. Confirm the hosting provider’s required destination. This may be an IPv4 address, IPv6 address, hostname, or a combination.
2. Decide whether the root domain, example.com, the www hostname, or both should serve the site.
3. Update the root A record if the host supplied an IPv4 address. Add an AAAA record only when an IPv6 address is intentionally configured.
4. For www, use the record type recommended by the host. A CNAME to the root domain or to a hosting hostname is common, but the correct target depends on the provider.
5. Remove conflicting records for the same hostname when they are no longer needed. An old A record can send visitors to a previous server.
6. Confirm that the hosting account recognizes the domain and that the site is configured for the expected hostname.
7. After DNS resolves correctly, configure HTTPS and verify that the certificate covers every hostname visitors use. See the SSL in cPanel walkthrough for a hosting-control-panel checklist.

To set up domain email

1. Obtain the mail provider’s exact MX hostnames and priority values. Do not infer them from the provider’s brand name.
2. Remove obsolete MX records if the domain is moving to a new mail provider. Leaving old and new destinations together can produce inconsistent delivery.
3. Add the provider’s TXT records for email authentication or domain verification exactly as supplied.
4. Check whether a TXT value must be entered with quotation marks. Many control panels add them automatically, so follow the panel’s instructions.
5. Review SPF carefully. A domain should have one effective SPF policy; adding separate SPF records can create an invalid or unpredictable configuration.
6. Complete DKIM and DMARC setup using the provider’s current instructions, then send test messages in both directions.

To verify a third-party service

1. Copy the requested record type, host or name, and value without changing punctuation, underscores, or capitalization in the value.
2. Check whether the service expects the full domain or only the host portion. A control panel may automatically append your domain.
3. Save the record, then use the service’s verification button after allowing time for the record to become visible.
4. Keep the verification record unless the service confirms it can be removed. Some services check it again during account or configuration changes.

To change nameservers or transfer a domain

Changing nameservers is a larger change than editing one A or CNAME record because it moves DNS authority. Before making the change, copy every required record from the current DNS zone, including records for email, subdomains, verification, and internal services. Create the equivalent zone at the new DNS provider before switching nameservers. For related planning, use this domain transfer checklist and the website hosting migration guide.

What to double-check

Authority: Make sure you are editing the active DNS provider. A record changed at a registrar will not affect the public internet if the domain uses different nameservers.

Host formatting: Some panels expect @ for the root domain; others expect a blank field or the full domain. For a subdomain such as blog.example.com, the panel may require only blog. Follow the panel’s label and examples.

Conflicts: A hostname generally should not have an active CNAME alongside A, AAAA, or another CNAME record. Review duplicate or conflicting entries before saving.

TTL: TTL, or time to live, indicates how long resolvers may cache a response. A shorter TTL can make planned changes easier to adjust, while a longer TTL can reduce repeated DNS queries. TTL does not force every resolver to update immediately, so plan changes with a reasonable transition period.

Propagation: Test from more than one network or DNS lookup tool, and check the authoritative nameserver directly when possible. A local result may be cached even after the authoritative record has changed.

Dependencies: Website hosting, SSL, email, CDN settings, staging environments, and verification services can all depend on DNS. Map these dependencies before a migration. The guide to staging and production hosting is useful when separate environments use separate hostnames.

Common mistakes

• Changing nameservers when only an A record was needed: This can unintentionally remove working email and verification records.
• Using the wrong IP address: Copy the address from the hosting provider’s account details, not from an unrelated server or old setup.
• Leaving old records in place: Previous hosting, email, or CDN records can continue directing traffic to the wrong service.
• Adding a CNAME to the root without checking support: The zone apex has special behavior and may require an A record or an alias feature.
• Editing MX records without a mail plan: Web hosting and email hosting may be separate services. Confirm where mail should be delivered before changing MX records.
• Creating multiple SPF records: Consolidate authorized senders into the policy required by your mail providers rather than publishing separate SPF policies.
• Assuming DNS changes failed too quickly: Check the authoritative answer, local cache, and TTL before reverting a change.
• Skipping a record inventory: During a migration, missing one TXT record or subdomain can break a service that is not immediately visible.

When to revisit

Review DNS whenever you change web hosting, move email providers, add a CDN, launch a subdomain, introduce a staging environment, or transfer a domain. Revisit the zone before seasonal planning cycles or major campaigns if traffic, email volume, or infrastructure will change. Also review it when your DNS management tools or hosting workflow changes.

Keep a dated record of the current zone, the reason for each change, and the intended rollback. Before editing, lower TTL only when there is a clear operational reason, record the previous values, and schedule a verification window. After editing, test the root domain, www, important subdomains, inbound email, outbound email, SSL, and any service verification flows.

The safest DNS workflow is simple: identify authority, document existing records, change only what is required, verify from multiple perspectives, and retain a rollback path. Use that checklist each time the underlying hosting, domain, or service inputs change.