DNS Records Explained: Every Record Type With Real Examples

A domain's DNS records say where its website lives, which servers take its email, who may issue its SSL certificates and how clients should connect. This page explains every common record type. Each section shows a real record from a live domain, pulled with dig on 12 October 2026, and explains every field in it.

Quick Answer: DNS records are entries on a domain's authoritative nameservers. Each one maps a name to a value: an IPv4 address (A), an IPv6 address (AAAA), another name (CNAME), a mail server (MX), free text (TXT), the zone's nameservers (NS), zone settings (SOA), a service host and port (SRV), a hostname for an IP (PTR), the certificate authorities allowed to issue certificates (CAA), or connection hints for HTTPS (HTTPS and SVCB). To see any domain's records, use our DNS lookup tool.

New to DNS itself? Read what DNS is and how it works first. To learn the lookup commands, see how to check DNS records for any domain.

What are DNS records?

A DNS record is one line in a domain's zone, the set of records its authoritative nameservers publish. Every record has the same five parts. Here is an A record for example.com, as its nameserver (hera.ns.cloudflare.com) publishes it:

example.com.    300    IN    A    104.20.23.154

When a resolver answers from its cache, it shows the time left, so the TTL counts down. A moment later, Cloudflare's 1.1.1.1 resolver returned the same record with 191.

DNS record types at a glance

A record: IPv4 address

An A record maps a name to an IPv4 address. A browser that wants example.com asks for its A records and connects to one of the addresses it gets back.

dig @1.1.1.1 example.com A +noall +answer

example.com.		191	IN	A	172.66.147.243
example.com.		191	IN	A	104.20.23.154

example.com has two A records. A name can have as many as you need, and resolvers return all of them. The order can change between answers. This answer lists the addresses in the reverse order of the nameserver's answer above. Clients usually try the first address, so rotating the order spreads visitors across servers. This is called round-robin DNS. Round-robin DNS does not check whether a server is up.

Both addresses above belong to Cloudflare (AS13335), because example.com sits behind Cloudflare. An A record shows where traffic goes first. That is not always where the site is hosted. Our IP lookup tool shows who owns any address, and the guide on finding your website's IP address explains what the address tells you.

AAAA record: IPv6 address

An AAAA record ("quad A") does the same job for IPv6. An IPv6 address is 128 bits, written as eight groups of hexadecimal digits. Runs of zero groups collapse to ::.

example.com.		227	IN	AAAA	2606:4700:10::6814:179a
example.com.		227	IN	AAAA	2606:4700:10::ac42:93f3

Publish AAAA records only if your server answers on IPv6. Clients that have IPv6 often prefer it, so an AAAA record pointing at a dead address slows down or breaks the site for them. Not every large site publishes one: on 12 October 2026, github.com returned no AAAA record.

CNAME record: alias to another name

A CNAME record (canonical name) says "this name is an alias, look up that other name instead". The value is always a hostname, never an IP address.

www.github.com.		3600	IN	CNAME	github.com.
www.wikipedia.org.	86400	IN	CNAME	dyna.wikimedia.org.

A resolver that finds a CNAME starts again with the target name. It repeats until it reaches A or AAAA records. Each step in that chain is another lookup.

Most hosted services attach to your domain through a CNAME. You point shop.yourdomain.com or docs.yourdomain.com at the hostname the service gives you. The service can then change its IP addresses without asking you to update anything.

CNAME rules

RFC 1034 states: "If a CNAME RR is present at a node, no other data should be present". Two practical limits follow from that:

• No other records on the same name. A name with a CNAME cannot also have MX, TXT or A records.
• No CNAME at the zone apex. The apex (example.com itself) must carry SOA and NS records, so it cannot be a CNAME.

DNS providers work around the apex limit in their own ways. Cloudflare resolves the target itself and answers with A and AAAA records, which it calls CNAME flattening. AWS Route 53 has alias records, and other providers sell ALIAS or ANAME records. The HTTPS record type (covered below) adds a standard way to alias the apex for web traffic.

MX record: mail servers

An MX record (mail exchange) names a server that accepts email for the domain, with a priority number in front.

dig @1.1.1.1 wikipedia.org MX +noall +answer

wikipedia.org.		300	IN	MX	10 mx-in1001.wikimedia.org.
wikipedia.org.		300	IN	MX	10 mx-in2001.wikimedia.org.

Sending servers try the lowest number first. Records with equal numbers share the load, as the two Wikipedia servers above do. Senders use a higher number only when the lower ones fail.

The MX hosts usually reveal the email provider. These are real records from 12 October 2026:

A domain that accepts no email can say so with a null MX (RFC 7505): one MX record with priority 0 and a target of .. example.com publishes exactly that:

example.com.		64	IN	MX	0 .

Senders then reject mail to that domain at once instead of retrying for days. For more on reading and fixing MX records, see how to check MX records.

TXT record: text for policies and verification

A TXT record holds free text. DNS does not interpret the text, but other systems do. Most TXT records today fall into four groups.

SPF: who may send mail

An SPF record lists the servers allowed to send mail for the domain. It starts with v=spf1 and ends with a rule for everyone else.

wikipedia.org.		600	IN	TXT	"v=spf1 include:_cidrs.wikimedia.org ~all"
example.com.		300	IN	TXT	"v=spf1 -all"

include: pulls in another domain's list. ~all asks receivers to treat mail from other servers as suspicious (soft fail). -all tells them to reject it. example.com combines -all with an empty list, so no server may send mail as example.com.

DKIM: signing keys

DKIM publishes a public key at <selector>._domainkey.<domain>. Receiving servers use it to check the signature on incoming mail. The selector comes from the mail service. GitHub publishes one for Google:

google._domainkey.github.com.	TXT	"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAj6T5sl/RwdSqGoYWaWaFbS2UAeyPrEmd0g..."

The key is shortened here, and the TTL and class columns are left out. You can look up a DKIM record only if you know the selector. The selector appears in the s= tag of a signed email's DKIM-Signature header.

DMARC: what to do with failures

DMARC lives at _dmarc.<domain> and tells receivers what to do with mail that fails SPF and DKIM checks, and where to send reports.

_dmarc.wikipedia.org.	600	IN	TXT	"v=DMARC1; p=reject; rua=mailto:dmarc-rua@wikimedia.org;"

p=reject asks receivers to refuse failing mail. The other policies are p=quarantine (send to spam) and p=none (only report). rua is the address for daily aggregate reports.

Domain verification

Services ask you to add a TXT record to prove you control a domain. On 12 October 2026, github.com had 24 TXT records. Most were verification tokens, for example (TTL and class left out):

github.com.		TXT	"google-site-verification=82Le34Flgtd15ojYhHlGF_6g72muSjamlMVThBOJpks"
github.com.		TXT	"stripe-verification=f88ef17321660a01bab1660454192e014defa29ba7b8de9633c69d6b4912217f"

You can usually remove old tokens once the service has verified the domain. Check the service's docs first, because some services check the record again later.

NS record: authoritative nameservers

NS records list the nameservers that hold a domain's zone. They exist in two places: in the parent zone (the .com servers, set through your registrar) and in your own zone. The copy at the parent is the one that sends resolvers to you.

example.com.		77399	IN	NS	hera.ns.cloudflare.com.
example.com.		77399	IN	NS	elliott.ns.cloudflare.com.

NS hosts name the DNS provider, which is often not the web host. GitHub splits its zone across two providers (four of its eight NS records shown, TTL and class left out):

github.com.		NS	dns1.p08.nsone.net.
github.com.		NS	dns2.p08.nsone.net.
github.com.		NS	ns-421.awsdns-52.com.
github.com.		NS	ns-520.awsdns-01.net.

The nsone.net hosts are NS1 (IBM) and the awsdns hosts are Amazon Route 53. GitHub lists four of each. Use at least two nameservers, so one outage does not take the domain offline.

The .com servers hand out delegations with a TTL of 172800 seconds (48 hours). That is the main reason a nameserver change can take up to two days to reach everyone. To see which registrar holds the delegation, use our WHOIS lookup tool.

SOA record: zone settings

Every zone has exactly one SOA record (start of authority) at its apex. It names the primary nameserver and an admin contact, and it carries five numbers.

example.com.		1800	IN	SOA	elliott.ns.cloudflare.com. dns.cloudflare.com. 2416374680 10000 2400 604800 1800

Managed DNS providers write the SOA for you. The field you are most likely to need is the last one. If you look up a new subdomain before you create it, resolvers cache the "does not exist" answer for up to this long.

SRV record: host and port for a service

An SRV record tells a client which host and port run a named service. The name has the form _service._protocol.domain (RFC 2782). The value is four fields: priority, weight, port and target.

_imaps._tcp.gmail.com.	86400	IN	SRV	5 0 993 imap.gmail.com.
_xmpp-client._tcp.jabber.org. 60 IN	SRV	30 30 5222 scarlet.jabber.org.
_autodiscover._tcp.fastmail.com. 3600 IN SRV	0 1 443 autodiscover.fastmail.com.
_submission._tcp.fastmail.com. 3600 IN	SRV	0 0 0 .

The first record tells mail clients that Gmail's IMAP service runs on imap.gmail.com, port 993. The last one tells them that fastmail.com offers no mail submission at that name. You see SRV records in email client autoconfiguration, XMPP chat, SIP telephony, Microsoft 365 and Minecraft servers.

PTR record: reverse DNS

A PTR record maps an IP address back to a hostname. It lives in a special zone: for IPv4, reverse the address and add in-addr.arpa.

dig @1.1.1.1 -x 1.1.1.1 +noall +answer

1.1.1.1.in-addr.arpa.	95	IN	PTR	one.one.one.one.

The owner of the IP address controls its PTR record, not the owner of the domain. For a server you rent, that means your hosting provider, usually through its control panel. Mail servers check PTR records, and many reject or flag mail from an IP whose PTR is missing or does not match. PTR records can also name the host: Wikipedia's address 185.15.59.224 reverses to text-lb.esams.wikimedia.org. Our IP lookup tool shows the reverse DNS name for any address.

CAA record: which CAs may issue certificates

A CAA record (certification authority authorization, RFC 8659) lists the certificate authorities allowed to issue SSL/TLS certificates for a domain. CAs must check CAA before they issue. A CA that is not on the list must refuse.

dig @1.1.1.1 CAA google.com +noall +answer

google.com.		86400	IN	CAA	0 issue "pki.goog"

Google allows only its own CA. Wikipedia allows two, and adds a contact for reports:

wikipedia.org.		600	IN	CAA	0 iodef "mailto:dns-admin@wikimedia.org"
wikipedia.org.		600	IN	CAA	0 issue "letsencrypt.org"
wikipedia.org.		600	IN	CAA	0 issue "pki.goog"

Each CAA record has three parts:

Three rules decide what happens in practice:

• No CAA record means no restriction. Any CA may issue. On 12 October 2026, example.com returned no CAA record.
• CAs climb the tree. For shop.example.com, a CA checks that name first, then example.com. The first CAA set it finds applies. A CAA record on the apex covers every subdomain without its own.
• An empty issuer blocks everyone. 0 issue ";" allows no CA at all for that tag.

If certificate renewal suddenly fails with a CAA error, your CAA records probably do not list the CA your host or content delivery network (CDN) uses. Add it, or remove the CAA records. To see which CA issued a site's current certificate, use our SSL checker.

HTTPS and SVCB records: connection hints

SVCB (service binding, type 64) and HTTPS (type 65) records come from RFC 9460, published in 2023. HTTPS is the version for websites. A browser reads it before connecting, to learn which HTTP versions the server supports and which addresses to use.

You need a recent dig to read them. With BIND's dig 9.20, the query looks like this:

dig @1.1.1.1 HTTPS cloudflare.com +noall +answer

cloudflare.com.		300	IN	HTTPS	1 . alpn="h3,h2" ipv4hint=104.16.132.229,104.16.133.229 ipv6hint=2606:4700::6810:84e5,2606:4700::6810:85e5

The dig that ships with macOS is version 9.10.6. It does not know the type name, so you have to ask for TYPE65. The answer comes back as raw hex:

cloudflare.com.		300	IN	TYPE65	\# 61 0001000001000602683302683200040008681084E5681085E5000600 ...

Reading the decoded record from left to right:

Other parameters include port and ech, the key for Encrypted Client Hello.

Cloudflare generates HTTPS records for proxied hostnames when HTTP/2 or HTTP/3 and Universal SSL are on. example.com is one of them:

example.com.		179	IN	HTTPS	1 . alpn="h3,h2" ipv4hint=104.20.23.154,172.66.147.243 ipv6hint=2606:4700:10::6814:179a,2606:4700:10::ac42:93f3

Alias mode (priority 0) is the standard answer to the "no CNAME at the apex" problem for web traffic. RFC 9460 gives this example:

@    7200    IN    HTTPS    0 pool.svc.example.

Clients that understand HTTPS records follow it to pool.svc.example. The apex still needs A and AAAA records for clients that do not.

SVCB is the same format for services other than HTTPS. One real use is Discovery of Designated Resolvers (RFC 9462). A device asks its resolver for _dns.resolver.arpa and learns where the resolver's encrypted DNS endpoints are. Cloudflare's 1.1.1.1 answers:

_dns.resolver.arpa.	300	IN	SVCB	1 one.one.one.one. alpn="h2,h3" port=443 ipv4hint=1.1.1.1,1.0.0.1 ...
_dns.resolver.arpa.	300	IN	SVCB	2 one.one.one.one. alpn="dot" port=853 ipv4hint=1.1.1.1,1.0.0.1 ...

The first record points to DNS over HTTPS (DoH) on port 443. The second points to DNS over TLS on port 853.

Our DNS lookup tool does not show HTTPS or SVCB records yet. Use dig HTTPS with a recent BIND dig, or a DoH query as described in how to check DNS records.

Less common record types

Example zone setups

The first setup uses addresses from the documentation ranges (192.0.2.0/24 and 2001:db8::/32). It shows the shape of a zone, not a real site.

A website with Google Workspace mail

If you are starting from scratch, you need a domain first: find one that is available to register, then add records like these.

; Website
example.com.          3600   IN   A       192.0.2.10
example.com.          3600   IN   AAAA    2001:db8::10
www.example.com.      3600   IN   CNAME   example.com.

; Email (Google Workspace)
example.com.          3600   IN   MX      1 smtp.google.com.
example.com.          3600   IN   TXT     "v=spf1 include:_spf.google.com ~all"
_dmarc.example.com.   3600   IN   TXT     "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

; Only Let's Encrypt may issue certificates
example.com.          3600   IN   CAA     0 issue "letsencrypt.org"

Google's current setup guide uses the single smtp.google.com MX record. Domains set up before 2023 often still carry the older aspmx records, as anthropic.com does above. Google still supports both.

A store on a hosted platform

Hosted platforms give you the values to enter. Shopify's manual setup asks for an A record on the apex and a CNAME on www:

example.com.          3600   IN   A       23.227.38.65
www.example.com.      3600   IN   CNAME   shops.myshopify.com.

The apex gets an A record because it cannot be a CNAME. The www CNAME lets Shopify change its addresses later without you editing the record.

Short TTLs for records that change

example.com's nameserver hands out its A records with a TTL of 300 seconds, as shown at the top of this page. A short TTL lets a change reach every resolver within minutes. The cost is more queries to the nameservers. Records that rarely change, such as NS and MX, often use hours or a day.

Look up DNS records for any domain

Enter a domain below to see its A, AAAA, CNAME, MX, NS, TXT, SOA, CAA and SRV records, with the hosting provider, SSL certificate and IP location.

For the command line, online tools and DoH, see how to check DNS records for any domain.

Troubleshooting DNS records

The site still shows the old server after a change

Resolvers keep serving the old record until its TTL runs out. If the old TTL was 86400, that can take a day. Before a planned move, lower the TTL to 300. Do it at least one old TTL before the move. Then ask the authoritative nameserver directly to confirm the new value is published:

dig @hera.ns.cloudflare.com example.com A +norec +short

Replace the server with one of your own NS records. If the authoritative answer is right, the rest is caching.

Email bounces or lands in spam

Check that the MX records point at your current provider. Then check that the SPF record lists every service that sends for you, that DKIM is published under the selector your provider uses, and that _dmarc exists.

dig yourdomain.com MX +short
dig yourdomain.com TXT +short
dig _dmarc.yourdomain.com TXT +short

A domain can have only one SPF record. Two v=spf1 TXT records make SPF fail.

NXDOMAIN or "domain not found"

The name does not exist in DNS. Check that the domain is registered and not expired, that the NS records at the registrar match your DNS provider, and that the provider has a zone for the domain. For a subdomain, check that you created the record on the right name.

Certificate issuance fails

Run dig CAA yourdomain.com +short. If records come back and none names your CA, add an issue record for it.

A CNAME conflicts with another record

Most DNS dashboards refuse to save a CNAME next to other records on the same name. Remove the other records, or use an A record instead. For the apex, use your provider's flattening or alias feature.

Frequently Asked Questions

What are the main types of DNS records?

The ones almost every domain uses are A and AAAA (addresses), CNAME (aliases), MX (mail servers), TXT (SPF, DKIM, DMARC and verification), NS (nameservers) and SOA (zone settings). SRV, PTR, CAA and HTTPS records are common but not universal. Each has its own section on this page.

How many DNS records can a domain have?

The DNS standards set no fixed limit. DNS providers can set their own limits per zone, so check your provider's plan if you need thousands of records.

Can I have multiple A records for one domain?

Yes. Resolvers return all of them, and clients pick one. This spreads traffic between servers. DNS does not check whether each server is healthy, so a dead server keeps getting a share of visitors until you remove its record.

What is the difference between a CNAME and an A record?

An A record points a name at an IPv4 address. A CNAME points a name at another name, and the resolver then looks up that name's addresses. Use a CNAME when a service gives you a hostname to point at, and an A record when you have a fixed IP address.

What happens if a domain has no CAA record?

Any certificate authority may issue certificates for it. CAA is optional. Adding a CAA record limits issuance to the CAs you list.

Do I need HTTPS records?

No. Browsers fall back to A and AAAA records when there is no HTTPS record. Cloudflare generates HTTPS records for proxied hostnames, so a site behind Cloudflare usually has one without the owner adding it.

How long do DNS changes take to apply?

A new record is usually visible within minutes. A changed record takes up to its old TTL, because resolvers keep the cached value until it expires. Nameserver changes can take up to 48 hours because of the TTL on the delegation at the TLD.

Wrapping up

Most domains need only A or AAAA, CNAME, MX, TXT and NS records. Add CAA if you want to limit who can issue certificates. To see what a domain publishes today, run it through our DNS lookup tool or the full hosting check.

Related articles

• What Is DNS and How Does It Work?
• How to Check DNS Records for Any Domain
• MX Record Check: How to Find a Domain's Mail Servers
• Website IP Lookup: How to Find Your Website's IP Address
• Where Is This Website Hosted? How to Find Out