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

DNS record types tell resolvers what kind of information a name holds: A and AAAA records point to IP addresses, CNAME creates aliases, MX routes email, TXT carries verification and security policies, and NS and SOA describe the zone itself. Knowing which record does what is the key to configuring a domain correctly.

Every domain's DNS lives in a zone, a set of records hosted on its authoritative name servers. Each record has a name, a TTL (how long it may be cached), a class (almost always IN for internet) and a type, followed by type-specific data. If you are new to how lookups work, start with What is DNS and how does it work? and then come back here.

In the examples below, @ is zone-file shorthand for the domain itself (the "apex" or "root" of the zone), here example.com.

Summary of common record types

A and AAAA records

The A record is the most fundamental type: it maps a name to a 32-bit IPv4 address. The AAAA record ("quad-A") does the same for 128-bit IPv6 addresses. A name can have several of each; resolvers return all of them and clients pick one, which gives simple load distribution and redundancy.

@      3600  IN  A     192.0.2.10
@      3600  IN  AAAA  2001:db8::10
www    3600  IN  A     192.0.2.10
www    3600  IN  AAAA  2001:db8::10

If your server has IPv6 connectivity, publish an AAAA record alongside the A record so IPv6-capable visitors can reach it natively.

CNAME records

A CNAME (canonical name) says "this name is an alias; go look up that other name instead". It is commonly used to point subdomains at hosted services, such as a CDN or a website builder, whose IP addresses may change without notice.

shop   3600  IN  CNAME  stores.example.net.

CNAMEs come with strict rules. A name that has a CNAME cannot have any other record of any type. Because the zone apex must always have SOA and NS records, you cannot place a CNAME at the apex (example.com itself), only on subdomains like www. Also, MX and NS records should point to names that have A or AAAA records, not to CNAMEs.

ALIAS, ANAME and CNAME flattening

To work around the apex restriction, many DNS providers offer a proprietary record, called ALIAS, ANAME or "CNAME flattening" depending on the provider. You configure it like a CNAME, but the provider's servers resolve the target themselves and answer with ordinary A and AAAA records. To the outside world, it looks like a normal A record. This is not a standard record type, so it only works if your DNS host supports it.

MX records

MX (mail exchanger) records tell other mail servers where to deliver email for your domain. Each has a preference number; lower values are tried first, and equal values share the load.

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

Here, senders try mail1 first and fall back to mail2 if it is unreachable. You can check any domain's mail routing with our MX lookup tool.

NS records

NS records list the authoritative name servers for a zone. They appear in two places: in your own zone, and as a delegation in the parent (TLD) zone, which is set through your registrar. The two sets should match. Use at least two name servers, ideally on separate networks, so your domain survives the loss of one.

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

NS records can also delegate a subdomain to different servers, for example handing dev.example.com to a separate DNS provider.

TXT records

TXT records hold arbitrary text, and over time they have become the place for machine-readable policies and ownership proofs:

• SPF lists the servers allowed to send mail for the domain.
• DKIM public keys live at selector._domainkey.example.com.
• DMARC policies live at _dmarc.example.com.
• Domain verification tokens prove control to services like search consoles and email providers.

@        3600  IN  TXT  "v=spf1 include:_spf.example.net -all"
_dmarc   3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

A single TXT string is limited to 255 characters, so long values such as DKIM keys are split into several quoted strings that are joined together. See SPF, DKIM and DMARC explained for how these records work together.

SOA record

Every zone has exactly one SOA (start of authority) record at its apex. It describes the zone rather than any service:

@  IN  SOA  ns1.example.net. hostmaster.example.com. (
        2026101301 ; serial
        7200       ; refresh
        3600       ; retry
        1209600    ; expire
        3600 )     ; minimum (negative caching TTL)

• MNAME (ns1.example.net.): the primary name server.
• RNAME (hostmaster.example.com.): the administrator's email address, with the first dot standing for @.
• Serial: a version number that must increase with each change so secondary servers know to update. A date-based format like YYYYMMDDnn is a common convention.
• Refresh and retry: how often secondaries check for updates, and how soon they retry after a failure.
• Expire: how long a secondary keeps serving the zone if it cannot reach the primary.
• Minimum: today used as the TTL for caching negative ("does not exist") answers.

CAA records

CAA (certification authority authorization) records state which certificate authorities may issue TLS certificates for your domain. Publicly trusted CAs are required to check them before issuing, so a CAA record limits the damage if someone tries to obtain a certificate for your domain from another CA.

@  3600  IN  CAA  0 issue "ca.example.net"
@  3600  IN  CAA  0 issuewild ";"
@  3600  IN  CAA  0 iodef "mailto:security@example.com"

This allows only the CA identified as ca.example.net to issue regular certificates (each CA documents the exact value to use), forbids wildcard certificates from any CA, and asks CAs to report violations. If no CAA record exists, any CA may issue.

SRV records

SRV records advertise the host and port for a particular service, which A records cannot do. The name follows the pattern _service._protocol.domain, and the data contains priority, weight, port and target:

_sip._tcp   3600  IN  SRV  10 60 5060 sip1.example.com.
_sip._tcp   3600  IN  SRV  10 40 5060 sip2.example.com.

Both targets share priority 10, so clients split traffic roughly 60/40 by weight. SRV is used by SIP, XMPP, LDAP, Microsoft Active Directory, and some games such as Minecraft Java Edition.

PTR records

PTR records power reverse DNS: they map an IP address back to a hostname. They live in special zones (in-addr.arpa for IPv4 and ip6.arpa for IPv6) controlled by whoever owns the IP block, usually your hosting provider or ISP rather than your domain's DNS host.

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

Mail servers rely on them heavily. Read What is reverse DNS? for details.

HTTPS, SVCB and DNSSEC records

SVCB and its web-specific variant HTTPS (standardized in RFC 9460) let a domain advertise connection details up front, such as support for HTTP/3 or alternative endpoints, saving a round trip. Unlike CNAME, an HTTPS record can be placed at the zone apex.

DNSSEC adds its own record types. DNSKEY holds the zone's public signing keys, RRSIG holds signatures over each record set, and a DS record, published in the parent zone through your registrar, links your keys into the chain of trust that starts at the root.

Frequently asked questions

Can a domain have multiple A records?

Yes. Resolvers return every A record for the name, and clients typically try them in turn. This is a basic form of load balancing and redundancy, though it does not detect failed servers on its own.

Should I use a CNAME or an A record for www?

Use a CNAME if www should follow a hosted service whose addresses you do not control, such as a CDN. Use A and AAAA records if you run the server yourself and know its fixed addresses.

Can I have more than one SPF TXT record?

No. A domain must publish only one TXT record starting with v=spf1. Two or more cause SPF checks to return a permanent error. Merge all senders into one record instead.

How long do DNS record changes take?

The change is live on your name servers immediately, but resolvers may keep serving the old value until its TTL expires. Lowering the TTL a day before a planned change keeps the switchover short.