TR
← Back to blogGuides

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

What each DNS record type does, how it looks in a zone, the rules that trip people up (CNAME at apex, MX targets, TXT length) and how to query each with dig.

Published: · 6 min read

A DNS zone is a list of resource records. Each one has the same five parts:

www.example.com.   3600   IN   A   192.0.2.10
└── name           └ TTL  └class └type └ data

The name is what gets looked up, the TTL is how many seconds a resolver may cache the answer (see what is TTL in DNS), the class is practically always IN, and the type decides how the data is interpreted. This guide walks through the types you will actually meet, with the rules that cause real outages.

Quick reference

Type Purpose Example data
A IPv4 address 192.0.2.10
AAAA IPv6 address 2001:db8::10
CNAME alias to another name shop.hosting.example.
MX mail servers for the domain 10 mx1.mail.example.
TXT free text: SPF, DKIM, DMARC, verifications "v=spf1 -all"
NS nameservers responsible for a zone ns1.dns.example.
SOA zone metadata, one per zone serial, timers
PTR reverse lookup: address to name mail.example.com.
SRV host and port of a service 10 5 5060 sip.example.com.
CAA which CAs may issue certificates 0 issue "ca.example"
DS, DNSKEY, RRSIG DNSSEC keys and signatures
HTTPS, SVCB service parameters for HTTPS 1 . alpn="h2,h3"

A and AAAA: addresses

A maps a name to an IPv4 address, AAAA to an IPv6 address. A name can have several of each; resolvers return all of them and clients pick one, which gives crude load distribution but not failover in any guaranteed sense.

$ dig +short www.example.com A
192.0.2.10
$ dig +short www.example.com AAAA
2001:db8::10

Publish an AAAA record only if the server really answers on IPv6. A broken IPv6 path makes the site slow or unreachable for some users while it "works for you".

CNAME: aliases and their two rules

A CNAME says "this name is an alias; look up that other name instead". The resolver restarts the lookup with the target.

shop.example.com.   3600  IN  CNAME  stores.hosting.example.

Two rules come from the DNS standards, not from provider preference:

  1. A name with a CNAME may have no other records. No MX, no TXT, nothing (DNSSEC records excepted).
  2. Therefore no CNAME at the zone apex. example.com itself must carry SOA and NS records, so it cannot be a CNAME.

Providers work around the second rule with "ALIAS", "ANAME" or "CNAME flattening": the DNS provider resolves the target itself and answers with A/AAAA records. It works, but it is a provider feature, not a record type; it does not survive a zone export to a provider that lacks it.

Other CNAME advice: do not point MX or NS records at a CNAME, and avoid long chains. Each hop is another lookup and another thing that can break.

MX: where mail goes

MX records name the servers that accept mail for the domain, each with a preference number. Lower is tried first; equal numbers share load.

example.com.  3600  IN  MX  10 mx1.mail.example.
example.com.  3600  IN  MX  20 mx2.mail.example.

The target must be a hostname with A/AAAA records: not an IP address and not a CNAME. If a domain has no MX at all, senders fall back to the domain's A record, which is rarely what you want. A domain that receives no mail can say so explicitly with a null MX: 0 .

SPF, DKIM and DMARC, which build on top of MX and TXT, are a topic of their own.

TXT: text with conventions

TXT holds arbitrary strings. Its real importance comes from conventions built on top:

  • SPF at the domain itself: "v=spf1 include:_spf.mail.example -all". Exactly one SPF record per name; two is a permanent error.
  • DKIM at selector._domainkey.example.com.
  • DMARC at _dmarc.example.com.
  • Ownership verification strings for search consoles, SaaS tools and certificate issuance.

A single string in a TXT record is limited to 255 bytes. Longer values, typically 2048-bit DKIM keys, are split into several quoted strings inside one record, and the reader joins them with no separator:

sel1._domainkey  IN TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC..."
                          "...AQ8AMIIBCgKCAQEA" )

Most control panels do the splitting for you. If you split by hand, do not add a space at the join.

NS and SOA: the structure of the zone

NS records list the authoritative nameservers. They exist twice: in the parent zone (the delegation, changed at your registrar) and inside your own zone. The two sets should match. NS records on a subdomain delegate that subdomain to other servers.

SOA is the single record at the top of every zone:

example.com. 3600 IN SOA ns1.dns.example. hostmaster.example.com. (
    2026092001 ; serial
    7200       ; refresh
    3600       ; retry
    1209600    ; expire
    300 )      ; negative-caching TTL

The serial tells secondary servers that the zone changed. The last field is what most people overlook: it controls how long resolvers cache "this name does not exist". That is why a record you created a minute after somebody looked it up can stay invisible for a while.

Moving NS records is its own project and needs a plan of its own.

PTR: reverse lookups

A PTR record maps an address back to a name. It lives in a special zone (in-addr.arpa for IPv4, ip6.arpa for IPv6) that is controlled by whoever owns the IP block, normally your hosting provider or ISP, not by you in your domain's zone.

$ dig +short -x 192.0.2.25
mail.example.com.

It matters mostly for mail servers. Details are in reverse DNS and PTR records.

SRV: services with ports

SRV records let a client find the host and port for a service, under a name of the form _service._proto.name:

_sip._tcp.example.com. 3600 IN SRV 10 60 5060 sip1.example.com.
;                                  prio weight port target

Used by SIP, XMPP, Matrix, some Microsoft services and others. Browsers do not use SRV for websites.

CAA: who may issue certificates

CAA lists the certificate authorities allowed to issue for the domain. Every public CA must check it before issuing.

example.com.  IN  CAA  0 issue "ca.example"
example.com.  IN  CAA  0 issuewild ";"

No CAA record means any CA may issue. More in CAA records explained.

DNSSEC records

DNSKEY holds the zone's public keys, RRSIG the signatures over each record set, NSEC/NSEC3 prove that a name does not exist, and DS in the parent zone ties the child's key into the chain of trust. Your DNS provider generates all of them except DS, which you (or the provider) submit through the registrar.

HTTPS and SVCB

The HTTPS record (a special form of SVCB) lets a browser learn, in the DNS answer itself, that a site supports HTTP/2 or HTTP/3, which addresses to use, and optionally an alias target, even at the apex. Large CDNs publish it automatically. You rarely write one by hand, but you will see it in lookups:

$ dig +short example.com HTTPS
1 . alpn="h2,h3"

What about ANY?

dig example.com ANY used to return everything a server had. Many servers now answer with a minimal response instead, because ANY was abused for amplification attacks. To see a zone's records, query each type you care about. There is no public query that lists all names in a zone; zone transfers (AXFR) are restricted to authorised secondaries.

Common mistakes

  • CNAME at the apex, or CNAME next to MX/TXT on the same name.
  • MX pointing at an IP address or at a CNAME.
  • Two SPF TXT records on one name.
  • Missing trailing dot in a zone file, so mx1.mail.example becomes mx1.mail.example.example.com.. Control panels differ in whether they expect the dot; check the result with dig.
  • An AAAA record for a server with no working IPv6.
  • Creating a record at www and expecting the bare domain to follow, or the other way round. They are different names.
  • Forgetting the negative-caching TTL when a new record "does not show up".

Check it with OrbitProbe

The OrbitProbe DNS lookup queries A, AAAA, CNAME, MX, TXT, NS, SOA and CAA for a name in one go and shows the TTL of each answer, so you can compare what is published with what you intended. Run it for the bare domain and for www separately; they are separate names with separate records.