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 that internet services use. DNS management may be handled at your domain registrar, a dedicated managed DNS provider, or a hosting platform. Before changing anything, confirm where the domain’s authoritative nameservers point; that is the system whose DNS zone is actually answering queries.

A DNS record normally includes a name, record type, value, and TTL (time to live). The name identifies the host, such as the root domain or www. The type determines how the value should be interpreted. The value may be an IP address, another hostname, a mail server, or verification text. TTL tells caching resolvers how long they may retain the answer before checking again. A lower TTL can make planned changes easier to observe, while a longer TTL can reduce repeated lookups. The practical setting depends on your DNS provider and change plan.

Understanding the difference between an A record and a CNAME is especially important. An A record requires an IP address. A CNAME points to a hostname and follows that hostname’s DNS answer. In many DNS systems, a CNAME cannot coexist with other records at the same name, and the zone root has provider-specific limitations. Follow the exact format shown by your DNS provider or service documentation rather than copying a record from a different interface.

Checklist by scenario

Pointing a domain to web hosting

• Confirm whether the hosting provider requests an A record, AAAA record, CNAME, or nameserver change.
• Use the provider’s destination exactly, including whether the record belongs at the root domain, www, or another subdomain.
• Check for existing A, AAAA, or CNAME records at the same name before adding a new one.
• Keep existing email-related records unless you are intentionally moving email.
• Test both the root domain and www, and confirm that SSL covers every hostname visitors will use.

For a complete workflow, see How to Point a Domain to Web Hosting: DNS Records, Nameservers, and Propagation.

Configuring email

• Identify the mail provider’s required MX hostnames and priorities.
• Remove obsolete MX records only after confirming that no active mailbox depends on them.
• Review SPF, DKIM, and DMARC requirements separately. SPF is generally published as TXT, while DKIM uses a provider-supplied TXT or CNAME record and DMARC uses a TXT record at _dmarc.
• Check whether your provider gives one combined SPF policy. Multiple SPF records at the same domain can cause validation problems, so do not create a second policy without understanding how the entries should be combined.
• Send and receive test messages after the change and inspect authentication results where available.

Use the SPF, DKIM, and DMARC Setup Guide when reviewing domain email authentication.

Verifying a service or SaaS platform

• Copy the requested record type, host or name, and value precisely.
• Preserve punctuation, underscores, and trailing dots when the provider includes them.
• Do not place the full domain in the name field if your DNS interface automatically appends the domain.
• Wait for the service to detect the record, then remove temporary verification records only if the service permits it and you no longer need them.

Creating a subdomain

• Choose a clear name such as app, status, docs, or shop.
• Use an A or AAAA record when the subdomain has a fixed address, or a CNAME when the destination is another hostname.
• Confirm that the application, web server, and SSL configuration recognize the new hostname.
• Document who owns the subdomain and what service it supports.

What to double-check before saving

Start by export­ing or recording the current DNS zone. A simple change log should include the date, record name, old value, new value, reason, and person responsible. This makes rollback possible and helps distinguish a DNS issue from an application or hosting issue.

Check for conflicting records. A hostname should not normally have a CNAME alongside A or AAAA records, and duplicate MX, TXT, or verification records may produce unexpected results. Some DNS providers support special root-domain behavior, sometimes described as an alias or flattened CNAME. Treat that as provider-specific functionality rather than a universal DNS record.

Review nameservers before troubleshooting individual records. If the domain uses nameservers at one provider but you edit a zone at another, your changes may never become authoritative. A DNS propagation checker can show what different resolvers currently return, but it does not override caching or correct an incorrectly delegated zone.

Finally, plan the change around the service’s dependencies. A website migration may involve DNS, hosting, SSL, redirects, databases, monitoring, and backups. Review the Website Launch Infrastructure Checklist or the Cloud Hosting Backup and Disaster Recovery Checklist when the change is part of a larger launch or migration.

Common mistakes and propagation troubleshooting

• Editing the wrong DNS provider: Verify the active nameservers at the registrar or with a DNS lookup tool.
• Using an IP address in a CNAME: CNAME values should be hostnames. Use A or AAAA for an IP address.
• Replacing all records during a website move: Preserve MX, SPF, DKIM, DMARC, verification, and service records unless they are intentionally changing.
• Duplicating an existing record: Search the zone first, especially for SPF and MX entries.
• Assuming propagation is instant: Cached answers may remain visible for the duration of their TTL, and different resolvers may update at different times.
• Testing only one hostname: Check the root domain, www, important subdomains, and mail flow separately.
• Changing nameservers without a copied zone: Recreate required records at the new DNS provider before delegation changes, then verify the result.

If a change does not appear, query the record from more than one network, check the authoritative nameserver directly, inspect the record name for duplicated domain text, and confirm that the value matches the service’s instructions. If the DNS answer is correct but the site still fails, investigate hosting, firewall rules, application configuration, or SSL. For certificate-related symptoms, consult SSL Certificate Errors Explained.

When to revisit this DNS management checklist

Return to this guide before a hosting migration, domain transfer, email-provider change, new SaaS integration, subdomain launch, or certificate and security review. It is also useful before seasonal planning cycles when traffic, campaigns, or staffing changes make an outage more costly.

Review the zone periodically for abandoned verification records, unused subdomains, obsolete mail servers, unexpected changes, and undocumented ownership. Recheck provider-specific record formats, TTL guidance, email-authentication requirements, and propagation behavior whenever your DNS service changes its interface or workflow, and at least every six months if the zone supports important production systems.

Before your next change, use this short sequence: identify the authoritative nameservers, export the current records, write the intended change and rollback, lower TTL only if your plan benefits from it, make the smallest necessary edit, test each affected service, and record the final state. Protect the registrar and DNS accounts with strong unique credentials and appropriate multi-factor authentication; the Registrar Account Security Checklist provides a related review.