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

Overview

The Domain Name System (DNS) translates human-readable names such as example.com into the destinations computers need to reach. Your domain registrar, web host, DNS provider, or cloud platform may provide the interface where these records are managed. Before editing anything, identify which provider is authoritative for the domain. The active NS records determine where DNS changes must be made; editing records at a registrar that is not authoritative will not change the live domain.

Each DNS record generally includes a name, record type, value, and TTL. The name identifies the domain or subdomain, the type describes the purpose, and the value points to an address, hostname, mail server, or verification string. TTL, or time to live, tells recursive DNS resolvers how long they may cache the answer. A lower TTL can make planned changes easier to adjust, while a higher TTL can reduce repeated lookups. Your DNS provider may display the root domain as @, leave it blank, or show the full domain name, so follow that provider’s field format.

• A: Points a hostname to an IPv4 address, such as 203.0.113.10.
• AAAA: Points a hostname to an IPv6 address.
• CNAME: Points a subdomain to another hostname, such as www.example.com to example.com.
• MX: Specifies which mail servers receive email for a domain, using a priority value.
• TXT: Stores text used for domain verification, email authentication, and other service instructions.
• NS: Identifies the authoritative DNS nameservers for a domain or delegated subdomain.
• SRV: Defines the hostname and port for services that publish connection details, often using a service and protocol name.

DNS is separate from web hosting, although the two work together. A hosting account contains website files and databases; DNS directs visitors to that hosting environment. For broader migration planning, see How to Move a Website to New Hosting Without Downtime.

Checklist by scenario

Point a domain to a website

1. Confirm whether the host gave you an IPv4 address, IPv6 address, nameservers, or a target hostname.
2. For an IPv4 address, create or update an A record for the root domain, commonly shown as @.
3. If the host supplied an IPv6 address, add the corresponding AAAA record.
4. Decide how www should work. A CNAME from www to the root domain is common, but use the host’s exact instructions when it requires a different target.
5. Remove conflicting records for the same hostname only after confirming they are no longer needed.
6. Check both the root domain and www over HTTPS after the change. DNS pointing alone does not guarantee that the site has a valid SSL configuration.

Create a subdomain

For a subdomain such as app.example.com, add a record with app as the name. Use an A or AAAA record when you have an IP address. Use a CNAME when the destination is another hostname supplied by a platform. Do not add a protocol such as https:// to an A or CNAME value. If the subdomain hosts a separate application, confirm that the application itself is configured to recognize the hostname.

Set up email

1. Obtain the mail provider’s complete MX instructions, including each server hostname and priority.
2. Remove obsolete MX records if the domain is being moved to a new provider. Multiple MX records are valid when intentionally configured, but leaving old and new providers together can produce inconsistent delivery.
3. Add the provider’s TXT records for SPF, DKIM, or domain verification exactly as supplied. SPF is normally published as one policy record for a domain; do not create competing SPF policies.
4. Check whether DKIM uses a selector subdomain such as selector1._domainkey. Copy the selector and value precisely.
5. Consider a DMARC TXT record after confirming the domain’s legitimate sending services. Begin with a monitoring-oriented policy if you are still inventorying senders, then tighten it only when you understand the results.

Verify ownership of a service

A platform may request a TXT record at the root domain or a named subdomain. Use the exact host and value provided by the platform, preserve punctuation, and avoid adding quotation marks unless the DNS interface requires them. Some services use a CNAME instead. After saving the record, return to the service and run its verification step; a DNS lookup alone may not complete the platform’s process.

Delegate a subdomain or configure a specialized service

Use NS records only when you intend to delegate DNS authority for a domain or subdomain to another DNS provider. SRV records are appropriate when a service publishes a protocol, hostname, port, and priority or weight. Their names and values are highly format-sensitive, so copy the provider’s example rather than improvising the field layout.

What to double-check

• Authoritative provider: Check the domain’s nameservers before making changes. This prevents edits in the wrong control panel.
• Record scope: Confirm whether the request applies to the root domain, www, a mail selector, or another subdomain.
• Value formatting: A record values are IP addresses; CNAME and MX values are hostnames. Do not confuse an IP address with a hostname or add a URL scheme.
• Trailing dots: Some DNS interfaces add a final dot to fully qualified hostnames automatically, while others expect you to enter the hostname without it.
• Conflicts: A hostname generally should not have a CNAME alongside other record types. Review existing records before adding a new one.
• TTL: Record the previous TTL before a planned migration and lower it ahead of time if your provider and change window justify doing so. Lowering TTL immediately before a change cannot control caches that already hold the older value.
• IPv6: An incorrect AAAA record can affect users on IPv6 networks even when the A record is correct. Add AAAA only when the IPv6 destination is configured and tested.

Use more than one checking method: the DNS provider’s record view, a command-line lookup such as dig or nslookup, and an external DNS lookup service. Query the record type you changed and test from more than one network when possible. For ongoing checks, the guidance in How to Monitor Website Uptime and Speed can help connect DNS changes with real website behavior.

Common mistakes

Editing the wrong DNS panel: The registrar may sell the domain while another provider hosts the authoritative DNS zone. Verify nameservers first.

Using a CNAME at the root when the provider does not support it: Some DNS platforms offer special root-domain alias features, while others require A records or nameservers. Follow the host’s documented method.

Replacing all records during a website change: A website migration may require only web records. Deleting MX, TXT, DKIM, or verification records can interrupt email and connected services.

Expecting instant propagation: DNS caches refresh according to TTL and resolver behavior. Avoid repeatedly changing values while waiting, because that makes troubleshooting harder and can extend uncertainty.

Copying a value incompletely: Long TXT and DKIM values are easy to truncate or alter. Copy them carefully and use the provider’s verification tool.

Testing only one hostname: Check the root domain, www, important subdomains, email delivery, and HTTPS separately. A successful website response does not prove that mail records are correct.

When to revisit

Review this DNS checklist before moving hosting, changing email providers, launching a new subdomain, connecting a third-party platform, or renewing a major application integration. It is also useful before seasonal planning cycles when traffic, campaigns, or operational ownership may change. Revisit the zone after a domain transfer, nameserver update, security incident, or unexplained email or website outage.

Keep a simple DNS change record with the date, person responsible, reason, old value, new value, TTL, and rollback plan. Export or document the current zone before a substantial change, and make sure backups cover the website files and database as well as DNS documentation. The related guide on How to Back Up a Website covers the application side of that preparation.

Before closing a change, use this final sequence: confirm the authoritative provider, save the existing configuration, make the smallest necessary edit, validate the published record, test the affected service, and document the result. When a change fails, restore the known-good value rather than making several experimental edits at once. This approach makes DNS management safer, easier to audit, and more repeatable as your domain and hosting setup evolves.