DNS Record Types Explained

DNS records control where a domain points, how email is routed, which services are available, and what security policies apply. This guide is the central DNScale reference for choosing record types, reading examples, avoiding common mistakes, and checking results with DNS tools.

If you already know the record type you need, jump to the quick reference table. If you are deciding between options, start with A record vs CNAME record, DNS records for email, or DNS record conflicts and mistakes.

Quick Reference

DNScale documents customer-managed standard and modern record types in the records API. SOA is also explained here because every authoritative zone has one; the apex SOA and apex NS records are usually provider-managed system records, not routine records you edit by hand.

What Is a DNS Record?

A DNS record is an instruction inside a DNS zone. Each record normally has:

Record conflicts matter because DNS has rules about which records can coexist. A CNAME must usually be the only record at its name. MX targets must resolve. DNSSEC DS and DNSKEY data must match. TTLs control how quickly changes become visible after resolvers cache old answers.

A Records

An A record maps a name to an IPv4 address.

Name: www
Type: A
Value: 192.0.2.10
TTL: 300

Use A records when you control the IPv4 address, when you need the apex domain to point to a server, or when other records must coexist at the same name.

Common mistakes:

• Using a private IP address such as 10.0.0.5 for a public website.
• Forgetting to update both apex and www.
• Setting a high TTL before a migration.

AAAA Records

An AAAA record maps a name to an IPv6 address.

Name: www
Type: AAAA
Value: 2001:db8::10
TTL: 300

Use AAAA records for dual-stack services so IPv6-capable clients can connect directly. Pair them with A records when the same service supports IPv4 and IPv6.

Common mistakes:

• Publishing AAAA before the service actually listens on IPv6.
• Forgetting IPv6 firewall rules.
• Testing only from IPv4 networks.

CNAME Records

A CNAME record aliases one hostname to another hostname.

Name: docs
Type: CNAME
Value: example.gitbook.io.
TTL: 3600

Use CNAME records for subdomains that should follow a third-party service, CDN, or SaaS target. Do not use a CNAME at a name that also needs MX, TXT, CAA, or other record data.

Common mistakes:

• Putting a CNAME at the apex/root domain.
• Creating long CNAME chains.
• Combining CNAME with TXT verification at the same name.

For a deeper decision framework, read CNAME vs A record.

MX Records

MX records tell senders where to deliver email for a domain. They include a priority and a mail server hostname.

Name: example.com.
Type: MX
Value: 10 mail.example.com.
TTL: 3600

Use MX records for domains and subdomains that receive email. Lower priority numbers are preferred.

Common mistakes:

• Pointing MX to a hostname that has no A or AAAA record.
• Missing the provider-required priority.
• Using a CNAME as the MX target when the mail provider expects a direct hostname.

TXT Records

TXT records store text values. They are widely used for email authentication and domain verification.

Name: example.com.
Type: TXT
Value: v=spf1 include:_spf.example.com -all
TTL: 3600

Use TXT records for SPF, DKIM, DMARC, Google/Microsoft verification, MTA-STS reporting, and service-specific ownership checks.

Common mistakes:

• Publishing multiple SPF records at the same name.
• Putting DMARC at example.com instead of _dmarc.example.com.
• Leaving stale verification records after a migration.

NS Records

NS records identify authoritative nameservers. At the parent zone, they delegate the domain to a DNS provider. Inside a zone, they can delegate a subdomain.

Name: dev.example.com.
Type: NS
Value: ns1.dev-provider.net.
TTL: 3600

Use NS records carefully. Parent-zone delegation and in-zone NS records need to agree during migrations.

Common mistakes:

• Parent and child NS records disagreeing after a provider migration.
• Delegating a subdomain without creating the child zone.
• Changing NS records without lowering TTLs first.

SOA Records

An SOA record stores zone authority metadata: primary nameserver, responsible mailbox, serial number, refresh, retry, expire, and minimum/negative-cache TTL.

Name: example.com.
Type: SOA
Value: ns1.dnscale.eu. hostmaster.example.com. 2026060901 3600 600 604800 300

Every authoritative zone has an SOA record. In managed DNS, the apex SOA is usually generated and maintained by the provider.

Common mistakes:

• Treating the SOA serial as application state.
• Misreading negative-cache TTL as a normal record TTL.
• Trying to hand-edit provider-managed SOA data during a migration.

CAA Records

CAA records restrict which public certificate authorities can issue TLS certificates for a domain.

Name: example.com.
Type: CAA
Value: 0 issue "letsencrypt.org"
TTL: 3600

Use CAA records when you want explicit certificate authority policy. Add issuewild when wildcard certificates should have separate rules.

Common mistakes:

• Forgetting the CA used by your CDN or hosting provider.
• Leaving old CA values after moving certificate automation.
• Making the record too restrictive before a certificate renewal.

SRV Records

SRV records publish service location, including priority, weight, port, and target.

Name: _sip._tcp.example.com.
Type: SRV
Value: 10 5 5060 sip.example.com.
TTL: 3600

Use SRV records for protocols that explicitly support service discovery, such as SIP, XMPP, LDAP, Kerberos, and some game servers.

Common mistakes:

• Missing the leading service and protocol labels, such as _sip._tcp.
• Forgetting that the SRV target still needs A/AAAA records.
• Mixing up priority and weight.

PTR Records

PTR records map an IP address back to a hostname in a reverse DNS zone.

Name: 10.2.0.192.in-addr.arpa.
Type: PTR
Value: host.example.com.
TTL: 3600

Use PTR records for reverse DNS, especially mail server reputation and infrastructure identification. In many cases, the IP address owner controls the reverse zone, not the domain owner.

Common mistakes:

• Trying to set PTR in the forward zone.
• Publishing PTR that does not match the server's forward A/AAAA records.
• Assuming you can control reverse DNS for cloud IPs without provider support.

Advanced Record Types

TLSA Records

TLSA records publish DANE certificate associations. They are only meaningful when DNSSEC validation protects the zone.

SSHFP Records

SSHFP records publish SSH host key fingerprints so clients can verify host keys through DNSSEC-protected DNS.

HTTPS Records

HTTPS records publish web service metadata such as HTTP/3 support, alternative endpoints, and ECH-related hints.

SVCB Records

SVCB records are the generic service-binding form behind HTTPS records.

ALIAS Records

ALIAS records provide CNAME-like behavior at the apex while allowing required apex records such as SOA, NS, MX, and TXT to coexist.

DNS Record Examples

To manage these as code, see Managing DNS with Terraform and the DNScale API records docs.

A Record vs CNAME Record

Use A records when you control the destination IP or need the apex domain. Use CNAME when a subdomain should follow a provider-controlled hostname. If you need CNAME-like behavior at the apex, use ALIAS records where supported.

DNS Records for Email

Email DNS usually combines several record types:

Use the SPF validator, DKIM validator, and DMARC validator to check common email DNS mistakes. For the full email-authentication overview, read email security with SPF, DKIM, and DMARC.

DNS TTL Explained

TTL means time to live. It tells recursive resolvers how long they can cache an answer.

Lower TTLs before a planned migration, wait for old caches to expire, make the change, verify, then restore a normal TTL. For details, read DNS TTL best practices and use the DNS propagation checker after changes.

DNS Record Conflicts and Mistakes

For broad troubleshooting, see DNS troubleshooting, SERVFAIL explained, and NXDOMAIN explained.

How To Check DNS Records

Use the right tool for the question:

After a DNS change, check authoritative answers first, then recursive resolver caches. A resolver serving the old answer may simply be honoring the previous TTL.

Managing DNS Records With DNScale

DNScale lets you manage authoritative DNS records through the dashboard, API, Terraform provider, and DNSControl.

If multiple people or environments touch DNS, pick one source of truth per zone. For Terraform, use the DNScale Terraform provider guide. For JavaScript-based DNS as code, use the DNSControl guide. For direct API automation, start with the records API docs.

Related Guides and Tools

Start Managing Records Safely

Need to manage records across multiple domains? DNScale gives you authoritative DNS with dashboard editing, API access, Terraform, DNSControl, DNSSEC tooling, and record-checking tools for safe changes.

• Start free
• Read the Terraform DNS provider guide
• Check a DNS record