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

What are DNS records?

DNS (Domain Name System) is often described as the phone book of the internet. When someone types a domain name into their browser, DNS translates that human-readable name into a machine-readable IP address. But DNS does far more than simple address lookups. It tells the world where your email should be delivered, which certificate authorities are allowed to issue certificates for your domain, and how your email authentication policies should be enforced.

Each piece of information published in DNS is stored as a record. Different record types serve different purposes. Some point to IP addresses, others delegate authority to nameservers, and others carry free-text data used for verification and security policies. You can inspect any domain's records using our free DNS Lookup tool.

Quick reference table

The table below summarises the most common DNS record types. Each is covered in detail further down the page.

A and AAAA records

The A record is the most fundamental DNS record type. It maps a domain name to an IPv4 address, which is the 32-bit numeric address that servers use to communicate over the internet. When a visitor types your domain into a browser, the resolver queries for an A record to find the server's IP.

example.com.    300    IN    A    93.184.216.34

The AAAA record (pronounced “quad-A”) serves the same purpose but for IPv6 addresses. IPv6 uses 128-bit addresses, providing a vastly larger address space than IPv4. As IPv6 adoption continues to grow, publishing AAAA records alongside A records ensures your domain is reachable on both protocols.

example.com.    300    IN    AAAA    2606:2800:220:1:248:1893:25c8:1946

A domain can have multiple A records (and multiple AAAA records), which enables round-robin load balancing across several servers. The TTL (time to live) value, shown as 300 seconds in the examples above, controls how long resolvers cache the answer before querying again.

CNAME records

A CNAME record (canonical name) creates an alias from one domain name to another. Instead of returning an IP address directly, it tells the resolver to look up the target name instead. This is commonly used to point subdomains to a hosting provider or CDN.

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

There are important restrictions to be aware of. A CNAME record cannot coexist with any other record type at the same name. This means you cannot place a CNAME at the zone apex (the bare domain, e.g. example.com) because the apex always has NS and SOA records. Some DNS providers work around this limitation with proprietary “ALIAS” or “ANAME” record types that flatten the CNAME at query time, but these are not part of the official DNS standard.

Use a CNAME when you want a subdomain to track another hostname's IP address automatically. Use an A record when you need direct control over the IP or when the name sits at the zone apex.

MX records

MX records (mail exchange) tell the world which servers accept email for your domain. When someone sends an email to user@example.com, the sending server queries the MX records for example.com to find out where to deliver the message.

example.com.    3600    IN    MX    10    mail1.example.com.
example.com.    3600    IN    MX    20    mail2.example.com.

Each MX record includes a priority value (the number before the hostname). Lower numbers indicate higher priority. In the example above, mail servers will try mail1.example.com first (priority 10). If that server is unavailable, they fall back to mail2.example.com (priority 20). Publishing multiple MX records with different priorities provides redundancy and ensures email delivery even during server outages.

An MX record must point to a hostname, not an IP address. That hostname must then have its own A or AAAA record. MX records also must not point to a CNAME.

TXT records

TXT records hold free-form text data associated with a domain. Originally intended for human-readable notes, they are now used extensively for machine-readable purposes: email authentication (SPF, DMARC, DKIM), domain ownership verification (Google Search Console, Microsoft 365), and security policies.

example.com.    3600    IN    TXT    "v=spf1 include:_spf.google.com ~all"

A single domain can have multiple TXT records. This is common in practice; you might have one TXT record for SPF, another for domain verification, and yet another for a site verification token. However, you should only ever have one SPF TXT record per domain. Multiple SPF records will cause authentication failures. If your SPF record is getting complex, our SPF Flattener can help you consolidate lookups, and the same page explains how to fix the SPF “too many DNS lookups” error.

Email authentication records

Several critical email security protocols are implemented as TXT records published at specific subdomains. These records are the backbone of modern email authentication. For more on how they work together, read our guide on what DMARC is and how it protects your domain.

• SPF is published as a TXT record at the domain apex. It lists every IP address and service authorised to send email on your behalf.

  example.com.    TXT    "v=spf1 include:_spf.google.com ip4:203.0.113.5 ~all"

• DMARC is published as a TXT record at _dmarc.example.com. It defines the policy receivers should apply to mail that fails DMARC (neither SPF nor DKIM passes in alignment with the From domain), and where to send aggregate reports. Check any domain's DMARC setup with our DMARC Checker.

  _dmarc.example.com.    TXT    "v=DMARC1; p=reject; rua=mailto:dmarc@example.com;"

• DKIM public keys are published as TXT records at selector._domainkey.example.com, where “selector” is a label chosen by your email provider (e.g. google._domainkey for Google Workspace).

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

• MTA-STS is published as a TXT record at _mta-sts.example.com. It signals that your domain supports MTA-STS, a mechanism that enforces TLS encryption for inbound email. You can verify this with our MTA-STS Checker.

  _mta-sts.example.com.    TXT    "v=STSv1; id=20260301;"

NS records

NS records (nameserver) delegate authority for a DNS zone to specific nameservers. Every domain has at least two NS records, and they tell the rest of the internet which servers hold the authoritative DNS data for that zone.

example.com.    86400    IN    NS    ns1.example.net.
example.com.    86400    IN    NS    ns2.example.net.

NS records are set at your domain registrar and typically have long TTL values (often 86400 seconds, or 24 hours). When you change DNS providers, updating your NS records is the step that redirects all DNS queries to the new provider. This is also where DNSSEC validation begins; the parent zone's DS record points to keys held by the nameservers listed in your NS records. You can verify your DNSSEC configuration with our DNSSEC Checker, and the same page explains what DNSSEC is and why it matters.

SOA records

Every DNS zone has exactly one SOA record (start of authority). It contains administrative metadata about the zone, including the primary nameserver, the responsible party's email address (encoded with a dot instead of an @), and several timing parameters that control how secondary nameservers synchronise with the primary.

example.com.    3600    IN    SOA    ns1.example.com. admin.example.com. (
    2026032301   ; serial number
    7200         ; refresh (2 hours)
    3600         ; retry (1 hour)
    1209600      ; expire (14 days)
    300          ; minimum TTL (5 minutes)
)

The key fields are: serial number, which must be incremented each time the zone is updated; refresh, the interval at which secondary servers check for updates; retry, how long to wait before retrying a failed refresh; expire, after which secondary servers stop serving the zone if they cannot reach the primary; and minimum TTL, which acts as the default negative caching duration (how long resolvers cache a “this record does not exist” answer).

SRV records

SRV records (service) specify the hostname and port for specific services. They are used by protocols such as SIP (voice over IP), XMPP (messaging), LDAP, and Microsoft Active Directory. Unlike MX records, which are limited to email, SRV records can advertise any service.

_sip._tcp.example.com.    3600    IN    SRV    10 5 5060 sip.example.com.

The format is _service._protocol.name, followed by four values: priority (lower is preferred), weight (for load balancing between records with the same priority), port, and target hostname. SRV records allow clients to discover services automatically without hardcoding server addresses or ports.

CAA records

CAA records (Certification Authority Authorization) specify which certificate authorities (CAs) are permitted to issue SSL/TLS certificates for your domain. Before issuing a certificate, CAs are required to check the domain's CAA records. If your domain lists only specific CAs, any other CA must refuse the request.

example.com.    3600    IN    CAA    0 issue "letsencrypt.org"
example.com.    3600    IN    CAA    0 issuewild "letsencrypt.org"
example.com.    3600    IN    CAA    0 iodef "mailto:security@example.com"

The issue tag controls standard certificate issuance. issuewild controls wildcard certificate issuance. The iodef tag specifies where CAs should send violation reports. CAA records take minutes to publish, and once they name the CAs you use, any other publicly trusted CA must refuse to issue for your domain. You can check your domain's CAA configuration with our CAA Checker. For a detailed walkthrough, see our guide on CAA records explained.

PTR records

PTR records (pointer) are the reverse of A records. While an A record maps a domain name to an IP address, a PTR record maps an IP address back to a domain name. They are published in the special in-addr.arpa zone (for IPv4) or ip6.arpa zone (for IPv6) and are managed by the IP address owner, which is typically your hosting provider or ISP.

34.216.184.93.in-addr.arpa.    3600    IN    PTR    mail.example.com.

PTR records are particularly important for email deliverability. Many receiving mail servers perform a reverse DNS lookup on the connecting IP. If the PTR record does not resolve, or if it does not match the sending domain's forward DNS, the server may reject the message or flag it as spam. If you run your own mail server, ensuring your PTR record is correctly configured is essential.

How to query DNS records

There are several ways to look up DNS records for any domain. On the command line, the most common tools are dig and nslookup.

# Query A records
dig example.com A

# Query MX records
dig example.com MX

# Query all TXT records
dig example.com TXT

# Query a specific DMARC record
dig _dmarc.example.com TXT

# Query CAA records
dig example.com CAA

If you prefer a browser-based approach, our DNS Lookup tool looks up A, AAAA, MX, TXT, NS, SOA, SRV and CNAME records without needing access to a terminal, including names with an underscore, such as _sip._tcp.example.com, where SRV records are published. It has no CAA or PTR lookup.

To check email authentication, DNSSEC, CAA and the certificate in one scan, try our Security Grade Check. It grades your domain A+ to F from 16 outside-in checks.

Next steps

Now that you understand the major DNS record types, here are some recommended next steps:

• Look up your domain's DNS records to see exactly what is published today.
• Check your DMARC record to confirm your email authentication policy is in place.
• Read our guide on what DMARC is if you are new to email authentication.
• Learn about fixing the SPF “too many DNS lookups” error if your TXT records are getting complex.
• Verify your DNSSEC chain of trust with our DNSSEC Checker.
• Explore ShieldMarc plans for ongoing DMARC monitoring, DNS health checks, and the Security Grade.

Frequently asked questions