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 information that browsers, mail servers, and other services can use. A DNS record is a rule stored in an authoritative DNS zone. Each record has a name, type, value, and often a TTL (time to live), which tells recursive resolvers how long they may cache the answer.

Most website and email setups rely on a small group of record types:

• A record: Points a hostname to an IPv4 address. It is commonly used for a root domain or a subdomain hosted on a server.
• AAAA record: Performs a similar job for an IPv6 address.
• CNAME record: Creates an alias from one hostname to another hostname. It is useful when a provider gives you a destination name rather than a fixed IP address.
• MX record: Specifies which mail servers receive email for a domain. MX records use priority values to indicate preference.
• TXT record: Stores text used for domain verification, email authentication, and service configuration.
• NS record: Identifies the authoritative name servers for a domain or delegated subdomain.

DNS management is separate from web hosting, although the two are often configured together. Your registrar may provide the DNS control panel, while your website, email, CDN, or cloud hosting provider supplies the values to enter.

For a broader reference, see DNS Records Explained: A Practical Guide to A, CNAME, MX, TXT, and NS Records. If you are changing records during a migration, keep an offsite backup and document the current zone before editing it.

Checklist by scenario

Connecting a website or web hosting account

1. Confirm whether the host expects an A record, AAAA record, CNAME, or a combination.
2. Check whether the root domain is written as @, left blank, or entered as the full domain in your DNS panel.
3. Point the root domain to the supplied IP address if the host requires an A record.
4. Point www to the root domain or the provider’s hostname if a CNAME is recommended.
5. Check that an old A, AAAA, or CNAME record is not competing with the new destination.
6. Confirm that the website’s SSL certificate covers every hostname you intend to use.

An A record versus a CNAME decision usually depends on the provider’s instructions. Do not place a CNAME and another record type on the same hostname unless your DNS provider explicitly supports that arrangement.

Configuring email

1. Collect the complete MX record list from your email provider, including each server name and priority.
2. Remove obsolete MX records only after confirming that the old service is no longer needed.
3. Enter each MX record at the correct host, usually the root domain.
4. Add the provider’s requested TXT records for SPF, DKIM, or domain verification.
5. Check whether the provider requires a separate DKIM CNAME instead of a TXT value.
6. Send test messages in both directions and inspect delivery results after DNS changes have had time to reach different resolvers.

When learning how to configure MX records, remember that MX values point to mail hostnames; they do not normally contain an IP address. The mail hostname must then resolve through an A or AAAA record.

Adding a subdomain

1. Choose a clear hostname such as app, staging, docs, or status.
2. Use an A or AAAA record when the subdomain needs to resolve directly to an IP address.
3. Use a CNAME when the destination is another hostname managed by a provider.
4. Confirm that the application, hosting account, reverse proxy, and SSL certificate all recognize the new hostname.
5. Test both the subdomain and any redirects from the root domain or www.

Verifying ownership or enabling a service

1. Copy the TXT or CNAME value exactly as provided by the service.
2. Preserve punctuation, underscores, hyphens, and capitalization where the provider requires them.
3. Place the record at the requested host, which may be the root domain or a generated label.
4. Do not delete unrelated TXT records without checking what uses them.
5. Use the provider’s verification tool only after confirming that the record is publicly visible.

What to double-check

Names and formatting: DNS panels differ in how they handle trailing dots, full domain names, and the @ symbol. Follow the panel’s field labels rather than assuming that every interface works the same way. A value entered as mail.example.com may be treated differently from mail.example.com. depending on the system.

TTL and propagation: TTL controls caching; it does not make a change travel instantly. Before a planned migration, lowering the TTL may help resolvers refresh sooner, but it cannot override existing cached answers. After changing records, check the result from more than one network or DNS lookup tool. For a deeper explanation, read DNS Propagation Explained: How Long Changes Take and How to Check Them.

Authoritative name servers: First identify which name servers are authoritative for the domain. Editing records at a registrar is ineffective if the domain actually uses a separate DNS provider. The NS records shown by a lookup and the name servers configured at the registrar should agree with your intended setup.

Conflicting records: Look for duplicate A records, stale AAAA records, multiple CNAME targets, old MX entries, and verification records left from previous services. Some duplicates are valid, but each should have a documented purpose.

Security and access: Limit DNS account access, enable available authentication controls, and keep a dated export or written inventory of important records. DNS changes can affect website availability, email delivery, SSL validation, and third-party integrations.

Common mistakes

• Using a CNAME at the root when the DNS provider does not support it: Use the provider’s supported root-domain method, often A or AAAA records, or an applicable flattening feature.
• Leaving old MX records in place: Mail can be delivered unpredictably when obsolete and current mail servers coexist.
• Replacing all TXT records with one new value: TXT records may support several independent services. Add the required entry without removing others blindly.
• Forgetting IPv6: An outdated AAAA record can send some visitors to the wrong server even when the A record is correct.
• Editing the wrong DNS zone: Confirm the domain, environment, and authoritative provider before saving changes.
• Assuming propagation means the configuration is correct: Waiting does not fix a misspelled hostname, wrong IP address, invalid priority, or missing SSL configuration.
• Changing many records without a rollback plan: Make related changes together, record the previous values, and test each service after the change.

If a website or email service still fails, use a structured workflow rather than repeatedly editing records. The guide How to Troubleshoot DNS Issues can help separate DNS problems from hosting, application, certificate, and mail-server problems.

When to revisit

Review your DNS inventory before seasonal planning cycles, domain transfers, hosting migrations, email-provider changes, CDN adoption, or major application releases. Revisit it whenever workflows or tools change, especially when a team introduces a new SaaS platform that requests TXT, CNAME, or MX records.

Use this short maintenance routine:

1. Export or document the active DNS records and their purpose.
2. Confirm the authoritative name servers and registrar access.
3. Remove records for retired services only after checking dependencies.
4. Test the root domain, key subdomains, website SSL, and inbound and outbound email.
5. Record the date, editor, reason, and rollback values for each significant change.

Before the next change, start with the documented baseline, verify the provider’s current instructions, and lower risk by changing only what the scenario requires. That simple habit makes DNS management more predictable and gives you a clear recovery path when a website, email system, or verification workflow behaves unexpectedly.