A and AAAA Records: Mapping Domains to IP Addresses
The A record is the most fundamental DNS record type. It maps a hostname to an IPv4 address — a 32-bit number written in dotted decimal notation like 93.184.216.34. When your browser resolves www.example.com, the final answer it needs is almost always an A record. A domain can have multiple A records pointing to different IP addresses for load balancing; resolvers return all of them and clients typically use the first.
The AAAA record (pronounced "quad-A") is the IPv6 equivalent, mapping a hostname to a 128-bit IPv6 address written in colon-separated hexadecimal like 2606:2800:220:1:248:1893:25c8:1946. A properly configured domain should have both A and AAAA records so that IPv6-capable clients can connect over IPv6 while older clients fall back to IPv4. Both record types carry a TTL that controls how long resolvers cache the mapping.
CNAME Records: Aliases and Canonical Names
A CNAME (Canonical Name) record maps one hostname to another hostname rather than directly to an IP address. For example, www.example.com might be a CNAME pointing to example.com. When a resolver encounters a CNAME, it follows the alias chain and performs an additional lookup for the target hostname until it arrives at an A or AAAA record with an actual IP address.
CNAMEs are invaluable for pointing subdomains to CDN or hosting provider hostnames that may change their IP addresses without notice. Instead of maintaining an A record you would need to update every time the CDN moves IPs, you point your subdomain to the CDN's stable hostname and let the CDN manage the IP-level mapping. One important constraint: a CNAME record cannot coexist with any other record at the same name — which means CNAMEs are forbidden at the zone apex where SOA and NS records are required.
MX Records: Email Routing
MX (Mail Exchanger) records direct email for a domain to the correct mail servers. When a mail server wants to deliver a message to user@example.com, it queries DNS for the MX records of example.com and connects to the listed mail exchangers in priority order. Each MX record contains a priority number (lower is higher priority) and a hostname pointing to the mail server.
For example, a domain might have MX records with priorities 10 and 20. The sending server always tries priority 10 first. If that server is unreachable or returns a temporary failure, the sender tries the priority-20 server. Multiple MX records with different priorities provide both redundancy and a clear failover order. Note that MX records must point to a hostname (an A or AAAA record), not directly to an IP address, and cannot be CNAMEs.
TXT Records: Verification and Email Authentication
TXT records store arbitrary text strings in DNS. Originally intended for human-readable information, they have become the standard mechanism for domain verification and email authentication because any organization can query them without special infrastructure.
The most common TXT record uses are: SPF (Sender Policy Framework), which lists IP addresses and hostnames authorized to send email for a domain; DKIM (DomainKeys Identified Mail) public keys, which email receivers use to verify cryptographic signatures on incoming messages; DMARC policies, which instruct receivers on how to handle emails that fail SPF or DKIM checks; and domain ownership verification strings from services like Google Search Console, AWS, and Cloudflare. A domain can have multiple TXT records at the same name.
NS and SOA Records: Zone Delegation and Authority
NS (Name Server) records specify which servers are authoritative for a DNS zone. Every domain must have at least two NS records for redundancy, and those NS records appear both in the domain's own zone and in the parent TLD zone as a delegation. Changing NS records at your registrar is the mechanism for moving your DNS hosting from one provider to another.
The SOA (Start of Authority) record is the administrative record that begins every DNS zone. It contains the primary nameserver hostname, the zone administrator's email address (with the @ sign replaced by a dot), a serial number that increments with every zone change, and four timing parameters that control zone transfer behavior between primary and secondary nameservers. The SOA minimum TTL field also controls how long resolvers cache negative responses (NXDOMAIN) for the zone.
PTR, SRV, and CAA Records
A PTR (Pointer) record performs reverse DNS — mapping an IP address back to a hostname. PTR records live in special reverse-DNS zones (in-addr.arpa for IPv4, ip6.arpa for IPv6) controlled by the IP address owner rather than the domain owner. PTR records are critical for email deliverability: receiving mail servers check that the sending IP's PTR record matches the sending hostname to filter spam.
SRV (Service) records specify the location of a service — hostname, port, priority, and weight — for protocols that support DNS-based service discovery. VoIP (SIP), XMPP instant messaging, and some gaming protocols use SRV records so that clients can find the correct server and port automatically rather than requiring manual configuration. The format is: priority, weight, port, target hostname.
CAA (Certification Authority Authorization) records specify which certificate authorities are permitted to issue TLS certificates for a domain. A CAA record with the value letsencrypt.org means only Let's Encrypt may issue certificates for that domain. CAAs are a defense against certificate misissuance by unauthorized CAs and have been checked by compliant CAs since 2017.
DNS Record Types Quick Reference
| Type | Purpose | Example Value | Typical TTL | Notes |
|---|---|---|---|---|
| A | Maps hostname to IPv4 address | 93.184.216.34 | 300–3600 s | Multiple records allowed for load balancing |
| AAAA | Maps hostname to IPv6 address | 2606:2800:220:1::1 | 300–3600 s | Should accompany A record for dual-stack |
| CNAME | Alias to another hostname | example.com. | 300–3600 s | Forbidden at zone apex; cannot mix with other types |
| MX | Mail server for domain | 10 mail.example.com. | 3600 s | Lower priority number = higher preference |
| TXT | Text data (SPF, DKIM, DMARC, verification) | v=spf1 include:_spf.google.com ~all | 300–3600 s | Multiple TXT records allowed at same name |
| NS | Authoritative nameservers for zone | ns1.cloudflare.com. | 86400 s | Minimum two required; must point to hostnames |
| SOA | Zone administrative parameters | ns1.example.com. admin.example.com. 2026050101 3600 900 604800 300 | N/A (authoritative) | One per zone; serial increments on each change |
| PTR | Reverse DNS (IP to hostname) | mail.example.com. | 3600 s | Controlled by IP owner, not domain owner |
| SRV | Service location (host + port) | 10 20 5060 sip.example.com. | 300–3600 s | Used by SIP, XMPP, some gaming protocols |
| CAA | Authorized certificate authorities | 0 issue "letsencrypt.org" | 3600 s | CAs must check before issuing TLS certs |
Frequently Asked Questions
What is the difference between A and CNAME records?
An A record maps a hostname directly to an IPv4 address. A CNAME record maps a hostname to another hostname — an alias. When a resolver encounters a CNAME, it follows the chain until it reaches a record with an actual IP address (an A or AAAA record). A records resolve in one step; CNAME records require at least two lookups. CNAME records are useful for pointing subdomains like www to a canonical hostname that may change IP addresses without requiring individual updates.
Can I use CNAME at the root/apex of a domain?
No. The DNS specification forbids CNAME records at the zone apex (the root of a domain, e.g. example.com without any subdomain) because an apex domain must have SOA and NS records, and a CNAME cannot coexist with any other record type at the same name. Many DNS providers work around this with proprietary record types — Cloudflare calls theirs CNAME Flattening, AWS calls it ALIAS — that resolve the target hostname to an IP at query time and return an A record, effectively behaving like a CNAME without the apex restriction.
What does an MX record priority number mean?
An MX record's priority number (also called preference) tells sending mail servers which mail exchanger to try first. Lower numbers indicate higher priority. A sending server always tries the lowest-priority-number MX record first. If that server is unreachable, it tries the next lowest, and so on. For example, if example.com has MX records with priorities 10 and 20, the priority-10 server is the primary mail server and the priority-20 server is the fallback.
What is a TXT record used for?
TXT records store arbitrary text strings in DNS and are used for a variety of domain verification and email authentication purposes. Common uses include SPF (Sender Policy Framework) records that list authorized mail senders for a domain, DKIM public keys that email receivers use to verify message signatures, DMARC policies that define how receivers should handle emails failing SPF or DKIM, and domain ownership verification strings required by Google Search Console, AWS, and other services.
What is a PTR record and why is it needed for email?
A PTR record maps an IP address back to a hostname — the reverse of what an A record does. PTR records live in the in-addr.arpa (IPv4) or ip6.arpa (IPv6) reverse DNS zones, which are controlled by the IP address's owner (usually the hosting provider or ISP), not the domain owner. PTR records matter for email because receiving mail servers perform a reverse DNS lookup on the sending server's IP and check whether the result matches the sending domain. A missing or mismatched PTR record is a strong spam signal and can cause legitimate email to be rejected.
What is a SOA record?
A SOA (Start of Authority) record is the first record in every DNS zone and defines administrative parameters for the zone. It contains the primary nameserver hostname, the responsible party's email address (with @ replaced by a dot), a serial number that increments with each zone change, and four timing values: refresh (how often secondary nameservers check for updates), retry (how long secondaries wait before retrying a failed refresh), expire (how long secondary data is valid if the primary is unreachable), and minimum TTL (used for negative caching of NXDOMAIN responses).