DNS Record Types Explained

A DNS record is an instruction stored in an authoritative DNS zone file that directs internet traffic, connects hostnames to IP addresses, and routes email to destination mail servers. If you are new to DNS administration, start with our guide on what is a DNS record. 

Each DNS record type serves a specific network function, from resolving hostnames to authenticating message senders. The quick-reference guide below breaks down the 12 most common DNS record types you will encounter in production environments.

Simplify DNS Records with PowerDMARC! [KEEP SAME]

DNS Record Types

The table below outlines the twelve primary DNS record types used across web routing, mail exchange, and infrastructure security:

A Record

An A record (Address record) maps a domain name or subdomain to an IPv4 address. When a user enters a web address in a browser, the recursive resolver queries the A record to locate the web server hosting the site.

Example:

example.com. 3600 IN A 192.0.2.1

AAAA Record

An AAAA record (Quad-A record) functions like an A record but maps a hostname to a 128-bit IPv6 address instead of a 32-bit IPv4 address. Because the global pool of available IPv4 addresses is exhausted, modern networks deploy AAAA records alongside standard A records to support dual-stack routing for visitors on IPv6-enabled internet providers.

Example:

example.com. 3600 IN AAAA 2001:0db8:85a3:0000:0000:8a2e:0370:7334

CNAME Record

A CNAME record (Canonical Name record) creates an alias pointing one domain name to another canonical domain name rather than to an IP address. When a resolver encounters a CNAME record, it restarts the lookup process using the target domain name. CNAME records cannot coexist with other records at the zone root apex.

Example:

blog.example.com. 3600 IN CNAME webhost.example.net.

MX Record

An MX record (Mail Exchanger record) tells sending mail transfer agents where to deliver incoming email for a given domain. MX records always include a priority preference number alongside the mail host name, where lower integers take precedence. This is the DNS record type that identifies an email server responsible for processing inbound messages.

Example:

example.com. 3600 IN MX 10 aspmx.l.google.com.

TXT Record

A TXT record (Text record) attaches machine-readable text attributes to a domain. While originally created to hold human-readable notes, TXT records now serve primarily as the transport mechanism for domain verification tokens and email authentication frameworks. See our dedicated section below for how SPF, DKIM, and DMARC rely on TXT records.

Example:

example.com. 3600 IN TXT “google-site-verification=rXOxyZounnZ…”

NS Record

An NS record (Name Server record) indicates which authoritative DNS servers maintain the definitive DNS records for a domain or delegated sub-zone. Every domain requires at least two functional NS records pointing to geographically distributed nameservers to maintain high availability and prevent domain resolution outages.

Example:

example.com. 86400 IN NS ns1.powerdns-cloud.com.

SOA Record

An SOA record (Start of Authority record) is a mandatory record located at the apex of every DNS zone. It declares core administrative metadata about the zone, including the primary master nameserver, the technical administrator contact email address, the zone serial number, and operational timers that control caching and secondary zone transfers.

The timers defined in the SOA record include the refresh interval (how frequently secondary servers query the master for updates), the retry interval (the waiting window after a failed transfer attempt), the expire limit (when secondary servers discard stale zone data if the master remains unreachable), and the minimum TTL (which controls how long resolvers cache negative lookup responses like NXDOMAIN).

Example:

example.com. 86400 IN SOA ns1.example.com. hostmaster.example.com. (
2026101001 ; serial
7200 ; refresh (2 hours)
3600 ; retry (1 hour)
1209600 ; expire (2 weeks)
3600 ) ; minimum TTL (1 hour)

You can inspect your domain SOA parameters using our SOA record lookup tool.

PTR Record

A PTR record (Pointer record) performs the opposite task of an A record by resolving an IP address back to its associated hostname through reverse DNS resolution. PTR records are configured inside dedicated reverse lookup zones (in-addr.arpa for IPv4 and ip6.arpa for IPv6) administered by the owner of the IP space rather than the domain registrar.

Receiving email servers routinely run reverse DNS checks against the connecting IP address of outbound mail transfer agents. If the sending IP address lacks a matching PTR record that aligns with the sender’s forward hostname, corporate spam filters and major webmail providers frequently reject the inbound message. You can verify your reverse zone entries with our PTR record lookup tool.

Example:

1.2.0.192.in-addr.arpa. 3600 IN PTR mail.example.com.

SRV Record

An SRV record (Service record) defines the location, protocol, port number, priority, and weight of servers providing specific application services. Instead of assuming standard ports, network clients query SRV records to discover custom connection parameters for protocols like SIP (VoIP), LDAP directory services, and XMPP messaging.

The SRV record structure begins with the service name and protocol prefixed with underscores (such as _sip._tcp.example.com), followed by priority and weight values for load balancing, the destination port number, and the target hostname providing the service.

Example:

_sip._tcp.example.com. 3600 IN SRV 10 60 5060 bigbox.example.com.

CAA Record

A CAA record (Certification Authority Authorization record) allows a domain owner to specify which Certificate Authorities (CAs) have permission to issue public SSL/TLS certificates for their domain and subdomains. When an engineer requests an SSL certificate, compliant CAs must check the domain CAA record before completing issuance.

Publishing CAA records protects your organization against unauthorized or fraudulent certificate generation, reducing exposure if a rogue CA is compromised. The record contains an issuer flag, a property tag (issue, issuewild, or iodef for security violation incident reporting), and the approved CA identifier. You can evaluate your certificate authorization policy with our CAA checker.

Example:

example.com. 3600 IN CAA 0 issue “letsencrypt.org”

DNSSEC Records (DNSKEY, DS)

Domain Name System Security Extensions (DNSSEC) protect resolvers against DNS spoofing, cache poisoning, and man-in-the-middle manipulation by attaching cryptographic signatures to DNS records. DNSSEC relies on two essential records: DNSKEY and DS.

A DNSKEY record stores public signing keys inside the child zone. Authoritative servers publish Zone Signing Keys (ZSK) to sign individual record sets and Key Signing Keys (KSK) to sign the zone keys themselves. A DS record (Delegation Signer) holds a cryptographic hash of the child zone Key Signing Key and is published directly in the parent zone (such as .com or .org). Resolvers trace this cryptographic chain of trust upward to the root DNS zone to verify that query answers have not been altered in transit. Verify your signing setup with our DNSSEC checker.

DNSKEY Example:

example.com. 3600 IN DNSKEY 257 3 13 oJM7nE…9yZ==

DS Example:

example.com. 3600 IN DS 2371 13 2 4f2e9a18…cb02

Email Authentication Records: SPF, DKIM, DMARC

A common point of confusion is treating SPF, DKIM, DMARC, BIMI, and MTA-STS as standalone DNS record types. In the DNS protocol specification, these are not unique resource record types. They are standardized configuration policies published as TXT records (or occasionally CNAME records for hosted DKIM selectors) hosted at designated hostnames and subdomains.

When a remote mail server receives a message claiming to originate from your domain, it queries these text strings to verify whether the sender is authorized, whether the message body was altered in transit, and what disposition action to apply if validation fails:

Because these authentication policies reside in standard TXT entries, typographical mistakes or improper syntax can immediately disrupt your email deliverability. Run your domain through our free Domain Analyzer to confirm your SPF, DKIM, and DMARC records are syntactically sound and protected against domain spoofing.

How to Look Up Each DNS Record Type

You can inspect the DNS records published for any domain using web-based tools or command-line utilities.

For a fast assessment across global recursive resolvers, use our free DNS record lookup tool. It retrieves A, AAAA, MX, CNAME, TXT, NS, SOA, and PTR records without requiring software installation.

If you prefer troubleshooting from a terminal:

• On macOS and Linux: Use dig to query specific record types:
  

dig example.com MX

• On Windows: Use nslookup specifying the query type:
  

nslookup -type=MX example.com

When evaluating responses, pay attention to the Time to Live (TTL) value. If you recently updated a DNS record, recursive resolvers will continue returning the previous cached entry until that TTL expires. You can monitor update progress across regions with our DNS propagation checker.

Why Each DNS Record Type Matters

DNS records provide the underlying map for every internet transaction. When records are configured properly, browsers resolve websites instantly, mail gateways route messages without friction, and cryptographic headers validate legitimate senders.

When a DNS record is misconfigured, missing, or pointing to retired infrastructure, critical services break immediately:

• An incorrect or missing A/AAAA record takes your website offline.
• A misconfigured MX record causes incoming emails to bounce back to senders.
• A missing or invalid TXT authentication record flags marketing and transactional emails as spam.
• A dangling CNAME pointing to an abandoned third-party host exposes your domain to hostile subdomain takeover.

Maintaining clean zone records and adhering to established DNS security best practices ensures your core digital infrastructure remains available, performant, and protected against interception attacks.

Final Words

Understanding DNS record types is essential for anyone responsible for domain administration, web performance, and email security. Each record type executes a dedicated role, from translating hostnames with A and AAAA records to establishing cryptographic email trust via TXT entries. Regular audits of your DNS zone files keep your network services running smoothly while safeguarding your brand against spoofing and dangling record vulnerabilities.

Frequently Asked Questions

How many DNS record types are there?

The Internet Assigned Numbers Authority (IANA) maintains a registry of dozens of official DNS resource record types. While many types are historical, experimental, or retired, production domains rely heavily on a core set of approximately 12 to 15 standard record types for routine web routing, mail delivery, and domain security.

What is the most common DNS record type?

The A record is the most common and fundamental DNS record type on the internet. Nearly every domain name hosted on the web requires at least one A record to map its human-readable domain name or subdomain to an accessible IPv4 address.

Which DNS record types do I need for email?

To send and receive email reliably, you need an MX record pointing to your mail server, valid A or AAAA records for that mail server host, and a corresponding PTR record for reverse DNS validation. In addition, you need TXT records configured for SPF and DMARC, along with TXT or CNAME records for DKIM.

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

An A record maps a hostname directly to a physical IPv4 address (example.com to 192.0.2.1). A CNAME record maps an alias hostname to another canonical domain name (blog.example.com to webhost.example.net). To compare lookup flows and apex limitations, review our guide on A record vs CNAME.

How long do DNS record changes take to apply?

DNS changes take anywhere from a few minutes up to 48 hours to apply globally. The update speed depends on the Time to Live (TTL) set on the existing record, which specifies how long intermediate resolvers can store the answer before querying authoritative nameservers for a fresh copy.