The Domain Name System uses different record types to store different kinds of information about a domain. Each record type serves a specific purpose, from mapping a domain to an IP address to routing email to verifying domain ownership for third-party services.
Whether you are setting up a new domain, configuring email, or troubleshooting a connectivity issue, understanding DNS record types is foundational knowledge. This guide covers every major record type with explanations, syntax examples, and practical guidance on when and how to use each one.
Address Records: A and AAAA
Address records are the most fundamental DNS record types. They map a domain name to an IP address, which is the core function of DNS.
A Record (IPv4 Address)
The A record maps a domain name to a 32-bit IPv4 address. This is the record that tells browsers and other clients which server to connect to when they visit your domain.
; Basic A record
example.com. 3600 IN A 203.0.113.50
; A record for a subdomain
blog.example.com. 3600 IN A 203.0.113.51
; Multiple A records for load balancing (round-robin DNS)
example.com. 3600 IN A 203.0.113.50
example.com. 3600 IN A 203.0.113.51
example.com. 3600 IN A 203.0.113.52
When to use: Every domain that hosts a website or any service accessible by IP address needs at least one A record. You can create multiple A records for the same name to distribute traffic across several servers (round-robin DNS).
Common configurations:
- Root domain (
example.com) pointing to your web server - Subdomains (
api.example.com,staging.example.com) pointing to different servers - Mail server hostname (
mail.example.com) referenced by MX records
AAAA Record (IPv6 Address)
The AAAA record (pronounced "quad-A") maps a domain name to a 128-bit IPv6 address. As IPv6 adoption grows, having AAAA records ensures your services are accessible to users and networks that prefer or require IPv6 connectivity.
; AAAA record
example.com. 3600 IN AAAA 2001:db8:85a3::8a2e:370:7334
; Dual-stack: Both A and AAAA records for the same domain
example.com. 3600 IN A 203.0.113.50
example.com. 3600 IN AAAA 2001:db8:85a3::8a2e:370:7334
When to use: If your hosting provider or server supports IPv6, you should add AAAA records alongside your A records (known as dual-stack configuration). This ensures compatibility with IPv6-only networks, which are increasingly common on mobile networks and in certain regions.
Important note: If you set an AAAA record, make sure the IPv6 address is actually reachable and your server is listening on it. A broken AAAA record can cause timeouts for IPv6 users before their devices fall back to IPv4.
Alias Records: CNAME
CNAME Record (Canonical Name)
A CNAME record creates an alias from one domain name to another. Instead of mapping directly to an IP address, the CNAME tells the resolver to look up the target name instead and use its address.
; www subdomain as CNAME to root domain
www.example.com. 3600 IN CNAME example.com.
; Subdomain pointing to a third-party service
blog.example.com. 3600 IN CNAME custom.ghost.io.
shop.example.com. 3600 IN CNAME shops.myshopify.com.
; CDN endpoint
cdn.example.com. 3600 IN CNAME d111111abcdef8.cloudfront.net.
When to use: CNAME records are ideal for subdomains that should point to another hostname, especially third-party services. They are commonly used for www subdomains, CDN endpoints, SaaS platform integrations, and email service verification.
Critical restrictions:
- A CNAME record cannot coexist with any other record type for the same name. You cannot have both a CNAME and an MX record on
example.com. - You should never place a CNAME at the zone apex (the root domain like
example.com). Some DNS providers offer proprietary alternatives (Cloudflare's CNAME flattening, Route 53's ALIAS record) that work around this limitation. - CNAME resolution adds an extra DNS lookup step, which marginally increases resolution time.
Mail Exchange Records: MX
MX Record (Mail Exchange)
MX records specify which mail servers are responsible for accepting email for your domain. When someone sends an email to [email protected], the sending mail server looks up MX records for example.com to determine where to deliver the message.
; Google Workspace MX records
example.com. 3600 IN MX 1 aspmx.l.google.com.
example.com. 3600 IN MX 5 alt1.aspmx.l.google.com.
example.com. 3600 IN MX 5 alt2.aspmx.l.google.com.
example.com. 3600 IN MX 10 alt3.aspmx.l.google.com.
example.com. 3600 IN MX 10 alt4.aspmx.l.google.com.
; Microsoft 365 MX record
example.com. 3600 IN MX 0 example-com.mail.protection.outlook.com.
; Self-hosted mail server
example.com. 3600 IN MX 10 mail.example.com.
example.com. 3600 IN MX 20 backup-mail.example.com.
Priority values: The number before the mail server hostname is the priority (also called preference). Lower numbers indicate higher priority. If the primary mail server (priority 1 or 0) is unreachable, the sending server will try the next server in priority order. This provides redundancy for email delivery.
When to use: Every domain that receives email must have MX records. Even if you do not plan to receive email, having a properly configured null MX record can prevent your domain from being used in bounce-back spam attacks:
; Null MX (RFC 7505) - domain does not accept email
example.com. 3600 IN MX 0 .
Important: MX records must point to a hostname (an A or AAAA record), never directly to an IP address, and never to a CNAME.
Text Records: TXT
TXT Record (Text)
TXT records store arbitrary text strings associated with a domain. While originally designed for human-readable notes, TXT records are now primarily used for machine-readable data, especially email authentication and domain verification.
; SPF record - specifies which servers can send email for your domain
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ~all"
; DKIM record - cryptographic email signature verification
google._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqG..."
; DMARC policy - instructions for handling failed email authentication
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"
; Domain verification for third-party services
example.com. 3600 IN TXT "google-site-verification=dEeMf_abc123..."
example.com. 3600 IN TXT "v=verifydns; token=xyz789"
Common uses for TXT records:
- SPF (Sender Policy Framework): Defines which IP addresses and servers are authorized to send email on behalf of your domain. Receiving mail servers check SPF records to detect forged sender addresses.
- DKIM (DomainKeys Identified Mail): Publishes a public key used to verify cryptographic signatures attached to outgoing emails. DKIM ensures the email content was not altered in transit.
- DMARC (Domain-based Message Authentication, Reporting, and Conformance): Specifies what receiving servers should do when an email fails SPF or DKIM checks (none, quarantine, or reject), and where to send aggregate reports.
- Domain verification: Services like Google Search Console, Microsoft 365, and various SaaS platforms ask you to add a specific TXT record to prove you own the domain.
When to use: Every domain that sends email should have SPF, DKIM, and DMARC records. You will also add TXT records whenever a third-party service requires domain verification. A domain can have multiple TXT records.
You can inspect all TXT records for any domain using the DNSChkr DNS Inspector, which is especially useful for auditing email authentication configurations.
Nameserver Records: NS
NS Record (Name Server)
NS records specify which DNS servers are authoritative for a domain. These records are set at two levels: at the domain registrar (which tells the TLD registry where to direct queries) and within the zone file itself.
; NS records as they appear in the zone file
example.com. 86400 IN NS ns1.dnshost.com.
example.com. 86400 IN NS ns2.dnshost.com.
; Delegated subdomain to different nameservers
internal.example.com. 86400 IN NS ns1.internal-dns.example.com.
internal.example.com. 86400 IN NS ns2.internal-dns.example.com.
When to use: NS records are typically set when you register a domain or change DNS providers. You rarely need to modify NS records in the zone file itself unless you are delegating a subdomain to a different set of nameservers (for example, giving a separate team control over internal.example.com).
Important: NS records should always list at least two nameservers for redundancy. If one nameserver is unreachable, resolvers will query the other.
Start of Authority: SOA
SOA Record (Start of Authority)
The SOA record is a mandatory record at the top of every DNS zone. It contains administrative information about the zone, including the primary nameserver, the email address of the zone administrator, and several timing parameters that control zone transfers and caching.
example.com. 86400 IN SOA ns1.dnshost.com. admin.example.com. (
2025020501 ; Serial number (YYYYMMDDNN format)
3600 ; Refresh interval (1 hour)
900 ; Retry interval (15 minutes)
1209600 ; Expire time (14 days)
300 ; Minimum TTL / negative cache TTL (5 minutes)
)
Field breakdown:
| Field | Example | Purpose |
|---|---|---|
| Primary NS | ns1.dnshost.com. | The primary authoritative nameserver |
| Admin email | admin.example.com. | Zone administrator email (@ replaced with .) |
| Serial | 2025020501 | Version number; must increment on every zone change |
| Refresh | 3600 | How often secondary servers check for updates |
| Retry | 900 | How often to retry if refresh fails |
| Expire | 1209600 | When secondary servers stop serving the zone if primary is unreachable |
| Minimum TTL | 300 | TTL for negative (NXDOMAIN) responses |
When to use: You generally do not need to manually edit the SOA record. Managed DNS providers handle it automatically. However, understanding the SOA is useful when troubleshooting zone transfer issues or when you see unexpected negative caching behavior (controlled by the minimum TTL field).
Service and Security Records: SRV, CAA, and PTR
SRV Record (Service Locator)
SRV records specify the location of specific services associated with a domain. Unlike A or MX records, SRV records include information about the port number and protocol, and support priority and weight for load distribution.
; SRV record format: _service._protocol.name TTL class SRV priority weight port target
_sip._tcp.example.com. 3600 IN SRV 10 60 5060 sipserver.example.com.
_xmpp-server._tcp.example.com. 3600 IN SRV 5 0 5269 xmpp.example.com.
; Microsoft 365 SRV records for Skype/Teams
_sipfederationtls._tcp.example.com. 3600 IN SRV 100 1 5061 sipfed.online.lync.com.
_sip._tls.example.com. 3600 IN SRV 100 1 443 sipdir.online.lync.com.
When to use: SRV records are required by specific protocols and services including SIP (Voice over IP), XMPP (chat), LDAP, CalDAV/CardDAV, and Microsoft 365 federation. You typically add SRV records when a service provider's setup documentation instructs you to.
CAA Record (Certification Authority Authorization)
CAA records specify which Certificate Authorities (CAs) are permitted to issue SSL/TLS certificates for your domain. This provides an additional layer of security against unauthorized certificate issuance.
; Only Let's Encrypt and DigiCert can issue certificates
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issue "digicert.com"
; No CA is authorized to issue wildcard certificates
example.com. 3600 IN CAA 0 issuewild ";"
; Send violation reports to this email
example.com. 3600 IN CAA 0 iodef "mailto:[email protected]"
When to use: CAA records are recommended for all domains, especially those handling sensitive data. If no CAA record exists, any CA can issue a certificate for your domain. Setting CAA records limits this to only the CAs you explicitly authorize.
PTR Record (Pointer / Reverse DNS)
PTR records map an IP address back to a domain name, providing reverse DNS (rDNS) lookup. They are stored in a special zone under in-addr.arpa (for IPv4) or ip6.arpa (for IPv6).
; Reverse DNS for IPv4 address 203.0.113.50
50.113.0.203.in-addr.arpa. 3600 IN PTR mail.example.com.
When to use: PTR records are essential for mail servers. Many receiving mail servers perform reverse DNS lookups on the sending server's IP address and will reject or flag email if the PTR record does not match the server's hostname. PTR records are typically managed by your hosting provider or IP address owner, not in your domain's DNS zone.
How to Inspect and Verify DNS Records
Knowing the theory is important, but you also need practical tools to inspect what records are actually configured and whether they are resolving correctly.
Using DNSChkr DNS Inspector
The DNSChkr DNS Inspector lets you query any domain and see all configured records organized by type. This is useful for:
- Auditing your complete DNS configuration at a glance
- Verifying that records you added or changed are resolving correctly
- Checking email authentication records (SPF, DKIM, DMARC) for correctness
- Comparing expected versus actual record values
Using DNSChkr Propagation Checker
When you add or modify a record, the DNSChkr Propagation Checker lets you check whether the change has propagated to DNS servers across multiple global regions. Select the specific record type you changed and verify that servers worldwide are returning the expected value.
Command-Line Tools
For quick lookups from your terminal, dig (on macOS and Linux) and nslookup (on all platforms) are useful:
# Query A record
dig example.com A +short
# Query MX records
dig example.com MX +short
# Query TXT records (useful for SPF/DKIM/DMARC)
dig example.com TXT +short
# Query a specific nameserver
dig @8.8.8.8 example.com A +short
# Query SOA record
dig example.com SOA
# Query CAA records
dig example.com CAA +short
Frequently Asked Questions
Key Takeaways
- A and AAAA records are the foundation of DNS, mapping domain names to IPv4 and IPv6 addresses respectively. Every website needs at least an A record.
- CNAME records create aliases from one name to another. They are ideal for subdomains and third-party service integrations but cannot be used at the zone apex or alongside other record types for the same name.
- MX records route email to the correct mail servers. Priority values determine failover order, and every domain that receives email must have MX records.
- TXT records store text data used for email authentication (SPF, DKIM, DMARC) and domain verification. These are critical for email deliverability and security.
- NS records delegate authority for a domain to specific nameservers. They are set at your registrar and within the zone file.
- SOA records contain administrative metadata about the zone, including the serial number and timing parameters for zone transfers and negative caching.
- SRV records locate specific services (SIP, XMPP, etc.) with port and priority information.
- CAA records restrict which Certificate Authorities can issue SSL/TLS certificates for your domain, adding a security layer against unauthorized issuance.
- PTR records provide reverse DNS, mapping IP addresses back to hostnames. They are essential for mail server reputation.
- Use the DNSChkr DNS Inspector to view and verify all record types for any domain in one place.
Need to check the DNS records configured for your domain? Use the DNSChkr DNS Inspector to see every record type at a glance, or verify changes are propagating worldwide with the DNSChkr Propagation Checker.