DNS Record Types Explained — A, AAAA, CNAME, MX, TXT & More

Last Updated: October 2026

What Are DNS Records?

The Domain Name System (DNS) is often called the phonebook of the internet. When you type example.com into your browser, your computer doesn't know how to reach that server by name alone — it needs an IP address. DNS records are the entries in that phonebook: structured data stored on authoritative name servers that map human-readable domain names to the machine-readable information needed to locate services, deliver email, verify ownership, and more.

Every domain has a set of DNS records managed through a DNS hosting provider (like Cloudflare, AWS Route 53, Google Cloud DNS, or your domain registrar's built-in DNS). These records are organized into a zone file — a text file that contains all the DNS records for a domain. When a DNS resolver receives a query for your domain, it contacts the authoritative name servers listed in your domain's NS records and retrieves the relevant record from the zone file.

Understanding DNS record types is essential for anyone managing a website, configuring email, setting up subdomains, or troubleshooting connectivity issues. For a broader introduction to how DNS works, see our guide on what is DNS.

A Record (Address Record)

The A record is the most fundamental DNS record type. It maps a domain name to an IPv4 address — the 32-bit numeric address that identifies a server on the internet (e.g., 93.184.216.34).

When you type example.com into your browser, the DNS resolver queries the A record for example.com to get the IP address of the web server. Without an A record, your domain cannot be reached by browsers or other IPv4 clients.

You can have multiple A records for the same domain, each pointing to a different IP address. This is called round-robin DNS and is a simple form of load balancing — the resolver returns all IPs and the client typically connects to the first one. Large services like Google and Netflix use this technique alongside more sophisticated load balancing.

How to query an A record:

• dig example.com A (Linux/macOS)
• nslookup -type=A example.com (Windows)
• Use our DNS Lookup tool online

AAAA Record (IPv6 Address Record)

The AAAA record (pronounced "quad-A") is the IPv6 equivalent of the A record. It maps a domain name to a 128-bit IPv6 address (e.g., 2606:2800:0220:0001:0248:1893:25c8:1946). As IPv4 addresses become increasingly scarce, IPv6 adoption continues to grow — as of 2026, roughly 45% of internet traffic uses IPv6.

If your server has an IPv6 address, you should add an AAAA record alongside your A record. This enables dual-stack connectivity, where clients that support IPv6 connect via the AAAA record and clients that only support IPv4 fall back to the A record. Modern operating systems and browsers prefer IPv6 when both are available, as it often provides slightly better performance due to more efficient routing.

How to query: dig example.com AAAA or nslookup -type=AAAA example.com

CNAME Record (Canonical Name)

A CNAME record creates an alias from one domain name to another. Instead of pointing directly to an IP address, a CNAME says "this name is actually the same as that name — go look up that name instead." The target of a CNAME is called the canonical name.

The most common use of CNAME records is pointing www.example.com to example.com (or vice versa), so both names resolve to the same server. CNAMEs are also essential when using CDNs (Content Delivery Networks), cloud hosting platforms, and SaaS services. For example, when you set up a custom domain on GitHub Pages, Netlify, or Vercel, they instruct you to create a CNAME record pointing your domain to their servers.

Important CNAME rules:

• A CNAME record cannot coexist with any other record type for the same name. If blog.example.com has a CNAME, it cannot also have an A record, MX record, or TXT record at that same name.
• A CNAME record cannot be used at the zone apex (the bare domain, like example.com without any subdomain). This is because the zone apex must have NS and SOA records, and CNAMEs conflict with them. Some DNS providers offer proprietary workarounds like ALIAS or ANAME records for this use case.
• CNAME resolution adds an extra DNS lookup step, which can slightly increase latency compared to using A records directly.

How to query: dig example.com CNAME or nslookup -type=CNAME www.example.com

MX Record (Mail Exchange)

MX records tell the internet which mail servers are responsible for accepting email for your domain. Without MX records, nobody can send email to you@yourdomain.com.

Each MX record has two components: a priority value (a positive integer) and the hostname of the mail server. The priority determines the order in which sending servers try to deliver mail — lower numbers mean higher priority. A typical configuration looks like:

• 10 mail1.example.com — Primary mail server (tried first)
• 20 mail2.example.com — Secondary mail server (backup, tried if primary is unavailable)
• 30 mail3.example.com — Tertiary mail server (last resort)

When someone sends an email to user@example.com, the sending mail server queries the MX records for example.com, sorts them by priority, and attempts delivery starting with the lowest-numbered (highest priority) server. If that server is unreachable, it tries the next one, and so on.

If you use a hosted email service like Google Workspace, Microsoft 365, or Zoho Mail, you configure your MX records to point to their mail servers. For example, Google Workspace MX records point to aspmx.l.google.com with various priorities for their backup servers.

Important: MX records must point to a hostname, not an IP address. The hostname referenced by an MX record must have its own A or AAAA record — it should not point to a CNAME.

How to query: dig example.com MX or nslookup -type=MX example.com

TXT Record (Text Record)

TXT records store arbitrary text data associated with a domain name. Originally designed for human-readable notes, TXT records are now critical for email authentication, domain verification, and security policies. A domain can have multiple TXT records.

SPF (Sender Policy Framework)

An SPF record is a TXT record that specifies which mail servers are authorized to send email on behalf of your domain. It helps receiving servers detect forged sender addresses (spoofing). An SPF record starts with v=spf1 followed by a list of authorized senders:

• v=spf1 include:_spf.google.com ~all — Authorizes Google Workspace servers; soft-fail everything else.
• v=spf1 ip4:203.0.113.0/24 include:sendgrid.net -all — Authorizes a specific IP range and SendGrid; hard-fail everything else.

The -all (hard fail) tells receivers to reject unauthorized senders outright. ~all (soft fail) marks them as suspicious but still delivers. Always set up SPF if you send email from your domain.

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to every outgoing email. The private key signs the email on the sending server, and the public key is published as a TXT record in DNS so receiving servers can verify the signature. A DKIM TXT record looks like:

• selector1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."

The "selector" allows multiple DKIM keys for the same domain (useful when rotating keys or using multiple email services). If the signature verification fails, the receiving server knows the email was tampered with or not sent by an authorized server.

DMARC (Domain-based Message Authentication, Reporting & Conformance)

DMARC builds on SPF and DKIM by telling receiving servers what to do when authentication checks fail, and where to send reports about authentication results. A DMARC TXT record is published at _dmarc.example.com:

• v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; pct=100 — Reject 100% of emails that fail both SPF and DKIM; send aggregate reports to the specified address.
• v=DMARC1; p=quarantine; rua=mailto:reports@example.com; pct=50 — Quarantine 50% of failing emails.

Start with p=none (monitoring only) to collect reports and understand your email flow before moving to p=quarantine or p=reject.

Domain Verification

Many services (Google Search Console, Microsoft 365, Stripe, AWS SES) verify that you own a domain by asking you to add a specific TXT record. For example, Google might ask you to add google-site-verification=abc123.... Once their systems detect the record, ownership is confirmed.

How to query: dig example.com TXT or nslookup -type=TXT example.com

NS Record (Name Server)

NS records declare which name servers are authoritative for a domain — that is, which servers hold the definitive DNS records for the zone. Every domain must have at least two NS records for redundancy. When a DNS resolver needs to look up records for your domain, it first queries the parent zone (e.g., the .com TLD servers) to find your NS records, then contacts those name servers directly.

If you use Cloudflare for DNS, your NS records might be anna.ns.cloudflare.com and bob.ns.cloudflare.com. If you use AWS Route 53, they will be four ns-xxxx.awsdns-xx.xx hostnames. Changing your NS records is how you delegate your domain's DNS to a different provider.

How to query: dig example.com NS or nslookup -type=NS example.com

SOA Record (Start of Authority)

The SOA record is a mandatory record present at the top of every DNS zone. It contains administrative information about the zone:

• Primary name server: The authoritative server for the zone (MNAME).
• Responsible person: An email address encoded in DNS format (RNAME), e.g., admin.example.com represents admin@example.com.
• Serial number: A version number that increments with every zone change. Secondary name servers use this to determine whether they need to request a zone transfer.
• Refresh interval: How often secondary servers should check the primary for updates.
• Retry interval: How long a secondary server waits before retrying a failed refresh.
• Expire time: How long a secondary server continues to serve the zone if it cannot contact the primary.
• Minimum TTL: The TTL used for negative caching (how long resolvers cache "this record does not exist" responses).

How to query: dig example.com SOA or nslookup -type=SOA example.com

SRV Record (Service Location)

SRV records specify the hostname and port number for specific services running on a domain. While most DNS records only provide a hostname (and clients connect to the default port for that service), SRV records explicitly define both the target host and port, along with priority and weight for load balancing.

The format is _service._protocol.name TTL class SRV priority weight port target. For example:

• _sip._tcp.example.com 3600 IN SRV 10 60 5060 sipserver.example.com — SIP service on TCP, priority 10, weight 60, port 5060, at sipserver.example.com.
• _minecraft._tcp.play.example.com 3600 IN SRV 0 5 25565 mc1.example.com — Minecraft server on a custom subdomain.

SRV records are used by VoIP/SIP, XMPP (Jabber) chat, Microsoft Active Directory, Minecraft multiplayer servers, CalDAV/CardDAV, and other protocols that benefit from service discovery. Not all applications support SRV records — HTTP/HTTPS notably does not.

How to query: dig _sip._tcp.example.com SRV

PTR Record (Pointer / Reverse DNS)

PTR records provide reverse DNS lookups — they map an IP address back to a domain name, the opposite of what A and AAAA records do. PTR records are stored in special zones: for IPv4, the in-addr.arpa zone (with octets reversed); for IPv6, the ip6.arpa zone.

For example, to create a PTR record for IP 203.0.113.25, you create a record at 25.113.0.203.in-addr.arpa that points to mail.example.com.

Reverse DNS is critical for email deliverability. Many receiving mail servers check that the sending server's IP address has a PTR record that matches the server's hostname (forward-confirmed reverse DNS). If the PTR record is missing or doesn't match, your emails are more likely to be flagged as spam or rejected outright. PTR records are also used in log analysis and security investigations to identify the hostnames behind IP addresses.

PTR records are managed by whoever controls the IP address block — typically your ISP or hosting provider. You usually need to request PTR record creation through their control panel or support team.

How to query: dig -x 203.0.113.25 or nslookup 203.0.113.25

CAA Record (Certificate Authority Authorization)

CAA records specify which Certificate Authorities (CAs) are allowed to issue SSL/TLS certificates for your domain. This is a security measure that prevents unauthorized CAs from issuing certificates, reducing the risk of man-in-the-middle attacks using fraudulently obtained certificates.

CAA records have three components: flags (usually 0), a tag (issue, issuewild, or iodef), and a value:

• 0 issue "letsencrypt.org" — Only Let's Encrypt may issue certificates for this domain.
• 0 issuewild "digicert.com" — Only DigiCert may issue wildcard certificates.
• 0 iodef "mailto:security@example.com" — Send violation reports to this email address.
• 0 issue ";" — No CA is authorized to issue certificates (effectively blocks all issuance).

Since September 2017, all publicly trusted CAs are required to check CAA records before issuing a certificate. If no CAA record exists, any CA may issue. Adding CAA records is a low-effort, high-value security improvement for any domain.

How to query: dig example.com CAA

NAPTR Record (Naming Authority Pointer)

NAPTR records are used in conjunction with SRV records for advanced service discovery, particularly in telecommunications. They define rules for rewriting domain names, mapping them to URIs, or chaining to further lookups. NAPTR is used by ENUM (telephone number mapping to SIP URIs), the Session Initiation Protocol, and certain DDDS (Dynamic Delegation Discovery System) applications.

NAPTR records are complex and specialized. Most domain administrators will never need to create one directly, but they are essential infrastructure for VoIP providers and telecom systems.

ALIAS / ANAME Records

ALIAS and ANAME records are not part of the official DNS specification (RFC standards) but are proprietary extensions offered by some DNS providers (Cloudflare, AWS Route 53, DNSimple, NS1). They solve the problem of CNAME records not being allowed at the zone apex.

An ALIAS/ANAME record works like a CNAME in that it points to another hostname, but the DNS server resolves it to IP addresses before responding to the client. This means you can point your bare domain (example.com) to a CDN, load balancer, or cloud service hostname without the limitations of CNAME records. The client receives A/AAAA records transparently.

If your DNS provider supports ALIAS/ANAME, it is the recommended way to point your root domain to services that only provide a hostname (like AWS Elastic Load Balancer, Heroku, or Netlify).

How to Query DNS Records

Being able to query DNS records is essential for troubleshooting and verifying your DNS configuration. Here are the most common tools:

Using dig (Linux / macOS)

dig (Domain Information Groper) is the most powerful command-line DNS tool. It provides detailed output including the answer section, authority section, and additional section:

• dig example.com — Queries the default record type (A).
• dig example.com MX — Queries MX records.
• dig example.com TXT +short — Shows only the answer, without headers.
• dig @1.1.1.1 example.com — Queries a specific DNS server (Cloudflare).
• dig example.com ANY — Requests all record types (some servers block ANY queries).
• dig +trace example.com — Traces the full resolution path from root servers down to the authoritative answer.

Using nslookup (Windows / Cross-platform)

nslookup is available on Windows, macOS, and Linux. It's simpler than dig but less detailed:

• nslookup example.com — Queries the A record using the default DNS server.
• nslookup -type=MX example.com — Queries MX records.
• nslookup -type=TXT example.com 8.8.8.8 — Queries TXT records using Google DNS.
• nslookup -type=NS example.com — Lists the authoritative name servers.

Using Our Online DNS Lookup Tool

Our DNS Lookup tool lets you query any record type for any domain directly from your browser, without installing or configuring anything. It's particularly useful for quick checks, verifying DNS changes from an external perspective, and sharing results with colleagues.

TTL Best Practices

TTL (Time to Live) is the number of seconds a DNS resolver should cache a record before requesting a fresh copy from the authoritative name server. Choosing the right TTL is a balance between performance (higher TTL = fewer queries, faster resolution from cache) and flexibility (lower TTL = faster propagation when you make changes).

• 300 seconds (5 minutes): For records that change frequently, such as during migrations, A/B testing, or failover scenarios. Also recommended as a temporary setting before making planned DNS changes.
• 3600 seconds (1 hour): A good general-purpose default. Balances cache efficiency with reasonable propagation time.
• 86400 seconds (24 hours): For stable records that rarely change, like MX records pointing to a well-established email provider or NS records for your domain.

Pro tip for DNS migrations: At least 24–48 hours before making a change, lower the TTL on the affected records to 300 seconds. This ensures that when you make the actual change, all caches will pick up the new value within 5 minutes. After the change has propagated and you've verified it's correct, raise the TTL back to its normal value.

DNS Propagation

When you create or modify a DNS record, the change doesn't take effect instantly across the entire internet. DNS propagation is the process of the updated record spreading to all DNS resolvers worldwide as their cached copies of the old record expire based on the TTL.

Propagation time depends on several factors:

• Previous TTL value: If the old record had a TTL of 86400 (24 hours), some resolvers may serve the old record for up to 24 hours after the change.
• Resolver caching behavior: Some resolvers honor TTLs strictly; others may cache slightly longer. ISP resolvers are often less aggressive about refreshing caches.
• Geographic distribution: Resolvers close to your authoritative servers may pick up changes faster than those on the other side of the world.
• Negative caching: If a record didn't previously exist, the "no such record" response was cached according to the SOA minimum TTL. You may need to wait for that negative cache to expire.

You can check propagation progress using online tools that query DNS from multiple global locations, or by using dig @specific-resolver example.com to check individual resolvers.

Common DNS Configurations

Basic Website Setup

A minimal DNS configuration for a website typically includes:

• An A record for the bare domain (example.com) pointing to your server's IPv4 address.
• An AAAA record for IPv6 (if your server supports it).
• A CNAME record for www.example.com pointing to example.com.
• At least two NS records for your authoritative name servers.
• An SOA record (usually auto-generated by your DNS provider).

Email Setup

A complete email configuration requires:

• MX records pointing to your mail server(s) with appropriate priorities.
• An SPF TXT record (v=spf1 include:yourprovider.com -all).
• A DKIM TXT record for email signature verification.
• A DMARC TXT record at _dmarc.example.com for authentication policy.
• A PTR record on your mail server's IP for reverse DNS (managed by your hosting provider).

CDN / Cloud Hosting Setup

When using a CDN or cloud platform:

• A CNAME record for subdomains (e.g., www) pointing to the CDN's hostname.
• An ALIAS/ANAME record (or Cloudflare's proxied A record) for the root domain if the provider doesn't give you an IP address.
• A CAA record authorizing the CA that your CDN uses for SSL certificates.

Frequently Asked Questions

What is a DNS record?

A DNS record is an entry in the Domain Name System that maps a domain name to specific information — such as an IP address (A/AAAA records), a mail server (MX records), or a text value (TXT records). DNS records are stored on authoritative name servers and queried by resolvers when clients need to find a service.

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

An A record maps a domain directly to an IPv4 address (e.g., example.com → 93.184.216.34). A CNAME maps a domain to another domain name as an alias (e.g., www.example.com → example.com). A records point to IPs; CNAMEs point to other names. CNAMEs cannot coexist with other record types and cannot be used at the zone apex.

What is an MX record and how does email delivery use it?

An MX record specifies the mail servers responsible for accepting email for a domain, along with a priority value. When sending email to user@example.com, the sending server queries MX records, sorts by priority (lower = higher priority), and attempts delivery to the highest-priority server first, falling back to others if needed.

What are SPF, DKIM, and DMARC records?

SPF lists authorized mail servers in a TXT record. DKIM publishes a public key in a TXT record for email signature verification. DMARC tells receivers what to do when SPF/DKIM checks fail (none, quarantine, or reject). Together, they protect your domain from email spoofing and improve deliverability.

How long does DNS propagation take?

DNS propagation typically takes a few minutes to 48 hours, depending on the TTL of the old records. Lower your TTL to 300 seconds at least 24–48 hours before making changes to ensure fast propagation.

What is a TTL in DNS and what value should I use?

TTL (Time to Live) is how long resolvers cache a record before refreshing. Use 300 seconds for records that change often, 3600 seconds as a general default, and 86400 seconds for stable records that rarely change.

How do I look up DNS records for a domain?

On Linux/macOS, use dig example.com A (or MX, TXT, etc.). On Windows, use nslookup -type=A example.com. You can also use our DNS Lookup tool to query any record type from your browser.

What is a CAA record and why should I use one?

A CAA record specifies which Certificate Authorities may issue SSL/TLS certificates for your domain. For example, 0 issue "letsencrypt.org" allows only Let's Encrypt. CAA records prevent unauthorized certificate issuance and are checked by all major CAs before issuing. Adding them is a simple, high-value security improvement.