DNS Records Explained: A, AAAA, MX, CNAME, TXT, NS

Last updated: May 31, 2026

Every time you type a domain name into your browser, a complex chain of lookups happens behind the scenes. It translates that human-readable name into a machine-readable IP address. The system responsible for this translation is the Domain Name System (DNS). The instructions that make it work are called DNS records.

Think of DNS as the phonebook of the internet. A phonebook maps a person’s name to their phone number. DNS maps domain names like example.com to IP addresses like 93.184.216.34. But DNS does far more than simple name-to-address translation. Different DNS record types handle email routing, domain aliases, security verification, and nameserver delegation.

DNS records matter to many roles: web developers deploying sites, sysadmins migrating email, and owners verifying domains. Understanding how they work is essential. Misconfigured DNS records cause many common problems. These include website downtime, email delivery failures, and failed SSL certificate issuance. This guide breaks down every major DNS record type with real-world examples you can reference when managing your own domains.

How DNS Works (Brief Overview)

A DNS lookup walks a short chain. A recursive resolver queries a root nameserver, then the TLD nameserver, then the authoritative nameserver that holds the records. The whole chain usually finishes in under 100 milliseconds. The result is cached at every level.

Before diving into individual record types, it helps to understand how DNS works at a high level. For a more detailed walkthrough of the full resolution chain, see our guide on how DNS works. When you enter www.example.com in your browser, the following DNS lookup process occurs:

1. Recursive Resolver — Your device sends the query to a DNS resolver. Examples are your ISP or Google Public DNS (8.8.8.8). The resolver does the heavy lifting.
2. Root Nameserver — If the resolver has no cached answer, it contacts one of the 13 root nameserver clusters. The root server knows which servers are authoritative for .com.
3. TLD Nameserver — The resolver then queries the Top-Level Domain (TLD) nameserver for .com. It responds with the authoritative nameservers for example.com.
4. Authoritative Nameserver — Finally, the resolver queries the authoritative nameserver for example.com, which holds the actual DNS records. It returns the requested record, and the resolver passes the answer back to your browser.

This entire process typically completes in under 100 milliseconds. The result is cached at multiple levels to speed up later lookups. The DNS records stored on that authoritative nameserver are what we’ll explore in detail below.

Common DNS Record Types

Most domain owners work with only six or seven record types regularly. The core set is A, AAAA, CNAME, MX, TXT, and NS. A handful of others fill in the gaps: SOA, SRV, CAA, PTR, and the newer HTTPS records. Each section below explains what the record does.

There are dozens of DNS record types defined in various RFCs. But most domain owners work with only six or seven regularly. Here’s what each one does and when you’ll encounter it.

A Record (Address Record)

The A record is the most fundamental DNS record type. It maps a domain name directly to an IPv4 address. That is how browsers know where to send HTTP requests for your website. Nearly every domain on the internet has at least one A record.

example.com.    300    IN    A    93.184.216.34

When you set up web hosting, your provider typically asks you to create an A record first. It points your domain to their server’s IP address. You can also create A records for subdomains. For example, pointing blog.example.com to a different server than your main site.

You can have multiple A records for the same domain name, each pointing to a different IP address. This is called round-robin DNS and is a basic form of load balancing where resolvers rotate through the available addresses.

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 instead of a 32-bit IPv4 address. The name “AAAA” reflects the fact that an IPv6 address is four times the length of an IPv4 address.

example.com.    300    IN    AAAA    2606:2800:0220:0001:0248:1893:25c8:1946

AAAA records exist because IPv4 address space is exhausted. IPv4 provides roughly 4.3 billion unique addresses. That seemed like plenty in the 1980s, but it ran out as billions of devices came online. IPv6 provides approximately 340 undecillion addresses, enough for the foreseeable future. Our guide on IPv4 vs. IPv6 explains the technical differences in detail. If your hosting provider supports IPv6, create both A and AAAA records so your site is reachable over either protocol.

CNAME Record (Canonical Name Record)

A CNAME record creates an alias that points one domain name to another domain name, not to an IP address. When a resolver encounters a CNAME, it follows the chain. It performs an additional lookup on the target domain to get the final IP address.

www.example.com.    3600    IN    CNAME    example.com.

The most common use of a CNAME record is pointing the www subdomain to the apex (bare) domain. CNAME records are also widely used when connecting to third-party services. For example, pointing shop.example.com to shops.myshopify.com or docs.example.com to a GitHub Pages URL.

There is one critical rule for CNAME records. A CNAME cannot coexist with any other record type at the same name. This means you cannot place a CNAME at your apex domain (example.com). The apex already needs NS and usually SOA records. This is a common source of confusion. It is the reason many DNS providers offer proprietary ALIAS or ANAME records that behave like CNAMEs at the apex. The difference between a DNS A record vs CNAME is fundamental. A records point to IP addresses directly, while CNAMEs point to other domain names.

MX Record (Mail Exchanger Record)

The MX record tells the internet where to deliver email for your domain. When someone emails user@example.com, the sending server looks up MX records on example.com. That lookup finds which mail server should receive the message. If you’ve ever wondered what is an MX record, it’s the DNS record that makes email work.

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.

Priority values are what make MX records unique among DNS record types. They let you define primary and backup mail servers. In the example above, aspmx.l.google.com (priority 1) is the preferred server. If it’s down, the sending server tries the alternates in order. Two servers with the same priority (like the two priority-5 servers above) receive mail in a round-robin fashion.

Getting MX records wrong is one of the fastest ways to break email delivery for your entire domain. If you’re migrating between email providers, always verify your records after making changes. You can run a focused MX record lookup to confirm the mail servers and priorities resolve correctly.

TXT Record (Text Record)

TXT records store arbitrary text data associated with a domain name. Originally designed for human-readable notes, TXT records have evolved. They are now among the most important DNS record types for security and verification. If you’re asking what is a TXT record used for, the answer is short. It is almost always email authentication or domain verification.

;; SPF record - authorizes mail servers to send for your domain
example.com.    3600    IN    TXT    "v=spf1 include:_spf.google.com ~all"

;; DMARC record - email authentication policy
_dmarc.example.com.    3600    IN    TXT    "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

;; Google domain verification
example.com.    3600    IN    TXT    "google-site-verification=abc123def456..."

The three most common uses for TXT records are:

• SPF (Sender Policy Framework) — Specifies which mail servers are authorized to send email for your domain. Without an SPF record, your emails are far more likely to land in spam folders.
• DKIM (DomainKeys Identified Mail) — Uses cryptographic signatures to verify that email content hasn’t been tampered with in transit. DKIM keys are published as TXT records at specific subdomains.
• DMARC (Domain-based Message Authentication) — Builds on SPF and DKIM. It tells receiving servers what to do when authentication fails (reject, quarantine, or do nothing) and where to send reports.

Services like Google Search Console, Microsoft 365, and various CDN providers also use TXT records. They verify that you own a domain. They give you a unique string to add as a TXT record, then check for its presence to confirm ownership. To read the raw TXT values on any domain, run a TXT record lookup.

NS Record (Nameserver Record)

NS records specify which nameservers are authoritative for a domain or subdomain. They are the foundation of how DNS delegation works. When you register a domain, you point it to a hosting provider’s nameservers. That sets NS records at the registrar level.

example.com.    86400    IN    NS    ns1.examplehost.com.
example.com.    86400    IN    NS    ns2.examplehost.com.
example.com.    86400    IN    NS    ns3.examplehost.com.

There are two places where NS records matter. First, at the registrar level. These are the nameserver settings you configure when you buy a domain, such as setting Cloudflare’s nameservers. Second, within your DNS zone file, where the NS records should match what the registrar has. Zone-level NS records can also delegate subdomains to different nameservers entirely. For example, you might delegate api.example.com to a different DNS provider than your main domain. To see the registrar of record, expiration date, and current nameservers, run a WHOIS lookup.

HTTPS and SVCB Records (the Modern Additions)

The newest record types most guides still skip are SVCB (Service Binding) and HTTPS. Both were standardized in RFC 9460 in November 2023. The HTTPS record is the web-specific form of the general SVCB record. It solves several long-standing DNS limitations at once.

example.com.    300    IN    HTTPS    1 . alpn="h3,h2" ech=AED...

An HTTPS record does three things older records could not:

• Bootstraps HTTP/3 from DNS. The record advertises supported protocols (the alpn list), so a browser learns the site supports HTTP/3 before it connects. It can open a QUIC connection on the first request. That avoids starting on HTTP/2 and upgrading through an Alt-Svc round trip.
• Works at the zone apex. Unlike a CNAME, an HTTPS record can sit at the apex domain. It can point traffic to a CDN or alternate endpoint. This is the standardized fix for the apex-CNAME limitation described above.
• Carries Encrypted Client Hello. The ech parameter publishes the key for Encrypted Client Hello, which hides the server name during the TLS handshake. RFC 9848 (2026) makes SVCB the primary way to bootstrap ECH.

Other DNS Record Types Worth Knowing

Beyond the core record types above, there are several others you may encounter:

• SOA (Start of Authority) — Every DNS zone has exactly one SOA record. It holds metadata about the zone, including the primary nameserver, the administrator’s email, the zone serial number, and refresh intervals. You rarely edit this directly.
• SRV (Service Record) — Specifies the host and port for specific services. Commonly used by Microsoft Active Directory, SIP/VoIP services, and some game servers. SRV records include priority and weight values for load balancing.
• CAA (Certification Authority Authorization) — Specifies which certificate authorities may issue SSL/TLS certificates for your domain. Adding CAA records is a security best practice that blocks unauthorized CAs. To see what certificates have actually been issued for a domain, use our SSL certificate checker.
• PTR (Pointer Record) — The reverse of an A record. Instead of mapping a domain to an IP, a PTR record maps an IP address back to a domain name. PTR records power reverse DNS lookups and are checked by mail servers to verify sender legitimacy. Our article on what is reverse DNS covers PTR records and email deliverability in depth.

How to Check DNS Records

Checking DNS records is a practical skill during site migrations, email troubleshooting, and SSL setup. There are two approaches. Command-line tools like nslookup and dig work well, as do web-based lookup tools that query many record types at once. Both read the same authoritative data.

Knowing how to check DNS records is a practical skill. It comes up regularly during site migrations, email troubleshooting, and SSL certificate setup. There are two main approaches: command-line tools and web-based tools.

Command-Line Tools

The two most common command-line tools for DNS lookups are nslookup and dig. The nslookup tool runs on Windows, macOS, and Linux. The dig tool runs on macOS and Linux, and installs on Windows.

# Look up A records
nslookup example.com

# Look up MX records
nslookup -type=mx example.com

# Look up TXT records
nslookup -type=txt example.com

# Query a specific DNS server
nslookup example.com 8.8.8.8

# Look up A records
dig example.com A

# Look up all record types
dig example.com ANY

# Look up MX records with short output
dig example.com MX +short

# Look up the new HTTPS record
dig example.com HTTPS

Online DNS Lookup Tools

If you prefer a visual interface, online tools are the way to go. They also let you check DNS records from a different geographic location. You can check DNS records for any domain using our DNS lookup tool. It queries multiple record types at once and shows results in a clean, readable format.

When to Check DNS Records

There are several common scenarios where checking DNS records is essential:

• Website migration — After changing hosting providers, verify that A and CNAME records point to the new server. Do this before assuming the migration is complete.
• Email troubleshooting — If emails are bouncing or landing in spam, check two things. Look at MX records for mail server configuration and TXT records for SPF, DKIM, and DMARC. DNS issues are a common cause of network problems. See our network connectivity troubleshooting guide for a step-by-step approach.
• SSL certificate issuance — Many SSL providers (especially Let’s Encrypt with DNS-01 challenges) require specific TXT records for domain validation. Verifying these records are in place saves time and failed attempts.
• Nameserver changes — After updating NS records at your registrar, check propagation. This ensures the new nameservers respond correctly before you make further changes.

DNS Propagation and TTL

DNS propagation is how updated records spread across the global network of resolvers. It is not instant. Every record carries a TTL (Time to Live) that tells resolvers how long to cache it. Lowering the TTL to 300 seconds a day before a change makes new records take effect faster.

DNS propagation is the process by which updated DNS records spread across the global network of recursive resolvers. When you change a DNS record, that change doesn’t take effect everywhere at once. Understanding why requires knowing how TTL works.

TTL (Time to Live) is a value set on every DNS record. It tells resolvers how long, in seconds, to cache the record. After that, they request a fresh copy from the authoritative nameserver. A TTL of 3600 means resolvers serve the cached version for one hour before checking for updates.

300     = 5 minutes   (good for records that change frequently)
3600    = 1 hour      (standard default for most records)
14400   = 4 hours     (common for stable records)
86400   = 24 hours    (typical for NS records and stable configs)

When you update a DNS record, resolvers that cached the old one keep serving it. They continue until their copy expires based on the TTL. This is why DNS changes aren’t instant. In practice, most DNS changes propagate within 15 minutes to 4 hours. The commonly cited “up to 48 hours” is a worst case. It applies to resolvers that don’t strictly honor TTL values or keep very long cache durations.

Pro tip: if you know a change is coming, lower the TTL ahead of time. Drop it to 300 seconds (5 minutes) at least 24 hours beforehand. By the time you make the switch, most resolvers have the short TTL cached. Your new records then propagate much faster. After the change is confirmed, raise the TTL back to a longer duration. To watch a change roll out across resolvers in different regions, use our DNS propagation checker.

Common DNS Mistakes to Avoid

Even experienced administrators make DNS errors. The most common are placing a CNAME at the apex and setting wrong MX priorities. Others include missing SPF, DKIM, or DMARC records and leaving a high TTL before a migration. Forgetting trailing dots in zone files and not verifying changes also make the list.

Even experienced administrators make DNS configuration errors. Here are the most common mistakes and how to avoid them:

• Using a CNAME at the apex domain — Placing a CNAME at the zone apex violates the DNS specification. It conflicts with the required SOA and NS records. If you need CNAME-like behavior at the apex, you have options. Use a provider that offers ALIAS or ANAME records, an A record, or an HTTPS record.
• Incorrect MX priority values — This means using the wrong priorities. One example is giving all MX records the same value when your provider expects a hierarchy. It can also mean giving a backup server the lowest number. Always follow your email provider’s recommended MX configuration exactly.
• Missing SPF, DKIM, or DMARC records — Without proper email authentication records, your domain is vulnerable to spoofing. Your legitimate emails are also more likely flagged as spam. Every domain that sends email should have an SPF TXT record. Domains that do not send email should publish "v=spf1 -all" to prevent spoofing. Use our SPF, DKIM & DMARC checker to verify all three records in one click.
• High TTL before a migration — Suppose your records have a 24-hour TTL and you move to a new server. Some users keep reaching the old server for up to a day. Always lower TTL values well in advance of planned changes.
• Forgetting trailing dots in zone files — In raw zone file syntax, fully qualified domain names end with a dot. Omitting it can make the server append the zone name, producing records like example.com.example.com. Most managed dashboards handle this, but it’s common when editing zone files directly.
• Not verifying after changes — Always confirm your DNS changes work using a DNS lookup tool or command-line tools. Don’t assume the change worked just because you saved it in the dashboard.

Frequently Asked Questions

Seven common questions about DNS records. They cover the A-versus-CNAME distinction, how long changes take to propagate, and what MX and TXT records do. They also cover the new HTTPS record and whether you can have multiple A records. Finally, they explain how to check a domain’s records.