DNS Records Explained: A, AAAA, CNAME, MX, TXT, NS, and SRV
You can think of DNS records as typed instructions that tell resolvers where to connect and how to handle services for a domain name. Each record type exists for a narrow purpose; using the right one saves you from intermittent failures that are hard to trace. We’ll walk through A, AAAA, CNAME, MX, TXT, NS, and SRV with plain examples you can copy and adapt.
DNS is hierarchical and cached. That means small errors propagate quickly and then stick around until time to live (TTL) expires. So we’ll call out common pitfalls—like pointing an MX to an IP or putting a CNAME at the zone apex—that are easy to miss but costly in production.
When you create or change records, always ask three questions: what exact owner name am I editing, what value format does this type require, and do I have conflicting data at this name. Those three checks prevent most issues before they ship.
Understanding Core DNS Records
At a high level, A and AAAA map names to IP addresses, CNAME creates an alias from one name to another, MX routes email, TXT carries arbitrary text used by policies like SPF, DKIM, and DMARC, NS delegates authoritative nameservers, and SRV advertises service endpoints with priority, weight, port, and target host. All of them share two levers you’ll set often: the owner name (left side) and TTL (how long resolvers cache answers).
A and AAAA Records
An A record maps a hostname to an IPv4 address; AAAA maps a hostname to an IPv6 address. You can publish multiple A or AAAA records at the same name to enable basic load distribution (authoritative servers typically permute the order of addresses). Use A/AAAA for any host you want clients to reach directly—web, API, mail hosts, and so on.
Syntax and Examples
Examples you can adapt: `example.com. 3600 IN A 203.0.113.10`, `www.example.com. 300 IN A 203.0.113.11`, `api.example.com. 300 IN AAAA 2001:db8:abcd::50`. If your DNS UI omits the trailing dot, entering `example.com` as a name may be auto-suffixed; values that are IPs never get dots.
Common Pitfalls
Don’t mix up name and value: A/AAAA values must be literal IPs, not hostnames. Avoid overly long TTLs during migrations; 300–600 seconds makes rollbacks manageable. Be careful with the apex record (the bare domain): some providers emulate a CNAME there with ALIAS/ANAME or CNAME flattening, but a standard CNAME can’t coexist with other data at the apex.
CNAME Records
A CNAME makes one DNS name an alias of another canonical name. Resolvers replace the alias with the target and then continue resolving, so the target must itself resolve to A/AAAA (or another chain ending in A/AAAA). Use CNAME when you want `www` to track the same destination as the apex, or when a vendor gives you a branded target like `customer.vendor.net`.
Syntax and Examples
Examples: `www.example.com. 300 IN CNAME example.com.`, `assets.example.com. 300 IN CNAME d111111abcdef8.cloudfront.net.`. The CNAME value is a hostname, not an IP address, and typically ends with a dot in zone-file notation to make it absolute.
Common Pitfalls
Never put a CNAME at a name that already has other records (like A, MX, TXT). The DNS standard forbids mixing CNAME with any other data at the same owner, and by definition you can’t place a CNAME at the zone apex because the apex must host SOA and NS. If you need “CNAME-like” behavior at the apex, use your provider’s ALIAS/ANAME or flattening feature.
MX Records
MX records route email by pointing to mail hosts with a numeric preference (lower is higher priority). Each mail host you publish in MX must itself have A/AAAA records and must not be a CNAME. Mail transfer agents try the lowest preference first and fail over to higher numbers on error.
Syntax and Examples
Examples: `example.com. 3600 IN MX 10 mail1.example.com.`, `example.com. 3600 IN MX 20 mail2.backup.example.net.`. Then create hosts: `mail1.example.com. 600 IN A 198.51.100.25` and optionally `IN AAAA 2001:db8:abcd::25`.
Common Pitfalls
Pointing an MX directly to an IP (like `10 198.51.100.25`) is invalid—targets must be hostnames and must not be aliases. For outbound deliverability, ensure your sending IPs have valid reverse DNS (PTR) that maps to a hostname which in turn resolves forward to the same IP; many receivers expect this and penalize mail lacking it.
TXT Records (SPF, DKIM, DMARC)
TXT is a generic container for text; today it most often carries sender authentication policies. SPF declares which hosts can send mail for a domain, DKIM publishes the public key used to verify signed headers, and DMARC sets alignment and reporting rules on top of SPF/DKIM results. All three work together to raise deliverability and block spoofing.
Syntax and Examples
SPF example at the apex: `example.com. 300 IN TXT "v=spf1 ip4:198.51.100.0/24 include:_spf.example.net ~all"`. DKIM lives at a selector subdomain: `selector1._domainkey.example.com. 300 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."`. DMARC uses a fixed label: `_dmarc.example.com. 300 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; aspf=s; adkim=s"`.
Common Pitfalls
Keep each TXT character-string under 255 bytes; long values should be split into multiple quoted strings that DNS joins. SPF evaluation has a hard limit of 10 DNS-querying mechanisms/modifiers (include, a, mx, ptr, exists, redirect); plan your includes accordingly. Use `~all` (softfail) while testing and switch to `-all` once you’re confident.
NS Records
NS records delegate authority for a zone. At the parent zone (the registry), NS glue tells resolvers which nameservers host your domain; inside your zone, matching NS records advertise the same set. Each nameserver hostname must itself resolve to A/AAAA, and in-bailiwick names typically require glue at the parent so resolvers can reach them.
Syntax and Examples
Inside your zone file: `example.com. 172800 IN NS ns1.dns-host.net.`, `example.com. 172800 IN NS ns2.dns-host.net.`. For vanity nameservers, add hosts like `ns1.example.com. IN A 203.0.113.53` and register them as glue at the parent.
Common Pitfalls
Don’t forget to update both parent and child NS sets; mismatches cause random-looking failures. Avoid pointing NS to CNAMEs; authoritative nameserver names must be real hostnames with A/AAAA, not aliases.
SRV Records
SRV advertises the location of specific services under a domain, including priority, weight (load share among equal priority), port, and target host. Many protocols use SRV for discovery—SIP, XMPP, LDAP, Kerberos, and others.
Syntax and Examples
Owner names include a service and protocol prefix: `_
Common Pitfalls
SRV targets must be hostnames with A/AAAA, not IPs; don’t append ports to the target hostname. Weight semantics trip people up: if any record at a given priority has a positive weight, entries with weight 0 get 0% selection; if all weights are 0, clients choose uniformly at random.
How to Verify and Troubleshoot
Work from the outside in. Query the exact owner name you added, confirm the answer type, check that TTL matches what you set, and then follow the chain: for CNAME or MX/SRV, resolve the targets and ensure they end in A/AAAA. Test both IPv4 and IPv6 paths. When records don’t appear, suspect caching (respect TTL), delegation mismatches (NS at parent vs child), or conflicting data (a CNAME coexisting with other records).
For planned changes, cut TTL to 300 well in advance, deploy new targets, verify reachability, then switch traffic and raise TTL once stable. Document intent per record—why the TTL is low, why weight is 0 on a backup SRV—so the next person doesn’t “clean up” what looks odd but is actually required.