DNS Records Cheat Sheet: A, AAAA, CNAME, MX, TXT, and NS Records by Use Case

Overview

When you register a domain, the domain itself does not automatically point to a website or mailbox. DNS, or the Domain Name System, connects readable names such as example.com and www.example.com to servers and services. You manage these instructions at your DNS host, which may be your registrar, web host, or a separate provider.

Before editing records, identify where DNS is hosted. Check the domain's nameservers at the registrar, then make changes in the control panel operated by that DNS provider. Editing records in the wrong dashboard will not affect the live domain.

The examples below use example.com. Your provider may label the name field as Host, Name, or Record. For the root domain, many interfaces use @; some expect the full domain or leave the field blank. Follow the interface's format rather than copying a value blindly.

DNS records at a glance

TTL means time to live: the period a resolver may cache a response before checking again. It is not a guarantee that every network will update at exactly that time. Lower TTLs can make planned changes easier to manage, while higher TTLs can reduce repeated lookups. Avoid lowering TTL at the last minute and expecting every cached answer to disappear immediately.

Checklist by scenario

To connect a domain to a website

1. Confirm whether the hosting provider requests an A record, an AAAA record, a CNAME, or a nameserver change.
2. Use an A record when the provider gives you a fixed IPv4 address. For example, set the root name to 203.0.113.10.
3. Use an AAAA record only when the host supplies an IPv6 address that is configured for your site.
4. Use a CNAME for a subdomain such as www when the provider gives you a hostname, such as sites.host.example.
5. Decide how the root domain and www should behave. If both are used, configure the hosting provider's recommended relationship and test both addresses.

A record versus CNAME is not simply a matter of preference. An A record contains an IP address; a CNAME contains another hostname. A CNAME generally cannot share the same name with ordinary records, and many DNS systems do not permit a conventional CNAME at the zone apex. This is why hosting instructions may provide different steps for example.com and www.example.com.

To set up email

1. Add every MX record supplied by your email provider, including its priority number. Lower numerical values generally indicate higher delivery preference.
2. Point each MX record to a hostname, not directly to an IP address. If the provider gives mail.example.net, enter that hostname.
3. Add the provider's TXT records for sender authorization, domain verification, DKIM, or DMARC as instructed.
4. Check whether the provider requires a particular host name, such as @, selector1._domainkey, or _dmarc.
5. Send a test message in both directions and inspect the message headers or provider diagnostics before treating the setup as complete.

TXT records are flexible, so their purpose depends on the value. SPF commonly begins with v=spf1, DKIM is normally published under a selector-specific name, and DMARC is normally published under _dmarc. Do not create multiple competing SPF policies at the same name; combine authorized senders according to the email provider's instructions. Long TXT values may be displayed as separate quoted strings by some interfaces, so preserve the provider's exact formatting.

To add a subdomain or third-party service

1. Choose a descriptive label, such as shop, app, docs, or status.
2. Use an A or AAAA record if the service provides an address, or a CNAME if it provides a hostname.
3. Add any verification TXT record at the exact label requested. A verification value at the root will not necessarily verify app.example.com.
4. Confirm whether the service also requires a redirect, custom-domain setting, TLS certificate, or application-level configuration.

For naming and site architecture considerations, see the guide to subdomains and subdirectories. DNS can direct traffic, but it does not automatically configure the application behind that traffic.

To delegate DNS or add a service that uses SRV records

Change NS records only when you intend to move authority for a domain or subdomain to another DNS provider. Use the complete nameserver set supplied by that provider, then verify that all existing website, email, verification, and security records have been recreated before switching.

SRV records are used by services that need more than a hostname, including a service name, protocol, priority, weight, port, and target. A provider may express the fields separately or provide a value such as 10 5 443 service.example.net. Copy the service and protocol labels exactly; an underscore in names such as _service._tcp is significant.

What to double-check

• Authority: Verify the active nameservers before editing. This is the first item in any DNS setup guide.
• Record name: Distinguish the root domain, www, and service labels such as _dmarc. Some dashboards append the domain automatically.
• Value type: Enter an IP address in A or AAAA records and a hostname in CNAME or MX targets. Do not add a URL such as https:// unless specifically requested.
• Duplicate records: Check for old A, AAAA, CNAME, MX, or TXT records that conflict with the new service. Do not delete records simply because they look unfamiliar; identify their purpose first.
• Trailing dots: DNS documentation may show fully qualified names ending in a dot, such as mail.example.net.. Many interfaces add or omit this punctuation automatically.
• TTL and propagation: Query the record from more than one DNS checker or resolver after saving. Cached answers can differ during a transition.
• Application settings: Confirm the domain inside the website host, email platform, certificate manager, or third-party service as well as in DNS.

If you are connecting hosting after buying a domain, compare the provider's requested records with the steps in this domain-to-hosting checklist. If you are moving DNS to a separate provider, review the DNS migration process before changing nameservers.

Common mistakes

• Adding a CNAME to the root without checking support: The DNS provider may require an A record, an ALIAS-style feature, or nameserver-based setup instead.
• Putting a URL in an A record: A records accept IPv4 addresses, not website addresses or paths.
• Using an MX record with an IP address: MX targets should be hostnames that resolve separately.
• Overwriting email records while connecting a website: Website records and mail records serve different purposes. Preserve MX, DKIM, SPF, and DMARC records unless the mail provider tells you to change them.
• Publishing several SPF TXT records: Consolidate the policy into the single SPF record expected at that domain name.
• Changing nameservers without copying records: A nameserver change can make the new DNS zone authoritative before it contains the old zone's necessary records.
• Assuming propagation means failure: A cached result, a local resolver, or an unconfigured third-party dashboard can explain different answers. Test the authoritative DNS and the public result separately.
• Deleting verification records after setup: Some services check ownership again later. Keep records that remain part of an active service's instructions.

When to revisit

Return to this checklist whenever you launch a website, add a subdomain, change email providers, introduce a SaaS tool, renew a certificate, or move DNS authority. Revisit it before seasonal campaigns and other planned traffic increases so you have time to lower TTLs, test changes, and restore a known-good configuration if needed.

Keep a simple DNS inventory with the record name, type, purpose, provider, date added, and owner. Save the provider's setup instructions and note which records are safe to remove. Review that inventory when teams, hosting platforms, or security tools change.

For a final pre-change check, confirm the active nameservers, export or record the current zone, identify website and email dependencies, apply only the requested records, and test from an external DNS checker. After the change, verify the website, mail delivery, subdomains, certificates, and service dashboards. This short routine makes DNS changes more predictable and gives you a clear recovery path when workflows or tools change.