DNS record types reference

Overview

DNS records are the concrete rules in a zone file. Each is a name and a value, and the record type says what the value means. When you point a domain at hosting, or email, or a third-party service, the setup guide is invariably asking you to add one of these, so it helps to know what each record does and what the lifecycle is.

Address records

| Type | Value shape | What it does | Example |

| A | IPv4 address (32-bit) | Maps a hostname directly to an IPv4 address. @ in most DNS panels means the apex (example.com itself). | @ A 203.0.113.7 |

| AAAA | IPv6 address (128-bit) | Maps a hostname to an IPv6 address. Use the same name as its A record when the host is dual-stacked. | @ AAAA 2001:db8::7 |

A records are what a browser ultimately needs; other records usually exist to prove control of the domain or to route non-web services.

Name records

• CNAME: an alias. The value is another name, and the resolver follows it before finally resolving that name to an address. www.example.com commonly points to a CDN host. A CNAME cannot normally sit at the apex, and it cannot coexist with other records on the same name.
• NS: the NS records say which nameservers are authoritative for the zone. They must match what the registrar holds. The root of the zone (the SOA record) also carries a serial that syncs when something changes.
• PTR: reverse lookup, the opposite direction, maps an IP back to a name. Used by mail servers for check and for diagnostics; it is set at the IP provider, not the domain DNS.

The CNAME vs A article covers the forwarding detail; the TTL article covers the caching number attached to every record.

Mail and verification records

| Type | Value shape | Used for |

| MX | Priority number and hostname of the mail server(s) | Routing email: 0 mail.example.com, 10 fallback.example.com |

| TXT | Free-form text on the domain | SPF policy (v=spf1 include:... -all), DKIM public key, DMARC policy, Search Console verification proof |

| CNAME _domainkey | The public DKIM key published for email signing | The mailbox provider gives you the exact name and value |

MX records do not resolve by IP directly; the resolver looks up the A record of the name in the MX value. Email works over the mail path, so the site can be on a different host entirely and email still lands. That is why "the website is fine but email is down" is so often a TXT or MX problem.

Policy and newer record types

• CAA: names which certificate authorities are permitted to issue for the domain. 0 issue "letsencrypt.org" allows Let's Encrypt and stops others. Empty or absent means any CA can issue.
• SRV: gives host and port for services such as SIP or _autodiscover for Microsoft 365. The name starts with an underscore-prefixed service.
• TLSA: for DANE, DNSSEC-signed reference to the certificate a server should present. Rarely needed on public websites.
• DNSSEC: adds a chain of signatures in the DS, DNSKEY, RRSIG records. When the registrar and hosting both support DNSSEC, enable it and keep the two sides aligned.

Practical workflow

1. Read the hosting or service instructions and note which record types they ask for by name.
2. For a website: add the A record (or AAAA for IPv6) to the provider IP, and a CNAME for www if the CDN gives a hostname.
3. For email: MX and TXT (SPF, DKIM, DMARC) are usually all that are needed.
4. For verification: adding TXT values and wait for the hostname to resolve is the classic Google and mail host flow.
5. After any change, wait out the existing TTL before the new record shows at every resolver; query a public DNS checker to confirm.

Both the TTL article and the propagation article explain those waits.