DNS record types explained (A, AAAA, CNAME, MX, TXT, NS, and more)

A quick recap: DNS maps names to data

The Domain Name System turns human-friendly names like example.com into the data a computer needs to actually connect — most often an IP address, but also mail routing, service locations, and text metadata. All of that data lives as individual records inside a zone, which is just the collection of records a nameserver is authoritative for. When something looks up your domain, it is really asking for a specific record type at a specific name. If you want the full journey of how a query travels from your device to an authoritative server, see how DNS works.

Every record shares the same basic shape: a name (the host it applies to), a type (what kind of data it holds), a TTL (how long it may be cached), and the data itself. The type is what this article is about. Here is each of the common ones, with a realistic example.

A — name to IPv4 address

The A record is the workhorse of DNS. It maps a name to a single 32-bit IPv4 address, and the address is the answer — there is no further lookup to do. A name can have several A records, in which case resolvers return all of them and clients pick one, which is a simple form of load balancing.

example.com.      3600  IN  A   93.184.216.34

AAAA — name to IPv6 address

The AAAA record (“quad-A”) is the exact IPv6 counterpart of the A record. It maps a name to a 128-bit IPv6 address. A dual-stack host typically publishes both an A and an AAAA record at the same name, and modern clients prefer the IPv6 answer when they have working IPv6 connectivity.

example.com.      3600  IN  AAAA  2606:2800:220:1:248:1893:25c8:1946

CNAME — an alias to another name

A CNAME (“canonical name”) record points one name at another name rather than at an address. When a resolver hits a CNAME, it restarts the lookup against the target and follows wherever that leads. This is how you point www.example.com at a CDN or platform endpoint without ever knowing its IP address — the provider changes the underlying address freely and you never have to touch your record.

www.example.com.  3600  IN  CNAME  example.com.

Two restrictions trip people up constantly. First, a CNAME cannot coexist with any other record at the same name — if www is a CNAME, it may not also have an A, MX, or TXT record, because the CNAME says “everything at this name lives over there instead.” Second, a CNAME is not allowed at the zone apex — the bare domain (example.com with no host in front) must carry the mandatory SOA and NS records, which a CNAME would forbid. That is why you cannot simply CNAME your root domain to a hosting provider; you either use an A/AAAA record there, or a provider-specific workaround (often marketed as “ALIAS” or “ANAME,” which are not real DNS record types but flattening tricks the nameserver performs for you).

MX — where mail for the domain goes

An MX (“mail exchanger”) record names the mail servers that accept email for a domain, each with a priority (also called preference) number. The rule is simple but easy to get backwards: lower numbers are preferred. A sending server tries the lowest priority first and only falls back to higher numbers if it cannot connect. Records at the same priority are load-balanced.

example.com.      3600  IN  MX  10  mail1.example.com.
example.com.      3600  IN  MX  20  mail2.example.com.

Here mail1 is the primary and mail2 is the backup. Note that an MX record must point at a hostname that itself resolves to an address (via an A or AAAA record) — it may not point at an IP address directly, and it should not point at a CNAME.

TXT — arbitrary text (and a lot of email plumbing)

A TXT record holds free-form text. Originally meant for human notes, it has become the universal carrier for machine-readable domain policy. The big three email-authentication mechanisms all ride on TXT records: SPF lists which servers may send mail for your domain, DKIM publishes the public key used to verify message signatures (at a selector name), and DMARC publishes your enforcement policy at _dmarc.example.com. TXT records are also how countless services ask you to prove you control a domain before they will issue a certificate or enable a feature.

example.com.      3600  IN  TXT  "v=spf1 include:_spf.example.net -all"
_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

If you have ever had to debug why a message failed authentication, the underlying records are almost always TXT records like these. The results show up in the message's email headers.

NS — delegating a zone to its nameservers

An NS (“name server”) record names the authoritative servers for a zone. NS records do two jobs: they appear at the top of your own zone to declare who is authoritative, and they appear in the parent zone to delegate the child to those servers. When you set nameservers at your registrar, you are populating the NS records that .com hands out to point queries at your DNS provider.

example.com.      86400  IN  NS  ns1.example-dns.net.
example.com.      86400  IN  NS  ns2.example-dns.net.

SOA — the zone's authority and timers

Every zone has exactly one SOA (“start of authority”) record at its apex. It names the primary nameserver and the responsible party's email address, and carries a serial number plus a set of timers. The serial is bumped every time the zone changes so that secondary servers know to pull a fresh copy; the timers (refresh, retry, expire, and minimum) govern how secondaries sync and how long negative answers may be cached.

example.com.  3600  IN  SOA  ns1.example-dns.net. hostmaster.example.com. (
                2024010101  ; serial
                7200        ; refresh
                3600        ; retry
                1209600     ; expire
                3600 )      ; minimum

PTR — reverse DNS, from IP back to name

A PTR (“pointer”) record does the opposite of an A record: it maps an IP address back to a name. These live in special reverse zones (in-addr.arpa for IPv4, ip6.arpa for IPv6) and are usually controlled by whoever owns the IP block — typically your ISP or hosting provider, not you. Reverse records matter most for mail: many receivers reject or downrank a sending server whose IP has no matching PTR. There is a whole guide on this in reverse DNS.

34.216.184.93.in-addr.arpa.  3600  IN  PTR  mail1.example.com.

SRV — service, host, and port

An SRV (“service”) record advertises the host and port for a particular service, so clients do not have to assume a fixed port. The name encodes the service and protocol (for example _sip._tcp.example.com), and the data carries a priority, a weight (for load distribution among equal priorities), the port, and the target host. It is widely used by SIP, XMPP, Minecraft, and Microsoft services.

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

CAA — which certificate authorities may issue

A CAA (“certification authority authorization”) record lets you declare which certificate authorities are permitted to issue TLS certificates for your domain. Before issuing, a compliant CA is required to check for a CAA record and refuse if it is not on the list — a guardrail against mis-issuance. It does not affect how visitors reach your site; it only constrains who can mint certificates for it.

example.com.      3600  IN  CAA  0 issue "letsencrypt.org"

Quick reference table

TTL: how long records are cached

Every record carries a TTL (“time to live”) in seconds, which tells resolvers how long they may cache the answer before asking again. A TTL of 3600 means “this answer is good for an hour.” High TTLs reduce load and speed up repeat lookups, but they also mean a change you make can take that long to reach everyone, because caches everywhere are still serving the old value until it expires. The common trick before a planned migration is to lower the TTL a day ahead of time, make the change, then raise it again once things are stable.

Because of caching, an update is never instant everywhere — you and your resolver may keep seeing an old record until its TTL runs out. If you have changed a record and want your own machine to fetch the new value immediately, clearing your resolver cache helps; see how to flush your DNS cache.

Frequently asked questions

What is the difference between an A record and a CNAME?

An A record gives an IPv4 address directly, so the answer is the address. A CNAME gives another name, so the resolver has to look that name up to find the address. Reach for an A (or AAAA) record when you have an IP; reach for a CNAME when you want to alias to a hostname someone else manages. Remember that a CNAME cannot coexist with other records at the same name and is not allowed at the zone apex.

What does the priority number on an MX record mean?

It sets the order in which sending servers try your mail exchangers, and lower is preferred. Priority 10 is used before priority 20; records sharing a priority are load-balanced. It is a preference order, not a percentage or a weight.

Which DNS record type is used for SPF, DKIM, and DMARC?

All three are plain TXT records — there is no dedicated type for any of them. SPF sits on your domain name, DKIM at a selector name, and DMARC at _dmarc.yourdomain. The same TXT mechanism is what services use when they ask you to add a record to verify domain ownership.

Related reading

• How DNS works — the full path a query takes from your device to an authoritative nameserver.
• Reverse DNS — the PTR side of the story, and why it matters for mail deliverability.
• Flush your DNS cache — force your machine to pick up a record change instead of waiting for the TTL.
• Reading email headers — where SPF, DKIM, and DMARC results actually surface.
• DNS tools — look up the live records for any domain.
• Networking glossary — short definitions for the terms used throughout this guide.