DNS Record Types Explained, and Which Ones You Can Ignore

A working reference to A, AAAA, CNAME, MX, TXT, NS, SOA, CAA, DS and DNSKEY records: what each one does, what it cannot prove, and when it matters.

By Net Insight Published 2026-09-17 Updated 2026-09-17

Why the list matters before you edit anything

Every DNS change is a choice of record type, and most DNS mistakes are type mistakes rather than value mistakes. Putting an address in a TXT record, a CNAME at a name that already has records, or a mail route in an A record will each produce a zone that looks configured and behaves wrongly. Knowing which type does which job is the whole prerequisite.

The records below are the ones a normal zone actually uses. The report on the DNS lookup page shows them with their real values, and the propagation checker shows whether two resolvers currently agree about them.

Address records: A and AAAA

An A record maps a name to an IPv4 address. AAAA records do the same for IPv6. They are separate data, which is why a name can work over one family and not the other, and why an empty AAAA answer is a deliberate configuration rather than an error.

Multiple A records at the same name are normal and are how simple redundancy or load spreading is published. The client picks one, and the order is not something you control. Underscoring the separation between families is worth a line of its own: a working A record tells you nothing about IPv6.

The alias record: CNAME

A CNAME says that the name is another name. The resolver follows it and returns whatever that target resolves to. That indirection is useful when a provider’s edge addresses change without warning and useless when you need to control the address yourself.

The rule that catches people out is that a CNAME cannot coexist with any other record at the same name. A name with a CNAME cannot also have an MX record, a TXT record or an A record. Since a zone apex always has NS and SOA records, a bare domain normally cannot be a CNAME at all; providers solve this with a proprietary alias type that behaves like a CNAME but is served as an address record.

Mail records: MX, and the TXT records mail depends on

An MX record names the hosts that accept mail for a domain, each with a preference number. Senders sort by preference and try the lowest first, so higher numbers are redundancy rather than load sharing. An MX target must resolve to an address directly and must never be a CNAME — mail routing is the one place where that rule is enforced strictly.

Three TXT-record grammars carry the mail policy. SPF lists which hosts may send, DMARC states what to do when authentication fails, and DKIM publishes the public key that verifies a signature. All three are TXT records, and all three have their own parsers on this site: SPF checker, DMARC checker and DKIM checker. Reading them by eye is possible and error-prone, which is the reason the parsers exist.

Delegation records: NS and SOA

NS records name the servers that are authoritative for a zone. They describe who runs the DNS, which is often a different organisation from the one hosting the website and usually a different one from the registrant. A common confusion is reading NS records as ownership data; the WHOIS alternative page covers what those records do and do not reveal.

The SOA record is the zone’s bookkeeping. It names the primary server, carries an administrative mailbox, holds a serial number that increments on every change, and states the negative-caching interval — how long a resolver may remember that a name does not exist. That last value is the reason a name that never existed can appear to take longer to start resolving than a record that merely changed. The arithmetic is covered by the DNS TTL calculator.

Security records: CAA, DS and DNSKEY

A CAA record lists which certificate authorities are permitted to issue for a name. It is advisory in the sense that it is enforced by the authorities rather than by the protocol, and it is one of the cheapest security controls available: without it, any authority may issue for your name and you would not be told. The SSL and CAA check reads it alongside the DNSSEC records.

DS and DNSKEY together make up DNSSEC. The DS record sits at the parent and the DNSKEY record in the zone itself. When both are present and consistent, a validating resolver can detect a modified answer. When the chain is broken, validating resolvers refuse to answer at all, which converts a signing mistake into an outage. That failure mode is the main argument for understanding DNSSEC before enabling it rather than after.

The records that are not about your website

Several types exist for reasons unrelated to serving a page, and seeing them in a zone is not a problem. Service records such as SRV publish host and port for protocols that need them. PTR records live in reverse zones owned by whoever holds the address range, which is why you usually cannot create one yourself — the reverse DNS lookup page covers that asymmetry.

TXT records also accumulate unrelated strings: provider verification tokens, policy identifiers, domain keys from services you have stopped using. They are harmless individually and worth pruning occasionally, because an unused verification token is a claim someone else may still be able to make.

What the records do not tell you

They do not tell you whether anything is working. A record set can be published, consistent at every resolver, and still point at a decommissioned server. DNS describes intent, and reachability is a separate question that only a connection attempt answers.

They do not tell you whether mail will arrive, whether a certificate is valid, or whether a site is trustworthy. Those live with the mail receivers, the certificate authorities and the reputation lists respectively. The network guide collects the reading order that keeps those questions separate.

Questions worth asking

Can two records of the same type exist for one name?

Yes, and for A, AAAA, MX and NS records that is normal: multiple records are how redundancy is published. The exceptions are CNAME, which must be alone at a name, and SOA, of which there is exactly one per zone.

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

An A record gives an address. A CNAME says this name is another name, and the resolver then looks that name up. A CNAME cannot coexist with other records at the same name, which is why it cannot be used at the bare domain of most zones.

Why do TXT records look unreadable?

TXT records carry arbitrary text for other systems to parse, not for people to read. SPF, DMARC and DKIM are all TXT records with their own grammars, which is why they need a parser rather than a manual reading.

Do I need DNSSEC?

It is optional and it is worth understanding either way. Without it, answers for a zone can be rewritten in transit without the resolver noticing. With it, a validation failure makes a zone unreachable for validating resolvers, so a broken rollout is worse than never enabling it.

Which record type should I create for a website?

An A record for IPv4 and an AAAA record for IPv6, with the same name. If a provider gives you a host name rather than an address, that is a hint to use a CNAME, but not at the zone apex, where most providers offer an alias record instead.