DNS Record Types Explained: A, AAAA, CNAME, MX, TXT, NS, SOA, SRV and CAA
A practical guide to the DNS record types you edit every day: what A, AAAA, CNAME, MX, TXT, NS, SOA, SRV and CAA do and how to check them.
By the DNSLab team Updated July 9, 2026
Quick answer
DNS records are instructions stored in your domain's zone that tell the internet how to route traffic and verify your domain. The most common types are A and AAAA (point a name to an IPv4 or IPv6 address), CNAME (alias one name to another), MX (route incoming email), TXT (hold text data such as SPF and verification records), and NS (delegate the domain to its authoritative nameservers).
What a DNS record actually is
A DNS record is a single line in a zone file that tells resolvers one fact about a name: where it points, who handles its mail, or which text values it carries. Every record has a name, a type, a TTL (how many seconds a resolver may cache it), and the data itself. When you type a hostname, your resolver walks from the root servers down to the authoritative nameservers for the domain and reads back the matching records. Understanding the types below is the difference between guessing why a site or email is broken and reading the answer straight from the zone. You can pull the live records for any name using the DNS Lookup tool on dnslab.
A and AAAA: the address records
An A record maps a hostname to an IPv4 address (example.com to 203.0.113.10). An AAAA record does the same job for IPv6 (2001:db8::10). These are the records a browser ultimately needs to open a connection, so almost every other record depends on them existing somewhere. You can have several A records for one name to spread traffic across servers, and a name can carry both A and AAAA at once for dual-stack hosts. A frequent mistake is publishing an AAAA record for a server that is not actually reachable over IPv6, which makes the site slow or unreachable for IPv6 clients while looking fine on IPv4.
CNAME, NS, SOA and CAA: names, delegation and control
A CNAME is an alias: www.example.com is a CNAME to example.com, and the resolver follows it to find the real address. The strict rule is that a name with a CNAME may hold no other records, so you can never put a CNAME at the zone apex (the bare domain). NS records list the authoritative nameservers for a zone and are how a parent delegates control to you. The SOA record sits at the apex and holds the zone's serial number and timing values that govern replication and negative caching. A CAA record names which certificate authorities are allowed to issue TLS certificates for the domain, limiting mis-issuance.
MX and TXT: mail and everything else
An MX record tells other mail servers where to deliver mail for your domain, each with a priority number where lower is tried first. MX records must point to a hostname, never an IP address. TXT records hold arbitrary text and have become the home for email authentication: SPF lists which servers may send for you, DKIM publishes a signing key, and DMARC (as a TXT at _dmarc.yourdomain) tells receivers what to do with messages that fail. Check these with the SPF, DKIM and DMARC tools on dnslab before you assume mail delivery is configured. TXT is also where you paste domain-ownership verification strings from Google, Microsoft and others.
SRV records for services
An SRV record advertises the host and port for a specific service rather than a bare address, so clients can find where a protocol lives without hardcoding it. The name follows a fixed pattern, _service._protocol.domain, for example _sip._tcp.example.com or _xmpp-client._tcp.example.com. The data carries four fields: priority, weight, port and target hostname. Priority works like MX (lowest first), and weight distributes load among targets that share a priority. SRV is used by SIP, XMPP, Microsoft 365 autodiscover and Minecraft servers among others. If a VoIP or chat client cannot connect, a missing or mistyped SRV name is a common cause worth checking early.
How to change a record and verify it
Edit records at whoever runs your authoritative DNS, usually your registrar or a provider like Cloudflare or Route 53. Set the type, name and value, and pick a TTL: use a low value such as 300 seconds before a planned change so it propagates quickly, then raise it afterward. Save, then confirm from the outside rather than trusting the dashboard. Query the specific type with the DNS Lookup tool, and remember that propagation is really old records expiring from caches, bounded by the previous TTL. Common failures are a stray trailing dot, an apex CNAME, or forgetting that MX and SRV point to names, not IPs.
Frequently asked questions
- Why can't I put a CNAME on my root domain?
- The DNS standard forbids a name that has a CNAME from carrying any other record, and the root of your zone must already hold SOA and NS records. A CNAME there would conflict with them. Providers work around this with ALIAS or flattened records that behave like a CNAME while returning A/AAAA data at the apex.
- How long does a DNS change take to appear?
- Only as long as the old record's TTL. Resolvers cache the previous value until it expires, so a record with a 3600-second TTL can take up to an hour to update everywhere. Lower the TTL before making changes to shorten the wait. Authoritative nameservers themselves usually reflect edits within seconds.
- Do SPF, DKIM and DMARC need separate record types?
- No. All three live in TXT records, just at different names and with different contents. SPF is a TXT at your domain apex, DKIM is a TXT at a selector name, and DMARC is a TXT at _dmarc.yourdomain. There is no dedicated SPF record type anymore. Use the SPF, DKIM and DMARC tools on dnslab to validate each one.