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 technical destinations that browsers and other services can use. Your domain registrar, DNS provider, and web host may be different companies, but DNS is the layer that connects them.

DNS management usually involves editing records inside a DNS control panel. Each record has a type, a name or host, a value, and often a time to live (TTL). The exact labels vary between providers, but the underlying concepts are consistent.

The main DNS records

• A: Points a hostname to an IPv4 address. A common example is an A record for @ pointing to a web server such as 203.0.113.10.
• AAAA: Points a hostname to an IPv6 address. Use it only when the destination is configured to accept IPv6 traffic.
• CNAME: Creates an alias from one hostname to another hostname. For example, www might point to example.com or to a provider-specific hostname.
• MX: Specifies which mail servers receive email for a domain. MX records include a priority value; lower numbers generally indicate a preferred destination.
• TXT: Stores text used for domain verification and email policies such as SPF, DKIM-related values, and DMARC.
• NS: Identifies the authoritative name servers for a domain or delegated subdomain. These records are normally controlled by the registrar or DNS host.
• CAA: Restricts which certificate authorities may issue TLS certificates for a domain. It is an optional security control that should be added only with a clear certificate-management plan.
• SRV: Publishes the hostname and port for specific services. Some collaboration, messaging, and directory systems require SRV records.
• TTL: Specifies how long resolvers may cache a response. TTL is a setting on a record rather than a record type.

Before changing anything, record the current configuration. Export the zone if your provider supports it, or capture the existing names, types, values, priorities, and TTLs. This makes rollback possible and prevents an unrelated record from being lost.

Checklist by scenario

Connecting a domain to a website

1. Confirm which DNS service is authoritative by checking the domain's name servers.
2. Ask the hosting provider whether it expects an A record, AAAA record, CNAME, or several records.
3. Use the root or apex name, often shown as @, for the main domain.
4. Create the requested record without deleting email, verification, or subdomain records.
5. Configure www separately if the provider requires it. A CNAME is common for a subdomain, but follow the host's instructions.
6. Check both the root domain and www in a browser after the change is visible.

Do not assume that changing the nameservers and changing individual records are the same task. Switching nameservers moves authority for the entire DNS zone. Editing an A or CNAME record changes only the specified hostname within the existing zone.

Setting up email

1. Collect the complete MX record list from the email provider, including priorities.
2. Remove obsolete MX records only when you are certain they no longer handle mail.
3. Add the provider's TXT records for sender authentication and domain verification.
4. Publish one deliberate SPF policy rather than creating several separate SPF records.
5. Add DKIM records exactly as supplied, including the selector and any required punctuation.
6. Add a DMARC TXT record after reviewing the provider's instructions and deciding where reports should go.
7. Send test messages in both directions and inspect the message authentication results where available.

For a fuller workflow, use the DNS email setup checklist covering MX, SPF, DKIM, and DMARC.

Completing domain or SSL verification

1. Identify whether the service requests a TXT, CNAME, or file-based verification method.
2. Enter the host exactly as specified. A provider may request _acme-challenge, a unique token, or a full hostname.
3. Preserve underscores, hyphens, quotation marks, and trailing punctuation when the provider requires them.
4. Wait for the record to become visible, then run verification from the service's dashboard.
5. After the certificate is issued, confirm that HTTPS works on the root domain and important subdomains.

DNS verification and SSL certificate installation are related but separate steps. A verification record can prove domain control, while the web server or hosting platform must still serve the certificate correctly. See the SSL certificate setup guide when HTTPS errors continue after DNS is correct.

Adding a subdomain

1. Choose a clear name such as app, docs, staging, or status.
2. Use an A or AAAA record for a fixed IP address, or a CNAME when the destination is another hostname.
3. Confirm that the hosting platform is configured to accept the new hostname.
4. Secure the subdomain with HTTPS if it handles visitors, credentials, or application data.
5. Review whether the subdomain should be public. Internal tools may need access controls in addition to DNS settings.

What to double-check

Names and formatting

DNS panels handle the root name differently. One provider may use @, while another may display the full domain or leave the field blank. Read the field description before entering a value. Avoid adding the domain twice if the panel automatically appends it.

Similarly, some panels expect only a hostname in the value, while others accept a fully qualified domain name. A CNAME intended for service.provider.example may be displayed with or without a final dot. Use the format documented by the provider and inspect the resulting record afterward.

Conflicting records

A hostname should not normally have a CNAME alongside an A, AAAA, or other incompatible data record. If www already has a CNAME, adding an A record for the same name may cause errors or inconsistent results. Review all records with the same name before saving.

Propagation and caching

DNS changes are not always visible everywhere at once. Recursive resolvers can retain an older response until its TTL expires, and local devices or networks may cache results as well. Test from more than one network and compare authoritative answers with recursive answers.

A propagation check can show whether a record is appearing in different locations, but it does not prove that the web server, mail server, or application is correctly configured. For a structured testing process, consult the DNS propagation checker guide.

Authoritative DNS

Make sure you are editing the active DNS provider. If the domain uses name servers at one provider but you edit a zone at another, your changes will not affect public DNS. This is one of the most common causes of a record appearing correct in a dashboard but failing in real-world tests.

Common mistakes

• Replacing the whole zone: Changing nameservers or importing a zone can remove records needed for email, verification, or subdomains. Save a backup first.
• Publishing multiple SPF records: SPF is designed as a single policy for a domain. Combine authorized senders according to the email provider's instructions.
• Pointing an A record to a hostname: A records require IP addresses. Use a CNAME when the destination is a hostname, unless the provider offers a specialized alias feature.
• Leaving old services active: Remove records for retired hosts only after confirming that no application, integration, or mailbox still depends on them.
• Testing only one hostname: The root domain, www, mail, staging, and application subdomains can use different records and different infrastructure.
• Changing several variables at once: Make one logical change, note the time and purpose, and test before proceeding. This makes failures easier to isolate.
• Ignoring account security: DNS controls can redirect web traffic, disrupt mail, or affect certificate issuance. Use strong account protection, limit administrative access, and review access when team responsibilities change.

When to revisit

Review DNS records before a domain transfer, hosting migration, website redesign, email-provider change, or SSL implementation. Also revisit them before seasonal planning cycles when traffic, campaigns, or temporary landing pages may introduce new subdomains.

Schedule a periodic inventory even when nothing appears broken. Compare active records with current services, document the owner and purpose of important entries, and remove records that no longer have a business or technical use. Review delegated subdomains, third-party verification tokens, mail authentication policies, and access to the DNS account.

When workflows or tools change, update the checklist rather than relying on memory. Provider dashboards may rename fields, deployment platforms may change their required targets, and applications may introduce new hostnames. Keep a dated change log with the record changed, previous value, new value, reason, and validation result.

Before your next DNS change: back up the zone, confirm the authoritative provider, identify dependencies, lower the TTL only if a shorter cache period is genuinely useful, make the smallest necessary edit, and test every affected service. If you need to investigate a complex response, an online DNS tool can help compare record types and resolver results; the DNS troubleshooting tools guide provides a starting workflow.