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

Overview

When you buy a domain, the domain itself does not automatically know where to send web traffic or email. The Domain Name System (DNS) provides that direction through a set of records stored in a DNS zone. Your registrar, hosting provider, or dedicated DNS provider may provide the control panel used to manage those records.

The correct record depends on the service you are connecting. An A record normally maps a hostname to an IPv4 address. A CNAME record maps one hostname to another hostname. MX records identify mail servers, while TXT records store text used for verification and email authentication. NS records identify the authoritative name servers for a domain or delegated subdomain.

DNS changes are powerful because one incorrect value can affect a website, email delivery, SSL validation, or a third-party integration. Before editing a zone, record the current values, confirm the service provider's instructions, and make one controlled change at a time. For a broader launch sequence, use the website launch checklist covering domain, hosting, DNS, SSL, and go-live steps.

Checklist by scenario

Connecting a website or hosting account

1. Confirm whether the hosting provider expects an A record, AAAA record, CNAME, or a change to your name servers.
2. Identify the exact hostname. The root domain is often represented as @ in a DNS control panel; www is a separate hostname.
3. For an A record, enter the provider's IPv4 address in the value field. For IPv6, use an AAAA record and the supplied IPv6 address.
4. If the provider gives a hostname instead of an IP address, use a CNAME where the provider permits it.
5. Check whether an existing record uses the same name. Remove or replace a conflicting record only after confirming what service depends on it.
6. Test both the root domain and any requested subdomain, such as www.example.com.

A CNAME is commonly useful for a subdomain such as app.example.com when a platform gives you a destination hostname. It is not a general substitute for an A record, and the root domain may have special restrictions in many DNS interfaces.

Adding a subdomain

1. Choose a clear label, such as docs, status, or staging.
2. Use the record type required by the destination service.
3. Enter only the label if the control panel automatically appends your domain. Some panels expect the full hostname, so check the field hint.
4. Confirm that the subdomain is not already used for another application, certificate validation, or security service.
5. Test the subdomain independently from the main website.

Setting up email

1. Collect the complete MX record list from the mail provider, including each server's priority.
2. Replace obsolete MX records only when you are ready to move mail. Leaving old and new records together can send messages to unintended servers.
3. Publish the provider's TXT records for SPF, DKIM, or domain verification exactly as supplied.
4. Check whether an SPF record already exists. A domain should not be given several independent SPF policy records; consolidate authorized senders according to the mail provider's instructions.
5. Complete the provider's verification step and send test messages in both directions.

Verifying a service or ownership claim

Many platforms ask you to publish a TXT record, although some use a CNAME or a file at your website. Add the requested record at the exact hostname, preserve punctuation and capitalization where instructed, and avoid adding quotation marks unless the control panel specifically requires them. Keep the record until the service confirms verification; removing it may invalidate a future check.

What to double-check

Names and formatting

DNS panels differ in how they display the host or name field. A value such as www may become www.example.com automatically. Entering the full domain when the panel appends it can create an unintended name such as www.example.com.example.com. Review the panel's preview, if available, before saving.

For CNAME, MX, and NS values, a trailing dot may appear in technical documentation to indicate a fully qualified domain name. Many web interfaces add or remove that dot automatically. Follow the provider's field guidance rather than adding punctuation repeatedly.

TTL and propagation

TTL, or time to live, tells caching DNS resolvers how long they may retain a response. A shorter TTL can make a planned change easier to adjust, while a longer TTL can reduce repeated lookups. The exact time users see a change depends on existing cached responses, the record's previous TTL, and the resolver being queried. Do not treat one local lookup as proof that every network has updated.

For a planned migration, lower the relevant TTL in advance if your provider and DNS panel allow it, then make the change during a monitored window. Restore a sensible value after the move is confirmed. This does not instantly clear caches that already hold the previous response.

Authority and ownership

First identify which name servers are authoritative for the domain. Editing records at the registrar will not affect the live zone if the domain uses a different DNS provider. An NS change is not the same as adding a record inside the zone: it delegates DNS control and can affect every hostname, including web and email services. If you are changing providers, document the complete zone before switching.

For a domain transfer, keep DNS and registrar changes separate where possible. The domain transfer checklist can help you plan the registrar side without losing track of active DNS services.

Common mistakes

• Using a CNAME where an A record is required: An IP address belongs in an A record; a hostname belongs in a CNAME.
• Creating a CNAME conflict: A name configured as a CNAME generally should not also have separate A, MX, or TXT records at that same name.
• Deleting MX records during a website change: Web hosting and email hosting may use different records. Change only the records relevant to the service.
• Publishing duplicate SPF records: Check for an existing SPF TXT record before adding another. Follow the mail provider's current formatting guidance.
• Editing the wrong DNS zone: Confirm the authoritative name servers and the exact domain before saving changes.
• Assuming propagation is instant: Compare results from more than one network or DNS lookup tool and allow for cached responses.
• Changing several records at once: Batch changes can make diagnosis difficult. Save a timestamped copy of the old zone and change related records in a controlled order.
• Ignoring DNSSEC during a provider change: If DNSSEC is enabled, coordinate key and delegation changes with the current and new DNS providers. A mismatch can make a domain fail validation.

When to revisit

Use this guide whenever you connect a new hosting account, add a subdomain, change email providers, verify a third-party service, or move DNS to a different provider. It is also worth reviewing before a seasonal campaign or other planned traffic increase, when a temporary staging environment is created, and after a website or infrastructure migration.

For an ongoing maintenance routine, review the zone at least when ownership, hosting, email, or application architecture changes. Remove records for retired services, confirm that SSL validation records are still needed, and check that former vendors no longer have unnecessary DNS entries. Keep a current inventory containing the record name, type, purpose, owner, and date last reviewed.

Before your next change, follow this short sequence:

1. Write down the desired outcome, such as “send www to the new web host” or “verify the mail domain.”
2. Identify the authoritative DNS provider and export or copy the existing relevant records.
3. Use the record type specified by the destination service, not a similar-looking alternative.
4. Check for conflicts at the same hostname and preserve unrelated web, mail, and security records.
5. Save the change, note the time and TTL, and test from more than one resolver or network.
6. Document the final value and remove obsolete records only after the replacement is confirmed.

DNS management becomes safer when every record has a clear purpose and every change has a rollback plan. Keep this checklist with your domain and hosting documentation so it is available the next time a service needs to be connected.