What are DNS records and what are the different types?

Sajjad
DNS
10 Oct, 2026

DNS records are the individual entries stored in a domain's DNS zone. Each one maps a name to a specific piece of information, such as an IP address, a mail server, or a line of text used for verification. The type of a record decides what kind of information it holds. The ones you'll use most are A and AAAA (IPv4 and IPv6 addresses), CNAME (an alias to another name), MX (mail servers), TXT (free-form text, used for SPF, DKIM, DMARC and verification), NS (which nameservers are authoritative) and SOA (administrative details for the zone). Beyond those are specialist types such as PTR, SRV, CAA, HTTPS and the DNSSEC records.

When you open the DNS panel for your domain, the list of record types can look intimidating. This article explains what every DNS record has in common, then walks through each common record type in turn with an example and a note on when you'd use it, followed by a reference table, a complete sample zone, and the rules that stop records from conflicting with one another.

What Every DNS Record Contains

Every DNS record, regardless of type, has the same five parts. In a standard zone file, a record is written on one line:

www.example.com.   3600   IN   A   192.0.2.10

Name (www.example.com.): The hostname the record belongs to. In DNS dashboards you usually type only the part before your domain, such as www, or @ for the domain itself.
TTL (3600): How many seconds resolvers may cache the record.
Class (IN): Almost always IN, for Internet.
Type (A): What kind of record this is.
Data (192.0.2.10): The value, whose format depends on the type.

Records with the same name and type are grouped into a record set. For example, a domain with two mail servers has one MX record set containing two records.

You can query any record type with dig by naming it after the domain:

dig example.com MX +noall +answer

example.com.		3600	IN	MX	10 mail1.example.com.
example.com.		3600	IN	MX	20 mail2.example.com.

Address Records

A Record

An A record maps a name to an IPv4 address. It's the most fundamental record type, because it's what turns a name into something a computer can connect to.

example.com.       3600  IN  A  192.0.2.10
www.example.com.   3600  IN  A  192.0.2.10

Use an A record whenever a hostname should resolve to a server's IPv4 address. You can publish several A records for the same name to spread traffic across multiple servers.

AAAA Record

An AAAA record (pronounced "quad-A") does the same job for IPv6 addresses.

example.com.  3600  IN  AAAA  2001:db8:10::1

If your server has an IPv6 address and listens on it, publish an AAAA record alongside the A record. Devices with IPv6 connectivity will usually prefer it.

Alias Records

CNAME Record

A CNAME record (canonical name) says that one name is an alias for another. The resolver follows the alias and looks up the target name's records instead.

shop.example.com.  3600  IN  CNAME  shops.example.net.

CNAMEs are common when pointing a subdomain at a hosted service, such as a store platform, help desk or CDN, because the provider can change its IP addresses without you updating anything. Two strict rules apply: a CNAME can't exist alongside any other record with the same name, and so it can't be used on the bare domain (example.com), which always has SOA and NS records.

ALIAS, ANAME and Flattened Records

Several DNS providers offer a provider-specific record, named ALIAS, ANAME, or a "flattened CNAME", that behaves like a CNAME at the bare domain. The provider looks up the target itself and returns ordinary A and AAAA records to visitors. These aren't standard record types in the DNS protocol, so they only work at providers that support them, and they can't be transferred to another provider as-is.

Email Records

MX Record

An MX record (mail exchange) tells other mail servers where to deliver email for your domain. Each MX record has a priority number and a hostname; lower numbers are tried first.

example.com.  3600  IN  MX  10 mail1.example.com.
example.com.  3600  IN  MX  20 mail2.example.com.

The target must be a hostname with its own A or AAAA records, not an IP address and not a CNAME. Hosted email providers give you the exact MX values to use.

TXT Record

A TXT record holds free-form text. DNS itself doesn't interpret it, but many other systems do, which makes TXT one of the most widely used record types.

example.com.         3600  IN  TXT  "v=spf1 include:_spf.google.com -all"
_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
example.com.         3600  IN  TXT  "google-site-verification=abc123example"

Common uses include:

SPF: Lists which servers may send email for your domain.
DKIM: Publishes public keys used to verify email signatures, under selector._domainkey.
DMARC: Sets your email authentication policy, under _dmarc.
Domain verification: Proves ownership to services such as Google, Microsoft and certificate authorities.

A single TXT string is limited to 255 characters, but a record can contain several strings that are joined together, which is how long DKIM keys are published.

Zone and Delegation Records

NS Record

An NS record (name server) lists the authoritative nameservers for a zone. NS records appear in two places: in your own zone, and in the parent zone (such as .com), where your registrar publishes them to delegate your domain to your DNS provider.

example.com.  86400  IN  NS  ns1.example.net.
example.com.  86400  IN  NS  ns2.example.net.

You can also add NS records for a subdomain to delegate it to different nameservers, for example to let another team run dev.example.com.

SOA Record

Every zone has exactly one SOA record (start of authority), at the top of the zone. It names the primary nameserver and the administrator's contact address, and contains timers used by secondary nameservers and for negative caching.

dig example.com SOA +short

ns1.example.net. hostmaster.example.com. 2026101201 7200 3600 1209600 300

The fields are the primary nameserver, the contact email (with the first dot standing in for @), the serial number, the refresh, retry and expire timers, and the negative caching TTL. Most hosted DNS providers manage the SOA record for you.

Service and Reverse Lookup Records

PTR Record

A PTR record (pointer) does the reverse of an A record: it maps an IP address back to a name. PTR records live in special zones under in-addr.arpa for IPv4 and ip6.arpa for IPv6, and are normally controlled by whoever owns the IP address block, such as your hosting provider.

dig -x 192.0.2.20 +short

mail.example.com.

Reverse DNS matters most for mail servers, because many receiving servers reject or penalise mail from IP addresses without a matching PTR record.

SRV Record

An SRV record (service) tells clients which host and port provide a particular service, along with priority and weight values for choosing between several servers. The name follows the pattern _service._protocol.domain.

_sip._tcp.example.com.  3600  IN  SRV  10 60 5060 sip1.example.com.
_sip._tcp.example.com.  3600  IN  SRV  10 40 5060 sip2.example.com.

The fields are priority, weight, port and target. SRV records are used by protocols such as SIP, XMPP, LDAP and Kerberos, by Active Directory, and by some games and Microsoft 365 services. Web browsers don't use SRV records for ordinary websites.

Security and Policy Records

CAA Record

A CAA record (certification authority authorisation) lists which certificate authorities may issue TLS certificates for your domain. CAs are required to check it before issuing.

example.com.  3600  IN  CAA  0 issue "letsencrypt.org"
example.com.  3600  IN  CAA  0 iodef "mailto:security@example.com"

If no CAA record exists, any CA may issue. Adding one is a simple way to reduce the risk of a certificate being issued by a CA you don't use.

DNSSEC Records

If your zone is signed with DNSSEC, it contains additional records that you rarely edit by hand:

DNSKEY: The zone's public signing keys.
RRSIG: A signature over each record set.
DS: A hash of your key, published in the parent zone through your registrar.
NSEC / NSEC3: Signed proof that a name or type does not exist.

Your DNS provider generates these automatically when you enable DNSSEC. The only one you usually handle yourself is the DS record, which you copy into your registrar's control panel.

Modern Records

HTTPS and SVCB Records

SVCB (service binding) and its web-specific form, the HTTPS record, were standardised in RFC 9460. They let a domain tell clients, before connecting, which protocols it supports (such as HTTP/3), alternative endpoints, and other connection hints. Unlike CNAME, an HTTPS record can be used at the bare domain.

example.com.  3600  IN  HTTPS  1 . alpn="h2,h3"

dig example.com HTTPS +short

1 . alpn="h2,h3"

Major browsers query HTTPS records today, and providers such as Cloudflare publish them automatically for proxied domains. For most sites they're an optimisation rather than a requirement.

DNS Record Types at a Glance

Type	Purpose	Example data	Typically managed by
A	Name to IPv4 address	`192.0.2.10`	You
AAAA	Name to IPv6 address	`2001:db8:10::1`	You
CNAME	Alias to another name	`shops.example.net.`	You
MX	Mail delivery servers	`10 mail1.example.com.`	You, using values from your email provider
TXT	Free-form text (SPF, DKIM, DMARC, verification)	`"v=spf1 -all"`	You
NS	Authoritative nameservers	`ns1.example.net.`	DNS provider and registrar
SOA	Zone administration and timers	`ns1.example.net. hostmaster...`	DNS provider
PTR	IP address to name	`mail.example.com.`	Owner of the IP block
SRV	Host and port for a service	`10 60 5060 sip1.example.com.`	You
CAA	Allowed certificate authorities	`0 issue "letsencrypt.org"`	You
HTTPS / SVCB	Connection hints and endpoints	`1 . alpn="h2,h3"`	You or your CDN
DNSKEY, RRSIG, DS, NSEC	DNSSEC signing and validation	Keys, signatures, hashes	DNS provider and registrar

There are many other record types defined in the DNS standards, such as NAPTR, SSHFP, TLSA and LOC, but the list above covers almost everything a typical website or business needs.

A Complete Example Zone

Here's how these records fit together in a small zone file for a business that runs its website on its own server, uses a hosted shop, and receives email through two mail servers:

$ORIGIN example.com.
$TTL 3600

@         IN  SOA    ns1.example.net. hostmaster.example.com. (
                     2026101201 ; serial
                     7200       ; refresh
                     3600       ; retry
                     1209600    ; expire
                     300 )      ; negative caching TTL

@   86400 IN  NS     ns1.example.net.
@   86400 IN  NS     ns2.example.net.

; Website
@         IN  A      192.0.2.10
@         IN  AAAA   2001:db8:10::1
www       IN  CNAME  example.com.
shop      IN  CNAME  shops.example.net.

; Email
@         IN  MX     10 mail1.example.com.
@         IN  MX     20 mail2.example.com.
mail1     IN  A      192.0.2.20
mail2     IN  A      198.51.100.20
@         IN  TXT    "v=spf1 mx -all"
_dmarc    IN  TXT    "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

; Certificates
@         IN  CAA    0 issue "letsencrypt.org"

; Services
_sip._tcp IN  SRV    10 100 5060 sip.example.com.
sip       IN  A      203.0.113.60

If you run BIND, you can check a file like this for errors before loading it:

named-checkzone example.com /etc/bind/zones/db.example.com

zone example.com/IN: loaded serial 2026101201
OK

Rules That Prevent Record Conflicts

A few rules apply across record types, and breaking them is behind many DNS problems:

A CNAME must stand alone: If a name has a CNAME, it can't have any other record, including MX or TXT. Most DNS dashboards will refuse to save a conflicting record.
No CNAME at the bare domain: Use A and AAAA, or a provider's ALIAS-style record, for example.com itself.
MX and NS targets must be hostnames with address records: Don't point them at IP addresses or at CNAMEs.
One SPF record per name: Multiple TXT records are fine, but only one may begin with v=spf1.
Records in a set share a TTL: Two A records for the same name should have the same TTL.
Names in zone files need a trailing dot to be absolute: Writing mail.example.com without the dot in a zone file can turn it into mail.example.com.example.com.

FAQ: DNS Record Types

At minimum, an A record for the hostname visitors use, and ideally an AAAA record if your server supports IPv6. Many sites also add a CNAME or A record for www, and a CAA record to control certificate issuance.

MX records to receive mail, plus TXT records for SPF, DKIM and DMARC so your outgoing mail is trusted. Your email provider tells you the exact values to use.

Yes, for most types. Several A records spread traffic across servers, several MX records provide backup mail servers, and several TXT records can hold different verification strings. CNAME and SOA are the exceptions, with only one allowed per name.

An A record points a name directly to an IPv4 address. A CNAME points a name to another name, and the resolver then looks up that name's address. CNAMEs can't be used at the bare domain or alongside other records.

Reverse DNS zones belong to whoever controls the IP address block, which is usually your hosting provider or ISP. You normally set a PTR record through their control panel or by asking their support team.

DNS doesn't provide a reliable way to list every record in someone else's zone. You can query individual types with dig, such as A, MX, TXT and NS, or export the full zone from your own DNS provider's dashboard.

Not in the DNS standards. They're features of particular DNS providers, which resolve the target themselves and return ordinary A and AAAA records. Check that your provider supports them before relying on one.

Conclusion

DNS records are the building blocks of your domain. Address records (A and AAAA) point names at servers, CNAMEs create aliases, MX and TXT records handle email delivery and authentication, NS and SOA records define the zone itself, and specialist types such as PTR, SRV, CAA, HTTPS and the DNSSEC records cover reverse lookups, services, certificate policy, connection hints and security.

You don't need to memorise every type to manage a domain well. Know what the common ones do, respect the few rules that stop records conflicting, check your changes with dig, and use the values your hosting and email providers give you. With that, the DNS panel becomes a tool you can use with confidence rather than a list of acronyms.