DNS Records Explained: A, CNAME, MX, TXT, and More

Every domain you control has a zone file sitting on a set of authoritative name servers — usually managed through your registrar or a DNS provider's dashboard. A zone file is just a list of records: instructions telling the rest of the internet what to do when someone looks up your domain, a subdomain of it, or asks about email destined for it.

This says: for the name www.example.com, cached for up to 3600 seconds, using the Internet class (always IN in practice), the record type is A, and the value is the IPv4 address 93.184.216.34. The record type is what determines what kind of answer a query gets — and that's what the rest of this guide covers.

TTL: How Long an Answer Sticks Around

The TTL (Time To Live), measured in seconds, tells resolvers how long they're allowed to cache a record before asking again. A low TTL (say, 300 seconds) means changes propagate quickly but your authoritative servers get queried more often. A high TTL (86400 seconds, a full day) reduces query load but means a change you make today might not be visible everywhere until tomorrow.

A common practice before making a change is to lower the TTL well in advance, let the old TTL expire so resolvers pick up the new low value, make the change, then raise the TTL again afterward once things have settled.

Address Records: Pointing a Name at an IP

A Record

The A record (Address record) is the most fundamental DNS record type. It maps a hostname directly to an IPv4 address.

When a browser resolves example.com, this is very often the record it's ultimately after. A domain can have multiple A records for the same name — this is called round-robin DNS, and it's a simple (if crude) way to spread traffic across several servers, since resolvers typically return the addresses in rotating order.

AAAA Record

The AAAA record ("quad-A") is the IPv6 equivalent of an A record. It maps a hostname to a 128-bit IPv6 address.

A dual-stack domain publishes both an A and an AAAA record for the same name. Modern clients prefer IPv6 when both are available and the network path supports it, falling back to IPv4 otherwise. See our guide to IP addressing for more on the difference between the two address families.

CNAME: Aliasing One Name to Another

A CNAME record (Canonical Name) doesn't point to an IP address at all — it points to another hostname. It's an alias: "whatever this other name resolves to, that's my answer too."

This is extremely common for www subdomains and for pointing custom domains at third-party hosted services (a storefront platform, a CDN, a static site host). Rather than hard-coding an IP address that the provider might change at any time, you alias to a name the provider controls and updates on their end as needed.

The CNAME Restriction at the Zone Apex

There's an important rule: a CNAME record cannot coexist with other records at the same name, and a domain's apex (also called the "root" or "naked" domain — example.com with no subdomain) almost always needs other records at that name, most notably the SOA and NS records that make it a valid zone in the first place.

This is why you generally can't set example.com itself as a CNAME, even though you can set www.example.com as one. Providers work around this limitation with proprietary record types that behave like a CNAME but are resolved apex-safe on their own infrastructure — commonly called an ALIAS or ANAME record. These aren't part of the official DNS standard; they're a convenience layer the DNS provider implements by looking up the target and serving the resulting A/AAAA records directly at the apex.

Rule of thumb: use an A/AAAA record when you have a fixed IP address to point at, and a CNAME when you're pointing at a name whose underlying address might change without your involvement.

Mail Routing: MX Records

An MX record (Mail Exchange) tells the world which mail servers accept email on behalf of a domain. When someone sends mail to you@example.com, the sending server looks up the MX records for example.com to find out where to deliver it — not the A record.

The number before the hostname is the priority (lower value = higher priority). Sending servers try the lowest-numbered server first and fall back to higher-numbered ones if it's unreachable. Each MX record points to a hostname, which must in turn resolve via its own A or AAAA record — an MX record can never point directly at an IP address.

If a domain has no MX records at all, mail servers following the standard will typically fall back to the domain's A record as a last resort, but relying on that fallback is considered bad practice — always publish explicit MX records if the domain sends or receives mail.

Text Records: TXT

A TXT record stores arbitrary text against a name. It was originally a generic, catch-all field, but in practice today it's dominated by machine-readable strings used for domain verification and email authentication.

Use case	Example
Domain ownership verification	`google-site-verification=abc123...`
SPF (sender authorization)	`v=spf1 include:_spf.example.com ~all`
DMARC policy	`v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com`
DKIM public key	`v=DKIM1; k=rsa; p=MIGfMA0GCSq...`

SPF — Sender Policy Framework

An SPF record lists which mail servers are allowed to send email as your domain. Receiving mail servers check the SPF TXT record for the sender's domain and reject or flag messages that originate from a server not on the list. This is a major defence against email spoofing.

The ~all at the end is a "soft fail" for anything not matched by the earlier mechanisms; -all is a stricter "hard fail."

DKIM — DomainKeys Identified Mail

DKIM lets a sending server cryptographically sign outgoing mail. The public key needed to verify that signature is published as a TXT record at a special selector subdomain:

The receiving server fetches this record, verifies the signature in the email header against the public key, and confirms the message wasn't altered in transit and genuinely came from a server holding the matching private key.

DMARC — Domain-based Message Authentication, Reporting and Conformance

DMARC ties SPF and DKIM together into a policy: what should a receiving server do if a message fails both checks? Published at a fixed name:

p= sets the policy — none (monitor only), quarantine (send to spam), or reject (refuse delivery outright). The rua address is where aggregate failure reports get sent, which is invaluable for spotting spoofing attempts against your domain.

Name Server Delegation: NS Records

An NS record (Name Server) declares which servers are authoritative for a zone — i.e., which servers hold the real answers for a domain and everything under it.

When you set a domain's name servers at your registrar, you're telling the parent zone (the .com TLD servers, in this case) which servers to refer resolvers to for anything under example.com. This is the mechanism that makes DNS hierarchical and delegated — nobody needs to run the entire internet's DNS themselves; they just need to be authoritative for their own slice and correctly delegate the rest.

NS records can also delegate a specific subdomain to a different set of name servers than the parent domain uses, which is how large organisations split management of different subdomains across different teams or providers.

SOA: The Zone's Metadata Record

Every zone has exactly one SOA record (Start of Authority), which describes administrative facts about the zone itself rather than answering a lookup.

Field	Purpose
Primary name server	The zone's master server
Admin email	Written with a dot instead of @ (`admin.example.com.` = `admin@example.com`)
Serial	Version number; secondary servers compare this to know if a zone transfer is needed
Refresh	How often secondaries check the primary for updates
Retry	How long to wait before retrying a failed refresh
Expire	How long a secondary keeps serving stale data if it can't reach the primary before giving up
Minimum TTL	How long negative answers (NXDOMAIN) may be cached

Reverse Lookups: PTR Records

Every other record type answers "what does this name resolve to?" A PTR record (Pointer) answers the opposite question: "what name belongs to this IP address?"

PTR records live in a special reverse-lookup zone, structured as the IP address written backwards under in-addr.arpa (IPv4) or ip6.arpa (IPv6):

Reverse DNS is controlled by whoever owns the IP address block — usually your hosting provider or ISP, not you — so setting it up often means submitting a request through them rather than editing your own zone. A correctly configured PTR record that matches the sending server's forward A record is a strong signal used by mail servers to filter spam; mismatched or missing PTR records are a common reason legitimate mail gets rejected.

Other Common Record Types

SRV — Service Records

An SRV record specifies the host and port for a specific service, rather than assuming a default port. It's used by protocols like SIP (VoIP), XMPP (chat), and some Microsoft services (Active Directory, Exchange autodiscovery).

The fields are priority, weight (for load-balancing between equal-priority targets), port, and target hostname.

CAA — Certification Authority Authorization

A CAA record restricts which Certificate Authorities are allowed to issue TLS/SSL certificates for a domain. It doesn't affect resolution at all — it's a security control that certificate authorities are required to check before issuing a certificate.

This example says only Let's Encrypt may issue certificates for the domain. If an attacker tricks another CA into attempting to issue a fraudulent certificate, a correctly configured CAA record causes that request to be refused.

NAPTR — Naming Authority Pointer

Less commonly seen day-to-day, NAPTR records support rule-based rewriting of names, most often in telephony systems (ENUM, mapping phone numbers to SIP addresses).

Record Types at a Glance

Type	Maps a name to...	Typical use
A	IPv4 address	Point a hostname at a server
AAAA	IPv6 address	Point a hostname at a server, IPv6
CNAME	Another hostname	Alias to a name that may change
MX	Mail server hostname + priority	Route inbound email
TXT	Arbitrary text	Verification, SPF, DKIM, DMARC
NS	Authoritative name servers	Delegate a zone or subdomain
SOA	Zone metadata	Administrative info, one per zone
PTR	Hostname (reverse lookup)	IP-to-name mapping, mail reputation
SRV	Host + port for a service	VoIP, chat, directory services
CAA	Authorized certificate issuers	Restrict TLS certificate issuance

Looking Up Records Yourself

Two command-line tools cover almost everything you'll need. dig (Linux/macOS, or installed separately on Windows) is the more detailed and scriptable of the two:

Both tools query whatever resolver your system is configured to use by default; append a server address to query a specific one directly, e.g. dig example.com @8.8.8.8, which is useful for checking whether a change has reached a particular public resolver yet without waiting on your own ISP's cache.

Propagation isn't really "propagation." DNS changes take effect on your authoritative servers immediately. What people call "propagation delay" is really just the TTL of the old record expiring in every resolver's cache around the world, one by one, at whatever rate each resolver happens to re-query. There's no single moment a change "goes live" everywhere — it's a gradual cache turnover bounded by whatever TTL was in effect before you made the change.

Further reading: RFC 1035 (DNS), RFC 1912 (Common DNS errors), RFC 6376 (DKIM), RFC 7208 (SPF), RFC 7489 (DMARC), RFC 6844 (CAA).