DNS record types explained: A, CNAME, MX, TXT, NS, SOA, SRV

A complete reference for DNS record types. What each one does, when to use it, and real-world examples for A, AAAA, CNAME, MX, TXT, NS, SOA, SRV, and CAA.

A DNS record is an instruction that tells DNS resolvers how to handle queries for your domain. There are around a dozen standard types, but six cover 95% of everyday use cases: A, AAAA, CNAME, MX, TXT, and NS. The others (SOA, SRV, CAA, PTR) have specific, narrower applications. Records are configured either in your registrar's DNS interface or at a dedicated DNS provider like Cloudflare, AWS Route 53, or OVH.

Quick reference table

Type	What it does	Typical use	Configured where
A	Maps domain to IPv4 address	Your web server's IP	DNS provider
AAAA	Maps domain to IPv6 address	IPv6-capable servers	DNS provider
CNAME	Aliases one domain name to another	www subdomain, SaaS subdomains	DNS provider
MX	Routes email for the domain	Google Workspace, Microsoft 365	DNS provider
TXT	Stores text data	SPF, DKIM, DMARC, domain verification	DNS provider
NS	Lists authoritative nameservers	Delegates DNS authority	Registrar
SOA	Zone metadata and serial number	DNS zone management	Auto (DNS provider)
SRV	Locates a specific service	VoIP, Microsoft Teams, gaming	DNS provider
CAA	Restricts certificate issuance	SSL/TLS security	DNS provider

Record A: IPv4 address

A records are the most fundamental DNS record type. They map a domain name to an IPv4 address, which is how a browser translates example.com into a server it can connect to.

example.com.    3600    IN    A    93.184.216.34

In Cloudflare's interface: Name = @, Type = A, Content = 93.184.216.34, TTL = Auto.

A domain can have multiple A records, this enables round-robin load balancing, where DNS resolvers cycle through the IP addresses for each request. If your server's IP changes, updating the A record is all you need. You typically have one A record for example.com and one for www.example.com (or a CNAME pointing www to @).

Record AAAA: IPv6 address

Identical to the A record but for IPv6 addresses. IPv6 adoption is significant, approximately 40% of global internet traffic as of 2024 uses IPv6. If your hosting provider gives you an IPv6 address, adding a AAAA record is worth doing.

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

Not mandatory, but if your provider supports IPv6 (Cloudflare, AWS, GCP all do), configuring the AAAA record in parallel with the A record improves connectivity for IPv6-only or IPv6-preferring users with no downside.

Record CNAME: domain alias

A CNAME makes one domain name an alias for another. It does not point to an IP address, it points to another domain name, and the resolver then looks up that domain's A record to find the actual IP.

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

Two important rules to know. First, a CNAME cannot be used at the domain apex (example.com itself) in standard DNS (you can only CNAME subdomains. Cloudflare solves this with "CNAME flattening", which makes an apex CNAME work transparently. Second, a CNAME cannot coexist with other record types for the same name) you cannot have a CNAME and an MX at www.example.com simultaneously.

Practical uses: www pointing to the root domain, blog.example.com pointing to example.ghost.io, shop.example.com pointing to example.myshopify.com. CNAME is useful when the target's IP address changes, you only update one record at the source, and all CNAMEs pointing to it automatically follow.

Record MX: email routing

MX records tell other mail servers where to send email addressed to your domain. Without valid MX records, any email sent to you@example.com will bounce.

example.com.    3600    IN    MX    10    aspmx.l.google.com.

The number (10 here) is the priority. Lower priority numbers mean higher preference. You can have multiple MX records with different priorities for backup mail servers, if the primary (lowest priority number) is unreachable, senders try the next one.

Google Workspace MX setup has five records with priorities 1, 5, 5, 10, and 10. Microsoft 365 uses a single MX record pointing to yourdomain-com.mail.protection.outlook.com with priority 0.

The most common mistake with MX records: forgetting to recreate them when changing nameservers. Your email stops working silently, there are no obvious error messages on your end, senders just get bounces.

Record TXT: verification and authentication

TXT records store arbitrary text data. They are the most overloaded record type in DNS, used for a wide range of purposes that have nothing to do with each other functionally.

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

The main uses:

SPF: specifies which mail servers are authorized to send email on behalf of your domain. Prevents spoofing.
DKIM: stores a public key used to cryptographically verify that outgoing emails were sent by you and were not tampered with.
DMARC: defines what to do with emails that fail SPF or DKIM checks (reject, quarantine, or monitor).
Domain ownership verification: Google Search Console, AWS Certificate Manager, Facebook, and many SaaS services ask you to add a TXT record to prove you control the domain. The record contains a unique token they give you.
Site verification: same mechanism for services like HubSpot, Atlassian, and others.

A domain can have multiple TXT records simultaneously, this is expected and normal. Your SPF record, DKIM records (one per sending service), DMARC record, and various verification tokens all coexist as separate TXT records on the same domain.

Record NS: nameservers

NS records identify which nameservers are authoritative for your domain, these are the servers that know where to find all your other DNS records.

example.com.    86400    IN    NS    ns1.cloudflare.com.

You typically have 2 to 4 NS records for redundancy. They are set by your DNS provider and configured at your registrar (not in the DNS zone itself, though they are visible there). The TTL on NS records is intentionally high (86400 = 24 hours) because these records rarely change.

You almost never edit NS records directly in your DNS manager, you change them at the registrar level when migrating to a new DNS provider. For how to do that, see how to change nameservers.

Record SOA: Start of Authority

Every DNS zone has exactly one SOA record. It contains administrative metadata about the zone: the primary nameserver, the contact email for the domain administrator, a serial number (incremented after each change), and timing parameters for zone synchronization between primary and secondary nameservers.

example.com.    3600    IN    SOA    ns1.example.com. admin.example.com. 2024010101 7200 3600 1209600 300

The fields after the SOA record name are: primary NS, admin email (dots replace @), serial number, refresh interval, retry interval, expire time, and minimum TTL.

You almost never configure this manually, your DNS provider manages it automatically. You would look at it when diagnosing complex DNS issues or verifying that a zone change was properly applied (check the serial number increment).

Record SRV: service locator

SRV records identify where a specific service runs on your domain, they combine protocol, port, and host information.

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

The format: _service._protocol.domain TTL IN SRV priority weight port target. The priority and weight are load balancing controls.

Real-world uses: Microsoft Teams requires SRV records for service discovery in hybrid deployments, Minecraft server hosting uses SRV records so players connect to play.example.com instead of a raw IP:port, and VoIP providers using SIP require SRV records for call routing.

You configure an SRV record only when a specific service provider asks for it, they give you the exact values.

Record CAA: Certification Authority Authorization

CAA records specify which certificate authorities are allowed to issue SSL/TLS certificates for your domain. Any CA not listed is blocked from issuing.

example.com.    3600    IN    CAA    0    issue    "letsencrypt.org"

If you use only Let's Encrypt, a CAA record with letsencrypt.org blocks DigiCert, Sectigo, and every other CA from issuing certificates for your domain, even if they are somehow socially engineered or breached. Adding a CAA record is a straightforward security improvement for any domain in production.

The tag issue allows issuance of regular certificates. issuewild allows wildcard certificates. iodef specifies where to send violation reports (an email address or URL).

Verifying your own records

To retrieve all DNS records for your domain in one command:

dig ANY example.com

Note: some resolvers restrict responses to ANY queries. More reliable is querying specific types:

dig A example.com
dig MX example.com
dig TXT example.com

Domain Sentinel provides a DNS lookup tool that queries multiple record types simultaneously and displays them in a readable format, useful when you want to verify your configuration without working through command-line output. Check your domain's records at any time to confirm changes took effect.