DNS Record Types Explained: A, AAAA, CNAME, MX, TXT & More

DNS (Domain Name System) records are instructions stored on authoritative DNS servers that provide information about a domain. They map human-readable domain names to IP addresses, direct email to the right servers, verify domain ownership, and much more.

Every domain has multiple DNS records of different types, each serving a specific purpose. Understanding these record types is essential for managing websites, email, and other domain-related services. You can look up DNS records for any domain using LookMyIP's DNS Lookup tool at lookmyip.com/dns.

The A record is the most fundamental DNS record type. It maps a domain name to an IPv4 address. When someone types your domain into a browser, the DNS resolver looks up the A record to find the server's IP address.

Example: example.com → 93.184.216.34

You can have multiple A records for the same domain pointing to different IP addresses. DNS will round-robin between them, providing basic load balancing.

A records are what you update when migrating your website to a new server.

The AAAA record (pronounced "quad-A") is the IPv6 equivalent of the A record. It maps a domain name to an IPv6 address.

Example: example.com → 2606:2800:0220:0001:0248:1893:25c8:1946

As IPv6 adoption grows, it's increasingly important to have AAAA records alongside your A records. Most modern hosting providers and CDNs support IPv6 and can provide AAAA records automatically.

A CNAME record creates an alias from one domain name to another. Instead of pointing to an IP address, it points to another domain name, which is then resolved to an IP.

Example: www.example.com → example.com blog.example.com → mysite.wordpress.com

CNAME records are commonly used to:

• Point "www" to the root domain
• Connect subdomains to third-party services (like a blog platform or CDN)
• Simplify management when one server hosts multiple services

Important limitation: You cannot place a CNAME record at the root/apex of your domain (e.g., example.com). CNAME records can only be used on subdomains. Some DNS providers offer workarounds like ALIAS or ANAME records for this purpose.

MX records specify which mail servers handle email for a domain. Each MX record has a priority value — lower numbers mean higher priority.

Example: example.com MX 10 mail1.example.com example.com MX 20 mail2.example.com

The sending mail server tries the highest-priority (lowest number) server first. If it's unavailable, it falls back to the next one. This provides redundancy for email delivery.

For a detailed guide on MX records and email routing, see our guide on MX Records Explained.

TXT records store arbitrary text data associated with a domain. While originally designed for human-readable notes, they're now primarily used for machine-readable purposes:

SPF (Sender Policy Framework): Specifies which mail servers are authorized to send email on behalf of your domain. Example: v=spf1 include:_spf.google.com ~all

DKIM (DomainKeys Identified Mail): Contains a public key used to verify email signatures.

DMARC: Defines how receiving servers should handle emails that fail SPF or DKIM checks.

Domain verification: Services like Google Workspace, Microsoft 365, and various SaaS tools ask you to add a TXT record to prove you own the domain.

Security policies: Records like CAA (Certificate Authority Authorization) control which CAs can issue SSL certificates for your domain.

NS records specify which DNS servers are authoritative for a domain. These are the servers that hold the definitive DNS records for the domain.

Example: example.com NS ns1.cloudflare.com example.com NS ns2.cloudflare.com

When you register a domain or change DNS providers, you update the NS records at your registrar to point to your chosen DNS provider's nameservers. NS records are critical — if they're misconfigured, your entire domain (website, email, everything) stops working.

SOA (Start of Authority): Contains administrative information about the zone, including the primary nameserver, the responsible party's email, and timing parameters for zone transfers and caching.

SRV (Service Record): Specifies the host and port for specific services. Used by protocols like SIP, XMPP, and Microsoft Active Directory. Example: _sip._tcp.example.com SRV 10 5 5060 sipserver.example.com

PTR (Pointer Record): The reverse of an A record — maps an IP address to a hostname. Used in reverse DNS lookups. PTR records are essential for email servers, as many receiving servers reject email from IPs without valid PTR records.

CAA (Certificate Authority Authorization): Specifies which Certificate Authorities are allowed to issue SSL/TLS certificates for the domain. Helps prevent unauthorized certificate issuance.

This is the single most common DNS design problem, and it has no clean solution in the original specification.

CNAME records cannot coexist with any other record at the same name. RFC 1034 is explicit about it. Your apex domain — example.com with no subdomain — must have NS records and an SOA record, because that is what makes it a zone. Therefore the apex can never hold a CNAME.

That collides directly with modern hosting. Vercel, Netlify, Heroku, AWS load balancers and most CDNs all give you a hostname rather than a fixed IP address, precisely so they can move traffic between machines without asking you to change DNS. They want you to CNAME to them. At www.example.com that is fine. At example.com it is illegal.

Four workarounds exist, in rough order of preference:

Provider-specific flattening. Cloudflare's CNAME Flattening, Route 53's ALIAS records, DNSimple's ALIAS, and NS1's linked records all accept a hostname at the apex and resolve it server-side, returning A records to the client. The zone stays specification-compliant because no CNAME is ever published. This is the correct answer when your DNS provider supports it, and most now do.

HTTP redirect from apex to www. Point the apex at a small redirect service by A record and serve a 301 to www. Perfectly valid, adds one round trip to the first request.

Static A records. Only viable if your host publishes stable IPs and commits to them. GitHub Pages does; most CDNs explicitly do not, and hard-coding their current IPs will eventually break silently.

Use www as the canonical hostname. The oldest answer, and still defensible. Redirect apex to www rather than the other way round.

The forthcoming SVCB/HTTPS record types are designed to solve this properly, and browser support is now broad, but registry and provider support is still uneven enough that flattening remains the practical choice.

Beyond the everyday record types, a handful appear only in specific situations — usually when a service is failing and you are reading the zone closely for the first time.

CAA — Certification Authority Authorization. Lists which CAs are permitted to issue certificates for your domain. Every public CA is required to check it before issuance since 2017.

example.com.  IN  CAA  0 issue "letsencrypt.org"
example.com.  IN  CAA  0 issuewild ";"
example.com.  IN  CAA  0 iodef "mailto:security@example.com"

That set permits Let's Encrypt to issue standard certificates, forbids wildcard issuance entirely, and asks CAs to report policy violations. If a certificate request suddenly fails with a CAA error, someone added one of these and forgot the CA you actually use.

SRV — Service records. Publish the host and port for a named service, used heavily by SIP, XMPP, Minecraft and Microsoft 365 autodiscover. The format packs a lot into one line:

_sip._tcp.example.com.  IN  SRV  10 60 5060 sipserver.example.com.

That is priority 10, weight 60, port 5060, target sipserver. Weight distributes load among equal-priority targets proportionally.

PTR — Reverse lookup. Maps an IP back to a hostname, published in the in-addr.arpa (IPv4) or ip6.arpa (IPv6) zone. Critically, you cannot set this in your own zone file — it lives in a zone controlled by whoever owns the IP block, meaning your hosting provider. This surprises people setting up mail servers, where a missing PTR causes widespread rejection.

SOA — Start of Authority. One per zone, holding the serial number, the refresh and retry intervals for secondary nameservers, and the negative-caching TTL. The last field is the one worth knowing: it controls how long NXDOMAIN answers are cached, and a high value is why a newly created record can appear missing for hours.

DS and DNSKEY. The DNSSEC chain of trust. The DNSKEY lives in your zone; the DS record is a hash of it, published one level up at your registrar. A mismatch between them takes the entire domain offline for validating resolvers — see the DNSSEC checker.

Reading a complete zone is the fastest way to see how the record types fit together. Here is a realistic small-business zone, annotated:

$ORIGIN example.com.
$TTL 3600

@       IN  SOA  ns1.example.com. admin.example.com. (
                 2026080201 ; serial (YYYYMMDDnn)
                 7200       ; refresh
                 3600       ; retry
                 1209600    ; expire
                 300 )      ; negative cache TTL

@       IN  NS   ns1.example.com.
@       IN  NS   ns2.example.com.

@       IN  A     192.0.2.10
@       IN  AAAA  2001:db8::10
www     IN  CNAME example.com.

@       IN  MX    1 smtp.google.com.
@       IN  TXT   "v=spf1 include:_spf.google.com ~all"
_dmarc  IN  TXT   "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
google._domainkey IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."

@       IN  CAA   0 issue "letsencrypt.org"

api     IN  A     192.0.2.20
docs    IN  CNAME example.github.io.

Several conventions are worth noting. @ is shorthand for the zone apex. The trailing dots are mandatory — smtp.google.com without one would be interpreted as smtp.google.com.example.com, which is the most common zone-file error there is. The serial number uses the date-plus-counter convention so it always increases, which is what tells secondary nameservers to pull a fresh copy.

Note also that www is a CNAME to the apex rather than a duplicate A record. That means changing the server IP requires editing one record, not two, and the two names can never drift out of sync.

Should I use A records or CNAME records for subdomains?

CNAME when the target is a hostname managed by someone else, because they can change the underlying IP without involving you. A records when you control the IP directly and want to avoid the extra resolution step. Never CNAME at the apex.

Can one name have multiple A records?

Yes, and it is a common poor-man's load balancer. Resolvers typically return them in rotating order and clients try the first. Be aware this gives you distribution but not health checking — a dead IP in the set will still be handed out.

What TTL should I use?

3600 for stable records, 300 for anything you are about to change, 86400 for records that essentially never change such as NS and MX at a settled provider. Very low TTLs increase query load and remove your buffer during a DNS provider outage.

Why is my TXT record split into two parts?

Individual character strings in a TXT record are limited to 255 bytes. Longer values, typically DKIM keys, are published as multiple concatenated strings. Resolvers join them automatically, so "part1" "part2" is read as one value. Do not add spaces between the parts.

How many DNS records can a domain have?

There is no protocol limit, but a UDP DNS response above 512 bytes requires EDNS0 or falls back to TCP. Zones with many records at one name — long SPF includes, several TXT records — can produce large responses that some restrictive firewalls drop, causing intermittent resolution failures that are miserable to diagnose.