DNS Record Types Explained: A, AAAA, CNAME, MX, TXT, NS, and More

What DNS Records Are

DNS records are instructions stored in authoritative nameservers that tell DNS resolvers how to handle requests for your domain. When someone types your domain into a browser, sends you an email, or connects to your API, DNS records direct that traffic to the correct server.

Each record type serves a different purpose. Your domain's DNS zone contains multiple record types working together — A records for web traffic, MX records for email, TXT records for authentication, and more.

DNS Record Types at a Glance

A Record

The A record is the most fundamental DNS record type. It maps a domain name to an IPv4 address — the four-number address format (like 93.184.216.34) that identifies a server on the internet.

When someone types example.com into a browser, the browser's DNS resolver looks up the A record for example.com and connects to the returned IP address.

Key details:

• You can have multiple A records for the same domain (round-robin load balancing)
• A records exist for the apex domain (example.com) and for each subdomain (www.example.com, app.example.com)
• Changing an A record redirects all web traffic to a different server
• TTL (Time to Live) controls how long resolvers cache the record

When to use: Every domain that serves web content needs at least one A record (or an AAAA record for IPv6-only, which is rare). If you use a CDN or load balancer, the A record points to the CDN's or load balancer's IP address.

AAAA Record

The AAAA record is the IPv6 equivalent of the A record. It maps a domain to an IPv6 address — the newer, longer address format (like 2606:2800:220:1:248:1893:25c8:1946).

IPv6 adoption is growing but not universal. Most sites have both A and AAAA records, serving whichever protocol the client supports. If you only have an A record, IPv6-only clients cannot reach your site (though this is rare in practice since most networks support IPv4).

When to use: Add AAAA records alongside A records for any domain that should be accessible over IPv6. Most modern hosting providers and CDNs support IPv6 and provide the AAAA address.

CNAME Record

A CNAME (Canonical Name) record aliases one domain name to another. Instead of pointing to an IP address, it points to a different domain, which is then resolved to get the final IP address.

For example, blog.example.com might have a CNAME pointing to example.ghost.io. When a resolver looks up blog.example.com, it follows the CNAME to example.ghost.io, then resolves that domain's A record to get the IP address.

Key rules:

• A CNAME cannot coexist with other record types at the same name. If blog.example.com has a CNAME, it cannot also have an A record, MX record, or TXT record at that exact name.
• A CNAME cannot be set on the apex domain (example.com) per the DNS specification. Some DNS providers offer workarounds (Cloudflare's CNAME flattening, Route 53's ALIAS records) but these are provider-specific extensions.
• CNAME chains (CNAME pointing to another CNAME) are technically valid but add latency and should be avoided.

When to use: For subdomains that point to external services — CDNs, SaaS platforms, hosted blogs, landing page builders. Common examples: www CNAME to your CDN, blog CNAME to your CMS platform, status CNAME to your status page provider.

MX Record

MX (Mail Exchange) records tell mail servers where to deliver email for your domain. When someone sends an email to user@example.com, the sending server looks up example.com's MX records to find the mail server.

MX records have a priority value (lower number = higher priority). Multiple MX records with different priorities provide redundancy:

10 mail1.example.com
20 mail2.example.com
30 mail3.example.com

Mail servers try the highest-priority record first (10), then fall back to lower-priority records (20, 30) if the primary server is unavailable.

When to use: Every domain that receives email needs MX records. If you use Google Workspace, Microsoft 365, or any email hosting provider, they provide the specific MX records to configure.

TXT Record

TXT records store arbitrary text data associated with your domain. Despite the generic name, TXT records have become critical for email authentication, domain verification, and security policies.

Common uses:

SPF (Sender Policy Framework): Defines which servers are authorized to send email from your domain. Example: v=spf1 include:_spf.google.com ~all. Without SPF, anyone can spoof emails from your domain.

DKIM (DomainKeys Identified Mail): Publishes a public key used to verify email signatures. Receiving servers check DKIM signatures to confirm the email was not modified in transit.

DMARC (Domain-based Message Authentication): Tells receiving servers how to handle email that fails SPF or DKIM checks. Example: v=DMARC1; p=reject; rua=mailto:dmarc@example.com. A DMARC policy of reject prevents phishing emails from being delivered.

Domain verification: Services like Google Search Console, Microsoft 365, and Stripe verify domain ownership by asking you to add a specific TXT record. The presence of the record proves you control the domain's DNS.

When to use: Every domain should have SPF, DKIM, and DMARC records, even if you do not send email from it (set DMARC to reject to prevent spoofing). Add verification TXT records as needed by third-party services.

NS Record

NS (Name Server) records delegate your domain's DNS to specific nameservers. They define which servers are authoritative for your domain — meaning which servers hold the definitive DNS records.

When you register a domain and set your nameservers to Cloudflare, Route 53, or your registrar's nameservers, you are configuring NS records.

Why NS records matter:

• Whoever controls your nameservers controls all of your DNS records
• An unauthorized NS change gives an attacker complete control over your domain's resolution
• NS changes should be extremely rare in normal operations

When to use: NS records are configured once when you set up your domain's DNS and changed only when migrating to a different DNS provider. They should never change unexpectedly.

SOA Record

The SOA (Start of Authority) record contains administrative information about the DNS zone. Every zone has exactly one SOA record. It includes the primary nameserver, the zone administrator's email, a serial number (incremented with each change), and timing values for zone transfers and caching.

The most operationally relevant field is the minimum TTL, which controls how long negative responses (NXDOMAIN — "this record does not exist") are cached. If you create a new subdomain, resolvers that previously cached a negative response for that name will not see the new record until the negative cache expires.

When to use: SOA records are managed automatically by your DNS provider. You rarely need to edit them directly, but understanding the minimum TTL field helps when troubleshooting why a new subdomain is not resolving.

CAA Record

CAA (Certificate Authority Authorization) records specify which Certificate Authorities are allowed to issue SSL/TLS certificates for your domain. They are a security mechanism that prevents unauthorized certificate issuance.

Example records:

0 issue "letsencrypt.org"
0 issue "digicert.com"
0 issuewild "letsencrypt.org"
0 iodef "mailto:security@example.com"

The issue tag authorizes a CA for standard certificates. The issuewild tag authorizes a CA for wildcard certificates. The iodef tag specifies where to send violation reports.

When to use: Add CAA records if you want to restrict which CAs can issue certificates for your domain. This prevents an attacker from obtaining a valid certificate from a different CA (for example, during a domain validation attack). If no CAA record exists, any CA can issue certificates for your domain.

SRV Record

SRV (Service) records specify the location of specific services. Unlike A records (which map a domain to an IP) or MX records (which are specific to email), SRV records are a general mechanism for locating any service.

SRV records contain four fields: priority, weight, port, and target. The format for the record name is _service._protocol.domain.

Example: _sip._tcp.example.com 10 5 5060 sip.example.com tells clients that the SIP service for example.com runs on sip.example.com, port 5060.

Common uses: SIP (VoIP), XMPP (instant messaging), CalDAV/CardDAV, Microsoft 365 autodiscovery, and gaming servers. Not all services use SRV records — most web services use A/CNAME records instead.

PTR Record

PTR (Pointer) records perform reverse DNS lookups — mapping an IP address back to a domain name. They are the inverse of A records.

PTR records live in a special DNS zone managed by the IP address owner (typically your hosting provider or ISP). You usually cannot set PTR records in your domain's DNS zone; you configure them through your hosting provider's control panel.

Why PTR records matter: Email servers check PTR records to verify that the sending server's IP address maps back to a legitimate domain. If your mail server's IP has no PTR record or the PTR points to a generic hostname (like host-192-0-2-1.example.net), receiving servers may reject or spam-filter your email.

When to use: Set PTR records for any server that sends email. Contact your hosting provider to configure the PTR record for your server's IP address.

How Records Work Together

A typical domain uses multiple record types in coordination:

Web traffic: A record (or AAAA) points the domain to your web server's IP. CNAME records alias subdomains to CDNs or platforms.

Email: MX records route incoming email to your mail server. TXT records (SPF, DKIM, DMARC) authenticate outgoing email. PTR records on your mail server's IP validate reverse DNS.

Security: CAA records restrict certificate issuance. TXT records carry DMARC policies. HSTS (via HTTP headers, not DNS) enforces HTTPS.

Infrastructure: NS records delegate DNS authority. SOA records control zone administration. SRV records locate specialized services.

Why Monitoring DNS Records Matters

Every record type represents a potential failure point or attack surface. An unauthorized A record change redirects your website. A modified MX record intercepts your email. A deleted TXT record breaks email authentication. A changed NS record hands control of your entire DNS to an attacker.

DNS monitoring tracks all record types continuously and alerts you when any record changes — whether the change was intentional or not. This is the safety net that catches misconfigurations during migrations, detects unauthorized modifications, and verifies that planned changes propagated correctly.

DNS records are the invisible routing layer that controls where your traffic goes, who can email you, and who can issue certificates for your domain. Understanding them is the first step. Monitoring them is what keeps your domain secure.