DNS is the phonebook of the internet, but unlike a phonebook, it stores far more than just names and numbers. Behind every domain sits a collection of records — each one serving a specific purpose, from routing web traffic to fighting email spam to proving domain ownership. If you have ever stared at a DNS management panel wondering what half those record types actually do, this guide breaks down every major type in plain terms, with real examples and the exact syntax you need to configure them correctly.
How DNS Records Are Structured
Every DNS record shares a common structure, regardless of type. Understanding this structure first makes every record type easier to grasp.
Name is the hostname the record applies to. TTL (Time to Live) is how long resolvers cache the record, in seconds. IN means the Internet class — you will always see this. TYPE is the record type, and value is the data the record returns. With that foundation in place, here is every record type you are likely to encounter.
A Record — IPv4 Address
The A record is the most fundamental DNS record. It maps a hostname to a 32-bit IPv4 address. When someone types your domain into a browser, an A record is almost certainly what resolves it to an IP address.
You can have multiple A records for the same hostname, which provides basic round-robin load balancing. Most web hosting control panels refer to A records simply as the main domain record. If your site is down and you suspect a DNS issue, the A record is the first thing to verify.
AAAA Record — IPv6 Address
The AAAA record does exactly what the A record does, but for 128-bit IPv6 addresses. The name comes from the fact that IPv6 is four times the length of IPv4. As IPv6 adoption grows, having an AAAA record alongside your A record is increasingly important.
If your hosting provider has assigned you an IPv6 address, create an AAAA record with it. Visitors on IPv6-only networks (more common on mobile) will reach you faster through the AAAA record than by falling back to IPv4.
CNAME Record — Canonical Name
A CNAME record is an alias. Instead of pointing a hostname directly to an IP address, it points it to another hostname, which then resolves to an IP. CNAMEs are used constantly for subdomains like www, for CDN configurations, and for third-party service integrations like Shopify, Mailchimp landing pages, or Heroku apps.
There are two hard rules with CNAMEs that trip people up constantly. First, you cannot create a CNAME at the zone apex — meaning you cannot CNAME your root domain (example.com) to anything. Use an A record or a host provider's ALIAS/ANAME feature instead. Second, you cannot mix a CNAME with other records for the same name. A CNAME must stand alone.
MX Record — Mail Exchange
MX records tell the internet where to deliver email for your domain. When someone sends an email to user@example.com, their mail server queries the MX records for example.com to find which mail servers accept mail.
The number before the mail server hostname is the priority. Lower numbers are tried first. Having a secondary MX with a higher priority number gives you a failover mail server. MX records must point to hostnames, never to IP addresses directly — so make sure the hostname you enter in an MX record has its own A record.
Common MX configurations for popular providers: Google Workspace uses aspmx.l.google.com at priority 1, Microsoft 365 uses a single yourdomain-com.mail.protection.outlook.com entry, and Zoho Mail uses mx.zoho.com at priority 10.
TXT Record — Text
TXT records hold arbitrary human-readable or machine-readable text. They were originally designed for documentation, but today they are the workhorse of domain verification and email authentication. You will create TXT records when verifying domain ownership with Google, setting up SPF, DKIM, and DMARC, and dozens of other use cases.
A domain can have multiple TXT records simultaneously, and they coexist without conflict. SPF is one TXT record, a Google verification token is another, and a DMARC policy lives at _dmarc.example.com as yet another TXT record.
NS Record — Name Server
NS records define which name servers are authoritative for a domain. These are set at your domain registrar, not in your DNS hosting panel. When a resolver first looks up your domain, it asks the root servers and then the TLD servers which name servers are authoritative for you — and the answer comes from NS records.
You almost never need to edit NS records yourself unless you are migrating DNS hosting to a new provider. They typically carry a TTL of 86400 seconds (24 hours) or longer. If your NS records point to the wrong servers, your entire domain becomes unreachable — so handle these with care.
SOA Record — Start of Authority
The SOA record is auto-generated by your DNS provider and marks the start of a DNS zone. It contains the primary name server, the email of the zone administrator (with the first dot replaced by @), and several timing parameters that control zone transfers and negative caching.
The serial number must increment every time the zone changes — DNS slaves use it to detect when to pull a fresh zone copy. Most managed DNS platforms handle SOA automatically. You will rarely need to edit it manually unless you are running BIND on your own servers.
PTR Record — Pointer (Reverse DNS)
PTR records are the reverse of A records. Where A records map names to IPs, PTR records map IPs back to names. They live in a special zone called in-addr.arpa and are controlled by whoever owns the IP address block — typically your hosting provider or ISP, not your DNS registrar.
Reverse DNS is critically important for email deliverability. Mail servers routinely reject or flag messages from IP addresses that have no PTR record or whose PTR does not match the forward A record (called forward-confirmed reverse DNS). If you are running your own mail server and landing in spam, check your PTR record first. Contact your server host and ask them to set the rDNS for your IP to your mail server hostname.
SRV Record — Service Locator
SRV records specify the hostname and port for specific services. They are used by protocols like SIP (VoIP), XMPP (chat), and Microsoft applications such as Skype for Business, Teams, and Exchange autodiscover.
The format is: priority, weight, port, target. Priority and weight together control load balancing and failover, similar to MX records. Weight distributes load proportionally among records with the same priority. Most people only encounter SRV records when setting up Microsoft 365 or a VoIP system — your provider will give you the exact values to enter.
CAA Record — Certification Authority Authorization
CAA records let you specify which Certificate Authorities (CAs) are allowed to issue SSL/TLS certificates for your domain. They are a security measure — if a CA sees a CAA record that does not include them, they must refuse to issue a certificate even if someone passes domain validation.
The issue tag controls single-domain cert issuance, issuewild controls wildcard certs, and iodef specifies where a CA should report policy violations. If no CAA records exist, any CA can issue for your domain. Adding CAA records is a low-effort, high-value security improvement.
DKIM Record — DomainKeys Identified Mail
DKIM records are TXT records published at a specific subdomain that carry your public key for email signing. Your mail server signs outgoing messages with the matching private key, and receiving servers verify the signature against the public key in DNS.
The subdomain format is always selector._domainkey.yourdomain.com. The selector is chosen by your mail provider — Google Workspace uses google, and most others generate a unique one. Your mail provider will give you the complete TXT record value to copy-paste. Do not try to construct it manually.
DMARC Record — Domain-based Message Authentication
DMARC builds on SPF and DKIM to give you control over what happens to emails that fail authentication. It is a TXT record at the fixed subdomain _dmarc.yourdomain.com.
The p tag sets the policy: none (monitor only), quarantine (send to spam), or reject (block outright). Start with none and use the aggregate reports sent to your rua address to understand your mail flows before moving to quarantine or reject.
ALIAS and ANAME Records — Zone Apex CNAMEs
ALIAS (used by DNSimple, Route 53) and ANAME (used by DNS Made Easy) are non-standard record types that solve the zone apex CNAME restriction. They behave like a CNAME but are resolved server-side, so the returned value is always an IP address — making them valid at the root domain level. If you need to point your root domain to a CDN, load balancer, or platform like Netlify or Vercel, look for ALIAS or ANAME support in your DNS provider. Not all providers offer this.
HTTPS and SVCB Records — Service Binding
These are newer record types (standardized in 2023) designed to improve performance and security for HTTPS connections. An HTTPS record lets a browser discover that a site supports HTTP/3 or has specific connection parameters without first making a plain HTTP request. Cloudflare automatically publishes HTTPS records for zones it manages.
Support is rolling out across browsers and resolvers. You do not need to configure these manually in most cases — your CDN or DNS provider handles it. But understanding them is useful when you see them appear in zone exports or lookup results.
Quick Reference Summary
- A — maps hostname to IPv4 address
- AAAA — maps hostname to IPv6 address
- CNAME — alias pointing to another hostname
- MX — mail server routing
- TXT — text data, used for SPF, DKIM, verification tokens
- NS — authoritative name servers for a zone
- SOA — zone authority and timing parameters
- PTR — reverse DNS, IP to hostname
- SRV — service location with port and priority
- CAA — restrict which CAs can issue certs for your domain
- DKIM — TXT record holding public key for email signing
- DMARC — email authentication policy at _dmarc subdomain
- ALIAS / ANAME — CNAME-like record valid at zone apex
- HTTPS / SVCB — service binding for improved HTTPS negotiation
Choosing the Right TTL for Each Record Type
TTL is often overlooked but matters a lot. A record that changes rarely — like an NS record — can safely have a TTL of 86400 seconds. An A record for a server you might need to migrate should be no higher than 3600 seconds. If you anticipate a change in the next 24 hours, drop the TTL to 300 seconds at least an hour in advance so the low TTL has time to propagate before you make the actual change. After the change, raise it back to 3600 or higher to reduce DNS query load.
Understanding every DNS record type is not just academic — it directly affects site availability, email deliverability, and security. Getting MX records wrong means lost email. Missing DMARC means your domain can be spoofed. Wrong A records mean your site goes offline. Treat your DNS zone with the same care as your server configuration, and audit it regularly to make sure nothing stale or incorrect is lurking.