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

DNS records come in more than a dozen types, but most domains only ever need a handful of them. Here's what each common type actually does, in plain language.

The core records almost every domain has

A — Maps a hostname to an IPv4 address. This is the record that lets browsers actually reach your website; without one, your domain typically can't be resolved over IPv4 at all.

AAAA — The IPv6 equivalent of an A record. Not strictly required (a huge share of the internet still runs fine on IPv4-only), but increasingly expected, particularly on mobile networks which are often IPv6-first.

CNAME — An alias: it points one hostname at another hostname rather than directly at an IP. Commonly used for subdomains pointing at third-party services (a CDN, a SaaS platform's custom-domain feature). One important restriction: a name can't have a CNAME and any other record type at the same time — that's why you can rarely put a CNAME on a bare domain apex, only on subdomains.

MX — Mail Exchange. Tells the internet which server(s) handle incoming email for your domain, each with a priority number (lower numbers are tried first). No MX record generally means no inbound email at all.

NS — Nameserver records. These declare which servers are authoritative for your domain's DNS — every other record type is ultimately served by whichever servers your NS records point to.

TXT — A general-purpose text field. Originally just free-form notes, it's now the workhorse record type for domain verification, and for SPF and DMARC policies (see our SPF/DKIM/DMARC guide).

Less common, but worth knowing

SOA — Start of Authority. Administrative metadata for the zone: the primary nameserver, an admin contact, a serial number that increments on every change, and timers that control how secondary nameservers refresh and retry.

CAA — Certificate Authority Authorization. Restricts which certificate authorities are allowed to issue TLS certificates for your domain. Publishing one is a small, low-effort security win — without it, any publicly trusted CA can issue a certificate for your domain.

SRV — Service records, specifying a host and port for a particular protocol (common in VoIP and some chat/collaboration platforms). Lets a client discover the right server without hardcoding it.

PTR — Reverse DNS: maps an IP address back to a hostname, the opposite direction of a normal lookup. Mail servers routinely check this as a legitimacy signal — a sending IP with no matching PTR record is a red flag to many spam filters.

NAPTR — Used for more complex service-discovery scenarios, notably VoIP/ENUM systems, where an identifier needs to be rewritten into a URI through a set of ordered rules.

DNSSEC-related records

DS and DNSKEY work together to form DNSSEC's chain of trust — covered in detail in our DNSSEC guide.

The newer web-performance records

HTTPS and SVCB — Recent additions that let a domain advertise connection details (supported protocols, IP address hints, TLS parameters) directly in DNS, so a browser can set up a faster, more secure connection before making its first HTTP request. Increasingly used by major CDNs and browsers.

Seeing all of this for a real domain

Rather than memorising the theory, the fastest way to actually understand these is to look at a real, well-configured domain and see which records it uses and why. Run a scan on any domain and DNSDecode will show every record it finds, grouped and filterable by type, with a plain-English explanation of what each one does available directly from the results table.