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

DNS is the directory that helps browsers and mail services find the right destination for a domain name. Understanding a few common record types makes website launches, email setup and troubleshooting much less intimidating.

DNS is the directory that helps browsers and mail services find the right destination for a domain name. Understanding a few common record types makes website launches, email setup and troubleshooting much less intimidating.

Understand the DNS lookup

When a visitor enters a domain, their device uses DNS resolvers to find the address or service associated with that name. The authoritative DNS provider publishes the records for the domain. A registrar sells or manages the domain registration, but it does not always host the active DNS zone.

Before editing anything, identify the nameservers currently delegated for the domain. Changes made in the wrong DNS dashboard will have no effect. Keep a copy of existing records so you can restore the configuration if necessary.

A records point names to IPv4 addresses

An A record connects a hostname to an IPv4 address. For example, the root domain may point to the public IP address of a web server. The exact IP must come from the hosting provider; do not copy an example address from a tutorial into a production DNS zone.

If the hosting provider changes the server IP, update the A record accordingly. Some providers give a managed target or an alias-style setup instead of a fixed IP, so follow the host’s published instructions rather than assuming every service uses the same pattern.

CNAME records create aliases

A CNAME record maps one hostname to another hostname. A common use is to point www to the root domain or to a hostname supplied by a hosting platform. The DNS resolver follows the alias to obtain the final destination.

A CNAME generally cannot coexist with other record types at the exact same hostname. Root-domain handling varies by DNS provider because some offer flattening or alias features. If the dashboard refuses a CNAME at the apex, use the provider’s supported alternative.

MX records route email

Mail exchanger records identify the servers that accept incoming mail for a domain. Providers often supply multiple MX records with priorities. Lower numeric priority is generally preferred, with other records available for fallback or load distribution according to the provider’s setup.

Changing nameservers without copying MX records can interrupt email even when the website starts working. Treat website DNS and email DNS as related but distinct systems. Verify mail delivery after a migration rather than checking only whether the homepage loads.

TXT records support verification and security

TXT records store text used for domain ownership verification and email policies. SPF records identify authorized mail senders; DKIM publishes a key used to verify signed messages; DMARC tells receivers how to handle mail that fails aligned authentication checks and where to send reports.

These policies require careful configuration. Multiple independent SPF TXT records at the same hostname can cause validation problems. Follow the mail provider’s exact values, keep only one combined SPF policy where applicable and test authentication before tightening DMARC enforcement.

TTL and propagation

A time to live, or TTL, tells caching resolvers how long a DNS answer may be retained. Lowering TTL before a planned migration can reduce the duration of stale cached answers, but it does not instantly clear caches that already hold the old value.

After a change, compare answers from multiple resolvers and check the authoritative nameservers. DNS updates often become visible quickly, but caches, browser behavior and hosting configuration can make a site appear inconsistent for a while.

Troubleshoot methodically

If a website does not open, confirm nameserver delegation, inspect A or CNAME records, check whether the host recognizes the domain and verify the TLS certificate. For email problems, inspect MX, SPF, DKIM and DMARC separately.

Commands such as nslookup and dig can show DNS answers, but interpret them in context. A correct DNS answer does not guarantee that the web server, application or firewall is configured correctly. Work from the domain outward until you locate the failing layer.

Final thoughts

The most useful next step is to apply one idea from this guide, check the result, and build on what you learn. Keep the experience of the reader at the center of every decision.