What are the most important DNS records?

For most domains the essential records are A (or AAAA) records that point your domain to a server, MX records that route email, and TXT records that hold verification and email-authentication data like SPF and DMARC. NS records are also required because they delegate your domain to its nameservers.

How many DNS records can a domain have?

There is no fixed limit set by the DNS protocol. A domain can have many records of different types and multiple records of the same type, for example several A records for load balancing or several MX records for mail redundancy. Practical limits come from your DNS provider, not the protocol.

Do DNS changes take effect immediately?

No. Resolvers cache records for the duration of their TTL (time to live), so a change can take anywhere from a few minutes to 48 hours to be seen everywhere. This delay is called DNS propagation.

Why can I not put a CNAME on my root domain?

Because a CNAME cannot coexist with any other record on the same name, per RFC 1034 section 3.6.2, and a root domain must carry SOA and NS records. A root CNAME is therefore invalid. DNS providers work around this with ALIAS, ANAME, or CNAME-flattening records, which resolve the target behind the scenes and answer with an A record. These are provider-specific features rather than DNS standards, so the name varies between providers.

Why does a DNS record still fail after I create it?

Usually negative caching. When you query a hostname that does not exist yet, the no-such-record answer is itself cached, for a duration set by the last field of the zone's SOA record as described in RFC 2308. Creating the record afterwards does not clear that cached negative answer, so lookups keep failing until it expires. This is why a new record often works from one machine and not another.

What is an SOA record?

Start of Authority. Every zone has exactly one, and it holds the primary nameserver, the administrative contact, a serial number that secondary servers use to detect changes, and the refresh, retry, and expire timers. Its final field sets how long resolvers cache negative answers, which is the field most likely to affect you in practice.

Can I set my own PTR record?

No, not in your own zone. Reverse DNS lives under in-addr.arpa for IPv4 and is controlled by whoever owns the IP address block, so you set it through your hosting or cloud provider rather than your DNS provider. It matters because receiving mail servers frequently check that a sending IP's reverse DNS resolves to a name that forward-resolves back to the same IP.

What happens if I change my nameservers?

You redirect the entire domain to a different DNS provider at once, replacing every record it serves. If the new provider's zone is not fully configured beforehand, your website, email, and everything else break simultaneously. Always build and verify the complete zone at the new provider first, querying its nameservers directly, and only then change the delegation at your registrar.

DNS Records Explained: A Complete Guide to Every Record Type

DNS (the Domain Name System) is the phone book of the internet: it translates human-friendly names like example.com into the machine addresses and routing instructions computers actually use. A DNS record is a single instruction in that phone book. It tells the internet where to send web traffic, where to deliver email, who is allowed to issue your SSL certificates, and more. The whole system is defined by RFC 1034 and RFC 1035, the original 1987 specifications that still govern how names resolve today.

Remember one thing and the rest follows. Each record has a type (A, MX, TXT, and so on), a name (which hostname it applies to), a value (what it points to), and a TTL (how long resolvers may cache it). Everything below is a variation on that idea.

Want to see every record for a domain right now? Our DNS analyzer resolves all the types covered here in a single pass.

The record types you actually need to know

Dozens of record types exist, all of them catalogued in the IANA DNS parameters registry. In day-to-day work, seven of them cover almost everything.

Record	Purpose	Points to	Common use
A	Maps a name to an IPv4 address	`93.184.216.34`	Your website's server
AAAA	Maps a name to an IPv6 address	`2606:2800:220:1::`	IPv6-capable servers
CNAME	Aliases one name to another name	`target.example.com`	Subdomains, CDNs
MX	Routes email for the domain	`mail.example.com` (priority)	Email delivery
TXT	Holds arbitrary text	`"v=spf1 ..."`	Verification, SPF, DKIM, DMARC
NS	Delegates the domain to nameservers	`ns1.provider.com`	Which servers answer for you
CAA	Restricts who can issue SSL certs	`0 issue "letsencrypt.org"`	Certificate security

A and AAAA: where your site lives

An A record points a hostname to an IPv4 address; an AAAA record does the same for IPv6. When someone visits your site, their browser looks up the A/AAAA record to find the server's IP. The two are not interchangeable. They serve different IP versions, and you often run both. See A vs AAAA records for when each matters.

CNAME: aliases

A CNAME says "this name is really an alias for that name." It's how www.example.com often points at example.com, and how you point a subdomain at a CDN or SaaS host. One rule matters above the rest: a CNAME can't coexist with other records on the same name, per RFC 1034 (section 3.6.2), which is exactly why you can't put one on a root domain. The full story is in CNAME vs A records.

MX: email routing

MX (Mail Exchange) records tell the world which servers accept email for your domain, each with a priority number (lower wins). Without correct MX records, mail to your domain bounces. Details and worked examples are in MX records explained.

TXT: verification and email authentication

TXT records hold free-form text, which has made them the home for some of the most important modern records: SPF, DKIM and DMARC (email authentication), plus domain-ownership verification for services like Google and Microsoft. Start with TXT records explained.

NS: delegation

NS records declare which nameservers are authoritative for your domain. They're set at your registrar and copied into your DNS zone. Get them wrong and nothing else resolves. See NS records explained.

CAA: certificate authority authorization

CAA records are a security control that lists which certificate authorities are allowed to issue SSL/TLS certificates for your domain. They're optional, but worth setting. See CAA records explained.

Beyond the seven: records you will eventually meet

The seven above cover daily work. A handful more show up often enough to recognise.

Record	Purpose
SOA	Start of Authority. One per zone, holding the primary nameserver, the admin contact, the serial number, and the timers below
SRV	Locates a service on a host and port, defined in RFC 2782. Used by SIP, XMPP, and Microsoft directory services
PTR	Reverse DNS. Maps an IP back to a name, and mail servers frequently check it
SVCB / HTTPS	Modern service-binding records that let a client learn connection parameters, including HTTP/3 support, before connecting
DS, DNSKEY, RRSIG, NSEC	The DNSSEC records that cryptographically sign a zone

The SOA record deserves particular attention because one of its fields causes a problem people rarely diagnose correctly. Its final value sets the negative caching TTL, per RFC 2308: how long resolvers remember that a record does not exist. If you query a hostname before creating it, the "no such record" answer gets cached, and creating the record does not clear it. The lookup keeps failing for a while afterwards through no fault of your configuration. If you have ever added a record and found it working from one machine but not another, this is usually why.

PTR records matter more than their obscurity suggests. Receiving mail servers often check that a sending IP's reverse DNS resolves to a name that forward-resolves back to the same IP. Failing that check hurts deliverability, and you cannot set a PTR record in your own zone. It belongs to whoever controls the IP block, so it is set through your hosting provider.

How a lookup actually resolves

Understanding the chain makes propagation and caching behaviour obvious rather than mysterious.

When something looks up www.example.com, a recursive resolver (usually your ISP's, or a public one) works down a hierarchy on your behalf:

Root servers answer "I do not know example.com, but here is who handles .com." There are 13 root server identities, a through m.root-servers.net, distributed worldwide by anycast.
The TLD nameservers for .com answer "here are the authoritative nameservers for example.com", which are the NS records set at the registrar.
The authoritative nameservers return the actual answer, with a TTL attached.

The resolver caches each step for as long as the TTL allows and serves that cached copy to everyone who asks next. That cache is the whole story behind propagation: your authoritative server updated instantly, but resolvers around the world keep serving the old answer until their copies expire. Nothing is actually propagating anywhere, which is why DNS propagation explained is really a guide about waiting for caches to expire.

The chain also explains the most catastrophic DNS mistake. Change your NS records at the registrar and you replace step 2, redirecting the entire domain to a different provider. If that provider's zone is not fully configured first, every record disappears at once: website, email, everything. Build the zone at the new provider, verify it by querying its nameservers directly, and only then change the delegation.

Mistakes that break things

A few misconfigurations account for most DNS incidents.

A CNAME on the root domain. The protocol forbids a CNAME coexisting with other records on the same name, and a root domain must carry SOA and NS records, so a root CNAME is invalid. Providers work around this with non-standard ALIAS, ANAME, or CNAME-flattening records that resolve the target and answer with an A record. These are provider features, not DNS standards, so the name differs everywhere.
Multiple SPF records. A domain may publish only one. Two TXT records both starting v=spf1 is a permanent error, not a merge, and it breaks authentication entirely. See what is SPF.
Forgetting the trailing dot. In a zone file, mail.example.com without a trailing dot is treated as relative and expands to mail.example.com.example.com. Most web control panels handle this for you, but raw zone files do not.
Leaving TTLs high during a migration. Lower TTLs to 300 seconds at least 24 hours before you plan to move, so the old high TTL has already expired everywhere by the time you make the change.
Removing the old server too early. Because of caching, traffic keeps arriving at the old IP after a change. Leave it running until at least the old TTL has passed.

TTL and propagation

Every record carries a TTL (time to live) in seconds, telling resolvers how long they may cache the answer. A low TTL (300s) means changes appear quickly but generates more lookups; a high TTL (86400s) is efficient but slow to update. Caching is the reason edits aren't instant. See DNS propagation explained for realistic timelines and how to speed up a migration.

How to inspect your records

You don't need command-line tools to audit a domain. Our DNS analyzer resolves A, AAAA, MX, TXT, NS, CNAME and CAA records in one pass and flags common misconfigurations. If you prefer the terminal, how to check DNS records walks through dig and nslookup.

Once these seven record types make sense, almost every DNS task becomes the same job: reading and editing the right line in the phone book. Pointing a domain at a host, setting up email, verifying ownership, debugging an outage. They all come down to that.