DNS Record Types
DNS Record Types Explained: A, AAAA, CNAME, MX, TXT, NS & More
11 min read · Updated 2026-06-19
Every DNS zone is just a collection of records — small typed entries that answer a specific kind of question about a name. One record type points a hostname at an IP address, another lists your mail servers, another carries the text that proves you own a domain. Knowing which record does what is the difference between confidently editing a zone and guessing.
This guide is the hub for the record types you will meet in practice. For each one you get what it does, its rough format, a concrete example, and the gotchas that trip people up. You can see all of these live for any domain with a DNS lookup.
Records at a glance
DNS defines dozens of record types, but a handful do almost all the real work. Here is the short list, with the rest of this guide covering each in detail.
| Type | Maps / carries | Typical use |
|---|---|---|
A | Name to IPv4 address | Point a hostname at a server |
AAAA | Name to IPv6 address | IPv6 equivalent of A |
CNAME | Name to another name (alias) | Alias one host to another |
MX | Mail servers and priority | Route inbound email |
TXT | Arbitrary text | SPF, DKIM, DMARC, verification |
NS | Authoritative nameservers | Delegate a zone |
SOA | Zone authority and timers | One per zone, defines the zone |
PTR | IP address to name | Reverse DNS |
SRV | Service location | Find a service host and port |
CAA | Allowed certificate authorities | Control who can issue TLS certs |
Every record also has a name, a type, a TTL (how long resolvers may cache it), and type-specific data. The TTL governs how quickly a change takes effect — see TTL and propagation.
A — IPv4 address
An A record maps a hostname to a single IPv4 address (a 32-bit address written as four dotted decimals). It is the most fundamental record on the web: when a browser needs to reach example.com, it asks for the A record to learn which server to connect to.
Format: a name, the type A, a TTL, and one IPv4 address. A name can have several A records to spread traffic across multiple servers.
Example:
example.com. 3600 IN A 198.51.100.10www.example.com. 3600 IN A 198.51.100.10
Notes: A records hold the IP literally, so if your server's address changes you must update every A record that points to it. For the IPv6 counterpart and a deeper walkthrough, see A and AAAA records.
AAAA — IPv6 address
An AAAA record (spoken "quad-A") is the IPv6 version of an A record. It maps a name to a 128-bit IPv6 address — four times the bits of an IPv4 address, which is why the type has four As. The format and meaning are otherwise identical to an A record; clients that support IPv6 prefer the AAAA answer.
Example:
example.com. 3600 IN AAAA 2001:db8::10
Notes: publishing both A and AAAA records for the same name is normal and recommended — clients pick whichever protocol they can use. Only publish an AAAA record if the destination actually answers over IPv6, or IPv6-capable clients may stall trying to reach a dead address. For the difference between the two address families, see IPv4 vs IPv6.
CNAME — canonical name (alias)
A CNAME record makes one name an alias for another name — never for an IP address. When a resolver hits a CNAME, it restarts the lookup against the target name and follows its records. This is handy for pointing www.example.com at a platform hostname, or aliasing several subdomains to one canonical host you can repoint in a single place.
Format: a name, the type CNAME, a TTL, and a single target hostname.
Example:
www.example.com. 3600 IN CNAME webhost.example.net.
Two gotchas that catch everyone:
- A name that has a CNAME can have no other records of any type at that name — no A, no MX, no TXT alongside it. The CNAME must stand alone.
- You cannot put a CNAME at the zone apex/root (the bare
example.comwith no subdomain), because the apex already carries mandatory SOA and NS records, and a CNAME forbids co-existing records. To alias the root, use a provider feature such as ALIAS, ANAME, or "CNAME flattening", which resolves the target and serves the resulting A/AAAA records at the apex.
See CNAME records for the full treatment, and A and AAAA records for the difference between aliasing a name and pointing at an IP.
MX — mail exchangers
An MX record tells the world which mail servers accept email for a domain. Each MX record pairs a priority (also called preference) with a mail server hostname. When someone sends you mail, the sending server tries the MX with the lowest priority number first — lower means more preferred — and falls back to higher numbers if it cannot connect.
Format: a name, the type MX, a TTL, a priority number, and a target hostname.
Example:
example.com. 3600 IN MX 10 mail1.example.com.example.com. 3600 IN MX 20 mail2.example.com.
Here mail1 (priority 10) is tried first; mail2 (priority 20) is the backup. Equal priorities are load-balanced.
Notes: the MX target must be a hostname with its own A/AAAA records — it must never point to a CNAME, and never to an IP address directly. A missing or wrong MX is one of the most common causes of lost inbound mail. See MX records for setup details, and pair them with the email-authentication records below.
TXT — text records
A TXT record holds arbitrary text attached to a name. On its own it means nothing to DNS, but specific systems read TXT records as configuration. Today TXT records carry most of email authentication and most domain-ownership proofs.
Format: a name, the type TXT, a TTL, and one or more quoted strings.
Common uses:
- SPF — lists which servers may send mail as your domain:
example.com. IN TXT "v=spf1 include:_spf.example.net -all" - DKIM — publishes the public key that signs your outbound mail, on a selector subdomain.
- DMARC — sets policy for messages that fail SPF/DKIM:
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com" - Domain verification — many services ask you to publish a one-off TXT token to prove control of the domain.
Notes: a single string in a TXT record is capped at 255 characters; longer values (common for DKIM keys) are split into several quoted chunks that resolvers concatenate. The full email trio is covered in SPF, DKIM and DMARC.
NS — nameserver delegation
NS records name the authoritative nameservers for a zone — the servers that hold the real answers for that domain. They appear in two places: in the parent zone, where they delegate the child zone, and inside the zone itself, where they declare its own authoritative servers.
Format: a name (the zone being delegated), the type NS, a TTL, and a nameserver hostname. A zone normally lists at least two NS records for redundancy.
Example:
example.com. 86400 IN NS ns1.example-dns.net.example.com. 86400 IN NS ns2.example-dns.net.
Notes: the NS records at your registrar (the parent's delegation) must match the nameservers actually serving your zone, or lookups break. Changing nameservers moves the whole zone to a new provider. You can inspect a domain's delegation with a nameserver lookup; for the full picture see nameservers and NS records.
SOA — start of authority
The SOA record ("start of authority") defines a zone. There is exactly one SOA per zone, and it sits at the apex. It records the primary nameserver, the responsible party's email, and the timers that secondary servers and resolvers use to stay in sync.
Key fields:
- MNAME — the primary (master) nameserver for the zone.
- RNAME — the administrator's email, with the
@written as a dot (e.g.hostmaster.example.com.). - Serial — a version number you must increase on every edit so secondaries know to refresh.
- Refresh — how often secondaries check for a new serial.
- Retry — how long to wait before retrying a failed refresh.
- Expire — how long a secondary keeps serving if it cannot reach the primary.
- Minimum — the negative-caching TTL: how long resolvers cache "this name does not exist".
Notes: if you forget to bump the serial after editing a zone, secondary servers may keep serving stale data. Most managed DNS providers update the SOA serial for you automatically.
PTR — reverse DNS
A PTR record does the reverse of an A/AAAA record: it maps an IP address back to a name. This is "reverse DNS", and it lives in special zones — in-addr.arpa for IPv4 and ip6.arpa for IPv6 — where the address is written backwards as a name.
Example: the PTR for 198.51.100.10 is stored at 10.100.51.198.in-addr.arpa:
10.100.51.198.in-addr.arpa. 3600 IN PTR mail1.example.com.
Notes: PTR records are controlled by whoever owns the IP block (typically your hosting provider or ISP), not by your domain's DNS, so you usually request them rather than edit them yourself. They matter most for mail: many receivers reject or distrust sending servers whose IP has no matching reverse DNS. You can check the reverse record for an address with an IP lookup.
SRV — service location
An SRV record advertises where a particular network service lives — both its host and its port — so clients do not have to assume a fixed location. Protocols like SIP, XMPP, LDAP, and Minecraft use SRV to discover servers.
Format: the name encodes the service and protocol as _service._proto.domain, and the data carries four values: priority, weight, port, and target host.
Example:
_sip._tcp.example.com. 3600 IN SRV 10 60 5060 sipserver.example.com.
That reads: for SIP over TCP, use priority 10, relative weight 60, connect on port 5060 at sipserver.example.com.
Notes: as with MX, lower priority wins; among equal priorities, weight distributes load proportionally. The target must be a real hostname with A/AAAA records, not a CNAME or an IP.
CAA — certificate authority authorization
A CAA record states which certificate authorities (CAs) are allowed to issue TLS/SSL certificates for your domain. Public CAs are required to check CAA before issuing, so it is a simple guard against an unauthorized CA being tricked into issuing a certificate for your name.
Format: a name, the type CAA, a TTL, a flags byte, a tag (issue, issuewild, or iodef), and a value.
Example:
example.com. 3600 IN CAA 0 issue "letsencrypt.org"example.com. 3600 IN CAA 0 iodef "mailto:security@example.com"
This permits only Let's Encrypt to issue certificates and asks CAs to report policy violations to your security address.
Notes: if you publish a CAA record, make sure it includes every CA you actually use, including any your hosting platform or CDN uses on your behalf — otherwise certificate renewals can silently fail. With no CAA record at all, any compliant CA may issue.
Key takeaways
- A records map a name to an IPv4 address; AAAA records map a name to an IPv6 address.
- CNAME aliases one name to another name (never an IP), must stand alone, and cannot live at the zone apex — use ALIAS/ANAME or flattening for the root.
- MX lists your mail servers with a priority; the lowest priority number is tried first.
- TXT records carry arbitrary text and power SPF, DKIM, DMARC, and domain verification.
- NS delegates a zone to its authoritative nameservers; SOA defines the zone with its serial and timers, one per zone.
- PTR is reverse DNS (IP to name) in in-addr.arpa / ip6.arpa; SRV locates a service and port; CAA controls which CAs may issue certificates.
Look up DNS records
See every DNS record type for any domain — A, AAAA, CNAME, MX, TXT, NS and more — with one lookup.
Frequently asked questions
What is the difference between an A record and a CNAME?▾
An A record points a name directly at an IP address. A CNAME points a name at another name, and the resolver then follows that target's records. Use an A record when you know the IP; use a CNAME when you want a subdomain to track whatever address another hostname resolves to. Remember a CNAME cannot coexist with other records and cannot sit at the zone apex. See CNAME records.
Can I put a CNAME at the root/apex of my domain?▾
No. The zone apex (the bare example.com) must carry SOA and NS records, and a CNAME is not allowed to coexist with any other records at the same name. To get CNAME-like behavior at the root, use a provider feature such as ALIAS, ANAME, or CNAME flattening, which resolves the target and serves the resulting A/AAAA records at the apex.
Which DNS records do I need for a typical website?▾
For a basic site with email you usually need: an A record (and an AAAA if you support IPv6) for the apex and www, or a CNAME on www pointing to your host; NS records delegating the domain (set at your registrar); the SOA your provider creates automatically; MX records plus TXT records for SPF/DKIM/DMARC if you send mail; and optionally a CAA record to lock down certificate issuance. You can confirm what is published with a DNS lookup.
How many DNS record types are there?▾
Dozens are formally registered with IANA, but only around ten do nearly all everyday work: A, AAAA, CNAME, MX, TXT, NS, SOA, PTR, SRV, and CAA. Others — like DNSKEY, DS, and RRSIG for DNSSEC, or NAPTR and TLSA — show up in more specialized setups. You rarely need to touch a type outside the core ten.
Why does the MX with the lowest number get used first?▾
The number on an MX record is a priority (preference), and by design lower means more preferred. A sending server sorts your MX records and tries the lowest number first, falling back to higher numbers only if it cannot connect. So an MX at priority 10 is your primary and one at priority 20 is the backup. Equal numbers share the load. See MX records.
How long do record changes take to apply?▾
That depends on the record's TTL — the cache lifetime resolvers honor. Until a cached copy expires, resolvers keep serving the old answer, so a change with a one-hour TTL can take up to an hour to be seen everywhere. Lowering the TTL before a planned change makes it propagate faster. See TTL and propagation for the full mechanics.