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

Overview

The Domain Name System (DNS) translates human-readable names such as example.com into destinations that computers can use. A DNS record is a specific instruction stored with the authoritative DNS provider for your domain. Your domain registrar may provide DNS management, or your records may be managed by a separate hosting, CDN, or security provider.

Before changing anything, identify where the domain's authoritative nameservers point. The provider listed in the domain's NS records is normally the place where you add or edit records. A hosting control panel, registrar dashboard, and DNS provider may use different labels, but the underlying record types are generally the same.

DNS names are entered differently by different interfaces. Some providers expect the full hostname, while others expect only the relative label. For the root domain, a field labelled Name, Host, or Record may use @. Always follow the provider's field instructions and review the resulting fully qualified name before saving.

Checklist by scenario

Point a website to a new IPv4 server

1. Confirm the server's correct public IPv4 address with the hosting provider.
2. Edit or create an A record for the root domain, commonly represented as @.
3. If visitors use www, check whether it has its own A record or a CNAME pointing to the root domain or hosting target.
4. Remove conflicting records only after confirming they belong to the old service and are no longer needed.
5. Verify that the new web server is configured to answer for the domain and that its SSL certificate covers every hostname you use.

An A record points directly to an IPv4 address. A CNAME points to another hostname, not an IP address. This is the key distinction in the common A record vs CNAME record question. Do not replace a provider-required hostname with an IP address unless the provider explicitly instructs you to do so.

Add IPv6 support

1. Confirm that the server is reachable over IPv6 and that its firewall, web server, and hosting configuration are ready.
2. Add an AAAA record with the assigned IPv6 address.
3. Test from an IPv6-capable network and confirm that the site serves the expected content.
4. Remove the record if IPv6 is withdrawn or no longer routes correctly; an incorrect AAAA record can send some visitors to an unreachable destination even when the A record works.

Set up email delivery

1. Copy the email provider's required MX hostnames and priorities exactly.
2. Remove obsolete MX records only when the old mail service has been retired. Multiple providers should not be combined casually.
3. Add the provider's authentication records, usually as TXT records for SPF and verification, plus a DKIM record often supplied as a hostname and value.
4. Publish one deliberate SPF policy for the domain rather than creating several separate SPF records.
5. Configure DMARC as a separate TXT record after reviewing the provider's guidance and your sending sources.

For a deeper email-specific checklist, see the SPF, DKIM, and DMARC setup guide. Email providers can change the exact hostnames and values they require, so use the current values shown in the provider's account rather than copying an old example.

Verify a service or domain

1. Choose TXT when the service gives you a text verification value.
2. Use a CNAME when the service gives you a hostname target, unless it specifically requests another record type.
3. Enter the token exactly, including punctuation and capitalization where required.
4. Leave unrelated records unchanged and remove the verification record only if the service confirms it is no longer needed.

Control certificate issuance

A CAA record can restrict which certificate authority may issue certificates for a domain. A typical value may resemble 0 issue "letsencrypt.org", but the correct authority name and any wildcard or validation requirements depend on your certificate provider. Test this change with the team responsible for SSL certificates before deployment. An overly restrictive CAA policy can prevent legitimate certificate renewals.

What to double-check

TTL and timing

TTL, or time to live, tells recursive DNS resolvers how long they may cache a response. A lower TTL can make planned changes easier to roll back, but it does not guarantee instant worldwide visibility. Existing cached responses may remain available until their stored TTL expires, and different resolvers may refresh at different times. For a planned migration, reduce the relevant TTL ahead of the change when practical, make the update, validate it, and restore a sensible value afterward.

Record conflicts

A hostname generally should not have a CNAME alongside other records such as A, AAAA, or MX at the same name. The root domain may also have provider-specific limitations because standard DNS does not allow a conventional CNAME at a name that already needs other records. Some platforms offer an ALIAS, ANAME, or flattened record; treat these as provider-specific features and follow their documentation.

Safe testing workflow

1. Export or record the current DNS zone, including names, types, values, priorities, and TTLs.
2. Write down the intended change and the reason for it.
3. Check the authoritative nameserver directly, then compare results from more than one public resolver or network.
4. Test the actual service: load the website, send and receive email, complete verification, or inspect the certificate.
5. Monitor for failures before deleting old records or closing the previous hosting service.

To diagnose propagation, distinguish between the authoritative answer and a cached answer. If the authoritative server has the new value but a recursive resolver still shows the old one, caching is likely involved. If the authoritative server is wrong, the record was changed at the wrong provider, entered under the wrong name, or blocked by another configuration issue.

For a broader migration process, use the website migration checklist, and review the website hosting security checklist after the change.

Common mistakes

• Editing DNS at the wrong provider: the registrar is not always the authoritative DNS host. Check the active nameservers first.
• Using a URL in a record value: A and AAAA records require addresses; CNAME and MX values use hostnames. Do not include https:// or a web path.
• Creating multiple SPF records: combine authorized senders into one SPF policy according to the email provider's syntax.
• Replacing all records during a website move: email, verification, subdomains, and security records may still depend on the existing zone.
• Forgetting the root and www hostnames: test both if both are advertised or linked.
• Assuming propagation is the only problem: an incorrect web server, firewall, SSL configuration, or mail routing setup can produce the same symptoms.
• Publishing an untested CAA policy: verify that every certificate authority used for current and future certificates is permitted.

When to revisit

Return to this checklist before moving web hosting, changing email providers, adding a CDN, enabling IPv6, renewing or replacing SSL certificates, or connecting a new verification service. Revisit it after domain registration changes, nameserver updates, security reviews, and seasonal planning cycles when infrastructure ownership or traffic patterns may change.

Keep a dated DNS inventory with the record purpose, responsible service, expected value, TTL, and change owner. Review it quarterly or whenever workflows and provider requirements change. Before each edit, compare the live zone with that inventory, confirm a recent website backup exists, and define a rollback step. The cloud storage and website backup maintenance guide can help keep that recovery process documented.

Final action checklist: identify the authoritative DNS provider, record the current zone, change only the required record, confirm TTL and conflicts, test from multiple networks, validate the real website or email service, and retain the change notes. That process turns DNS management from guesswork into a repeatable operational task.