DNS Records Explained: The Complete Guide to Every Type

PAYATE Team· Oct 26, 2026· 19 min read

DPAYATE

Every time you open a website, send an email, or connect an app to a server, something invisible happens first: a DNS lookup. The Domain Name System (DNS) is the phone book of the internet. It turns human-friendly names like example.com into the machine addresses and instructions that actually move your traffic. And the entries in that phone book are called DNS records.

If you have ever pointed a domain at a new host, set up email, added a Google or Microsoft verification string, installed an SSL certificate, or tried to figure out why your site “isn’t showing up yet,” you were dealing with DNS records — whether you knew it or not. This guide explains what each DNS record type does, in plain English, with real examples, so that the next time you open a DNS dashboard it finally makes sense.

Throughout the article you can follow along with a live tool: run any domain through the free DNS Lookup to see its actual records, and the DNS Propagation Checker to see whether a change has gone live everywhere yet.

What Is DNS and Why Records Matter

Computers don’t speak in names; they speak in numbers. A server might live at the IPv4 address 93.184.216.34 or the IPv6 address 2606:2800:220:1:248:1893:25c8:1946. Nobody wants to memorise that, so DNS lets us use example.com instead and quietly translates the name into the address in the background.

But DNS does far more than map names to IP addresses. It also tells the world which servers handle a domain’s email, which certificate authorities may issue its SSL certificates, how to prove you own the domain, and which other names it is an alias for. All of that lives in a domain’s DNS zone, a collection of records managed at your DNS provider (your registrar, your host, or a dedicated service like Cloudflare).

How a DNS Lookup Actually Works

When your browser needs to find example.com, it asks a chain of servers:

Recursive resolver — usually run by your ISP or a public provider (Google 8.8.8.8, Cloudflare 1.1.1.1). It does the legwork on your behalf.
Root servers — they don’t know example.com but they know who runs .com.
TLD servers — the .com servers point to the domain’s authoritative name servers.
Authoritative name servers — these hold the actual records and return the answer.

The answer is then cached for a period called the TTL (more on that later), so the next lookup is instant. This caching is exactly why DNS changes don’t take effect everywhere at once — a topic we’ll return to.

The Anatomy of a DNS Record

Almost every DNS record shares the same basic shape:

Name — the host the record applies to (@ for the root domain, www, mail, etc.).
Type — A, AAAA, CNAME, MX, TXT, and so on.
Value / Data — what the record points to (an IP, a hostname, a block of text).
TTL — how long resolvers may cache it, in seconds.
Priority — used only by some records such as MX and SRV.

With that mental model in place, let’s walk through every record type you are likely to meet.

A Record — The IPv4 Address

The A record (“Address”) is the most fundamental record of all. It maps a hostname to an IPv4 address.

example.com.    3600    IN    A    93.184.216.34

This says: “When someone asks for example.com, send them to 93.184.216.34.” You’ll typically have an A record for your root domain and often one for www (though www is frequently a CNAME instead).

A single name can have multiple A records pointing to several IPs; resolvers hand them out in rotation, giving you a simple form of load balancing known as “round-robin DNS.” Large sites like Google return different A records depending on your location, which is why the DNS Propagation Checker may show different IPs from different resolvers for such domains — that’s geo-balancing, not a propagation problem.

AAAA Record — The IPv6 Address

As the internet runs out of IPv4 addresses, IPv6 is taking over, and the AAAA record (pronounced “quad-A”) is its equivalent of the A record. It maps a hostname to a 128-bit IPv6 address.

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

Modern hosting should publish both A and AAAA records so visitors on IPv6 networks (increasingly common on mobile) connect over the faster, more direct protocol. If your AAAA record is missing or wrong, IPv6 users may experience slow timeouts before falling back to IPv4 — a subtle performance bug worth checking.

CNAME Record — The Alias

A CNAME (“Canonical Name”) record makes one name an alias for another name rather than for an IP address.

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

Here www.example.com is simply an alias of example.com; whatever IP the root resolves to, www inherits it. CNAMEs are extremely common for pointing subdomains at third-party services: shop.example.com at a Shopify address, blog.example.com at a hosted blog, or a CDN endpoint.

The Two Golden Rules of CNAMEs

A CNAME cannot coexist with other records on the same name. You cannot have a CNAME and an MX (or TXT, or A) record on the exact same host. This is why you usually cannot put a CNAME on the root domain (example.com), because the root must also carry NS and SOA records.
CNAMEs add a lookup hop. Each alias requires resolving the target too, so deep CNAME chains add latency. Many providers now offer “CNAME flattening” or ALIAS/ANAME records to let the root behave like a CNAME without breaking the rules.

A frequent question is CNAME vs A record: use an A record when you know the fixed IP; use a CNAME when you want to follow another name that might change IP on its own (like a load-balanced service). If the upstream service changes its IP, your CNAME keeps working automatically — a big maintenance win.

MX Record — Mail Exchange

The MX record tells the world which servers accept email for your domain. Without correct MX records, email to you@example.com simply bounces.

example.com.    3600    IN    MX    10    mail1.example.com.
example.com.    3600    IN    MX    20    mail2.example.com.

The number before the hostname is the priority (sometimes called preference): lower numbers are tried first. In the example above, sending servers try mail1 first and fall back to mail2 only if the first is unreachable. Giving two servers the same priority spreads load between them.

If you use Google Workspace, Microsoft 365, or a provider like Zoho, you’ll paste in a specific set of MX records they give you. A classic support ticket is “email stopped working” after a DNS change wiped the MX records — always confirm them with a DNS Lookup after editing your zone.

TXT Record — Free-Form Text (and the Backbone of Email Security)

The TXT record holds arbitrary text, and over the years it has become one of the busiest records in any zone. Its three biggest jobs are email authentication and domain verification.

SPF — Sender Policy Framework

An SPF record is a TXT record that lists which servers are allowed to send email on behalf of your domain:

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

Receiving servers check whether the sending server is authorised. If it isn’t, the message can be marked as spam or rejected. The ~all at the end is a “soft fail” (suspicious but accept); -all is a “hard fail” (reject outright).

DKIM — DomainKeys Identified Mail

DKIM adds a cryptographic signature to your outgoing mail; the matching public key lives in a TXT record at a selector subdomain such as selector1._domainkey.example.com. Receivers verify the signature to confirm the message really came from you and wasn’t altered in transit.

DMARC — Policy and Reporting

DMARC ties SPF and DKIM together and tells receivers what to do with mail that fails both, plus where to send reports:

_dmarc.example.com.    IN    TXT    "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

Getting SPF, DKIM and DMARC right is the single biggest thing you can do to improve email deliverability and stop spammers spoofing your domain. Because they all live in TXT records, you can inspect them instantly with a DNS Lookup set to TXT.

Domain Verification

Google Search Console, Microsoft 365, Facebook Business, and countless SaaS tools ask you to add a TXT record to prove you control the domain. These are harmless strings like google-site-verification=abc123... and can be safely left in place.

NS Record — Name Servers

The NS record lists the authoritative name servers responsible for a domain — the servers that actually hold the zone and answer queries about it.

example.com.    86400    IN    NS    ns1.provider.com.
example.com.    86400    IN    NS    ns2.provider.com.

When you move DNS hosting (say, to Cloudflare), the key step is changing the NS records at your registrar to the new provider’s name servers. Until those propagate, the old provider still answers. If your NS records don’t match what the registrar has delegated, you get the dreaded “lame delegation” and intermittent failures. You can confirm a domain’s name servers with a DNS Lookup (NS) or a WHOIS Lookup, which also lists them.

SOA Record — Start of Authority

Every zone has exactly one SOA record. It’s the zone’s “cover page,” describing administrative details:

example.com.  IN  SOA  ns1.provider.com. admin.example.com. (
            2026010501 ; serial
            7200       ; refresh
            3600       ; retry
            1209600    ; expire
            3600 )     ; minimum TTL

The fields are:

Primary name server — the main authoritative server.
Admin email — written with a dot instead of @ (so admin.example.com means admin@example.com).
Serial — a version number that must increase on every change so secondary servers know to update.
Refresh / Retry / Expire — timers controlling how secondaries sync.
Minimum TTL — how long negative (NXDOMAIN) answers are cached.

You’ll rarely edit the SOA by hand, but reading the serial number is a quick way to confirm whether a zone was recently updated.

CAA Record — Certificate Authority Authorization

The CAA record is a security control that restricts which certificate authorities (CAs) may issue SSL/TLS certificates for your domain.

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

This says only Let’s Encrypt may issue certificates for the domain. If any other CA receives a request, it must refuse. CAA records are a cheap, powerful defence against mis-issued certificates — a real attack vector — and every serious domain should have them. Pair this with the SSL Certificate Checker to confirm your live certificate matches your policy.

Other Records Worth Knowing

PTR Record — Reverse DNS

A PTR record maps an IP address back to a hostname — the reverse of an A record. It lives in a special reverse zone and is managed by whoever controls the IP block (usually your hosting provider). Correct reverse DNS (rDNS) is essential for sending email: many mail servers reject messages from IPs whose PTR doesn’t match their forward hostname.

SRV Record — Service Location

The SRV record advertises the host and port for a specific service, used by protocols like SIP (VoIP), XMPP (chat), and Microsoft services. It carries priority and weight like MX, plus a port number.

NAPTR, TLSA, and More

There are dozens of rarer types — NAPTR for telephone-number mapping, TLSA for DANE (pinning certificates in DNS), HTTPS/SVCB for modern connection hints — but 95% of real-world DNS management involves the records above.

TTL: Why DNS Changes Take Time

The TTL (Time To Live) is a number of seconds attached to every record telling resolvers how long they may cache the answer before asking again. A TTL of 3600 means “cache this for one hour.”

TTL is the single biggest source of confusion around DNS. When you change a record, resolvers that cached the old value keep serving it until the TTL expires. That’s why a change can appear instantly for you but take hours for others — a process called propagation.

The Pro Move: Lower the TTL Before a Migration

If you know you’re about to change a record, lower its TTL a day or two in advance (say to 300 seconds). Once the old long TTL has expired everywhere, your actual change will propagate in minutes instead of hours. After the migration settles, raise the TTL back up to reduce lookup load.

To watch a change roll out across the major public resolvers in real time, use the DNS Propagation Checker. When Google, Cloudflare, and the others all return the new value, you’re fully propagated.

How to Check Your DNS Records

You don’t need command-line tools to inspect DNS. The quickest way is a browser-based lookup:

Open the DNS Lookup tool.
Enter your domain and choose a record type (or “All records”).
Read the values and TTLs straight from the public name servers.

If you prefer the terminal, the classic commands are dig example.com MX or nslookup -type=TXT example.com. But for a quick visual check — especially when you’re on a phone or a locked-down work machine — a web tool is faster and shows everything at once.

Common DNS Mistakes (and How to Avoid Them)

Wiping MX records during edits. Always re-check email records after any zone change.
Putting a CNAME on the root domain. Use ALIAS/ANAME or your provider’s flattening feature instead.
Two SPF records. A domain may have only one SPF TXT record; merge multiple senders into a single v=spf1 line using include:.
Expecting instant propagation. Respect the TTL; lower it before planned changes.
Forgetting IPv6. Publish AAAA records so modern networks connect cleanly.
Missing CAA records. Lock down who can issue your certificates.

DNS and Security: Don’t Stop at Records

Plain DNS has no authentication, which historically made it vulnerable to cache poisoning — an attacker tricking a resolver into caching a forged answer and redirecting your visitors. The modern defence is DNSSEC, which cryptographically signs your zone so resolvers can verify answers are genuine. If you run anything important on your domain, it’s worth confirming whether DNSSEC is enabled and validating with the DNSSEC Checker. Combined with correct SPF/DKIM/DMARC and CAA records, DNSSEC rounds out a genuinely hardened domain.

Worked Examples: Real DNS Setups Step by Step

Theory clicks when you see it applied. Here are three of the most common real-world DNS tasks, spelled out record by record.

Example 1 — Pointing a New Domain at a Web Host

You bought mycoolsite.com and your host gave you an IP, 203.0.113.10. The minimum you need is:

@      A       203.0.113.10        ; root domain -> server
www    CNAME   mycoolsite.com.     ; www is an alias of the root

Now both mycoolsite.com and www.mycoolsite.com resolve to your server. If your host supports IPv6, add an AAAA record for the root too. After saving, confirm it with the DNS Lookup — if the A record shows your host’s IP, you’re live (once the TTL on any previous record expires).

Example 2 — Setting Up Google Workspace Email

To receive email at @mycoolsite.com through Google, you add Google’s MX record plus the SPF and DKIM TXT records they provide:

@                      MX    1   smtp.google.com.
@                      TXT   "v=spf1 include:_spf.google.com ~all"
google._domainkey      TXT   "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."
_dmarc                 TXT   "v=DMARC1; p=none; rua=mailto:dmarc@mycoolsite.com"

Note how email relies entirely on DNS: MX routes the mail, SPF authorises Google’s servers to send as you, DKIM lets receivers verify signatures, and DMARC sets the policy. Miss any of these and you’ll see mail land in spam or bounce. Verify each with a TXT lookup.

Example 3 — Adding a Subdomain for a Third-Party Service

You want status.mycoolsite.com to point at a hosted status-page provider. They give you a target hostname:

status    CNAME    statuspage.hosted-provider.com.

That’s it — the CNAME follows the provider’s address wherever it moves. This pattern (a CNAME on a subdomain pointing at a SaaS) is how most modern integrations work, from help desks to e-commerce to documentation sites.

The Layers of DNS Caching

When people say “DNS is cached,” they’re glossing over the fact that there are several caches stacked on top of each other, and a change isn’t visible until the relevant ones expire:

Browser cache — browsers keep their own short-lived DNS cache (often a minute or two).
Operating system cache — your OS caches lookups; you can flush it (ipconfig /flushdns on Windows, sudo dscacheutil -flushcache on macOS).
Router cache — home routers often cache DNS for the whole network.
Recursive resolver cache — your ISP’s or public resolver’s cache, governed by the record’s TTL. This is the big one.

When you’re testing a change and “it still shows the old value,” the culprit is almost always one of these caches holding the previous answer until its timer runs out. The DNS Propagation Checker queries resolvers directly, bypassing your local caches, so it shows you the authoritative picture rather than whatever your laptop happens to remember.

Advanced Records: ALIAS, ANAME, and HTTPS/SVCB

We noted that you can’t put a CNAME on a root domain. Providers solved this with ALIAS or ANAME records — a CNAME-like record that’s legal at the root. The DNS provider resolves the target behind the scenes and answers with the resulting A/AAAA records, so the root can “follow” another name without breaking the rules.

Newer still are the HTTPS and SVCB record types, which let a domain advertise connection hints — such as support for HTTP/3, the correct port, or Encrypted Client Hello parameters — before the browser connects. They speed up and secure the initial handshake, and adoption is growing fast at major CDNs. You’ll see these appear in a full record dump as the web continues to modernise.

DNS and SEO: Why It Matters for Rankings

DNS doesn’t directly rank your pages, but it underpins several things that do. Site speed starts with DNS resolution — a slow or distant name server adds latency to every first visit, and resolution time counts toward the metrics search engines watch. Reliability matters too: if your name servers go down, your site is unreachable and crawlers record errors. Using a fast, redundant DNS provider with multiple geographically distributed name servers (visible as several NS records) protects both users and rankings.

Correct DNS is also the foundation of HTTPS, a confirmed ranking signal: your certificate can only be issued and trusted if your A/AAAA, CAA, and (ideally) DNSSEC records are in order. And clean email authentication (SPF/DKIM/DMARC in TXT records) keeps your transactional and marketing mail out of spam, which indirectly supports engagement. In short, solid DNS is table stakes for a professional, well-ranking site.

DNS Troubleshooting: A Diagnostic Checklist

When something DNS-related breaks, work through this list in order and you’ll find most problems quickly:

Confirm the record actually exists and is correct. Run the domain through the DNS Lookup and read the live value from the authoritative servers. Half of “DNS problems” are simply a typo or a record saved in the wrong place.
Check whether it has propagated. If you just made a change, the old value may still be cached. Use the DNS Propagation Checker to see whether the major resolvers have the new value yet, and recall the TTL governs how long the old one lingers.
Verify the name servers. Make sure the NS records (and the delegation at your registrar) point at the DNS host you’re actually editing. A classic mistake is editing records at one provider while the domain is delegated to another.
Flush your local caches. If it works on the propagation checker but not on your machine, your OS or browser is holding a stale answer — flush the DNS cache.
For email issues, re-check MX, SPF, DKIM and DMARC. A single missing or duplicated TXT record is enough to send mail to spam.
For HTTPS issues, confirm A/AAAA, CAA and DNSSEC. A certificate can’t be issued or trusted if these are wrong — the DNSSEC Checker catches a surprising number of “mystery” outages.

Choosing a DNS Provider

Not all DNS hosting is equal, and since DNS sits in front of everything, the choice matters more than people assume. Look for:

Speed and global reach — name servers on an anycast network answer from the location nearest each visitor, shaving milliseconds off every first connection.
Reliability — multiple, geographically diverse name servers (you’ll see several NS records) so a single outage doesn’t take you offline.
Security features — one-click DNSSEC, CAA support, and protection against DDoS attacks aimed at your DNS.
Modern record support — ALIAS/ANAME at the root, plus newer HTTPS/SVCB records.
A sane API and interface — so automation and bulk changes don’t become a chore.

Major providers like Cloudflare, Amazon Route 53, Google Cloud DNS, and premium offerings from registrars all tick these boxes. For a high-traffic or business-critical domain, the small cost of good DNS hosting pays for itself the first time it prevents an outage or speeds up your global audience.

DNS Record Cheat Sheet

Keep this quick reference handy — it captures the essence of every record in one place:

A — name → IPv4 address. The basic “where does this domain live” record.
AAAA — name → IPv6 address. The modern companion to A; publish both.
CNAME — name → another name (alias). Can’t coexist with other records or sit on the root.
MX — which mail servers receive email, by priority (lower first).
TXT — free text; home of SPF, DKIM, DMARC, and verification strings.
NS — the authoritative name servers for the zone.
SOA — the zone’s cover page: primary server, admin email, serial, timers.
CAA — which certificate authorities may issue your SSL certificates.
PTR — reverse: IP → name. Important for sending email.
SRV — host and port for a specific service (SIP, XMPP, etc.).
ALIAS/ANAME — a CNAME-like record that’s legal at the root.
HTTPS/SVCB — modern connection hints (HTTP/3, ports, ECH).
TTL — not a record, but the seconds every record may be cached. Lower it before planned changes.

Whenever a record isn’t behaving, your first move is always the same: open the DNS Lookup, read what the authoritative servers actually publish, and compare it to what you expect. Nine times out of ten the problem is visible in that one screen.

Frequently Asked Questions

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

An A record points a name directly at an IP address; a CNAME points a name at another name, which is then resolved to an IP. Use an A record for fixed IPs and a CNAME to follow a service whose IP may change.

How long do DNS changes take to propagate?

Anywhere from a few minutes to 48 hours, governed by the record’s TTL and the caches of resolvers worldwide. Lowering the TTL before a change makes propagation much faster. Track it live with the DNS Propagation Checker.

Why does my website show different IPs on different DNS checkers?

Large sites use geo-based load balancing and return different A records depending on the resolver’s location. That’s normal and not a propagation issue.

Can I have more than one MX record?

Yes — that’s recommended for redundancy. Lower priority numbers are tried first; equal priorities share the load.

Do I need a TXT record for my website to work?

Not for the site itself, but you’ll almost certainly need TXT records for email authentication (SPF, DKIM, DMARC) and for verifying ownership with services like Google and Microsoft.

Conclusion

DNS records look intimidating until you realise they all follow the same pattern and each one has a single, clear job: A and AAAA point at servers, CNAME aliases names, MX routes email, TXT carries verification and anti-spoofing policies, NS and SOA define the zone, and CAA protects your certificates. Master those and you can confidently move hosts, set up email, pass domain verifications, and debug outages without guesswork.

The fastest way to learn is to look at real domains. Open the DNS Lookup, run a few sites you know, and compare their records. Then, whenever you make a change, confirm it with the DNS Propagation Checker and harden the domain with the DNSSEC Checker. DNS stops being scary the moment you can see exactly what it’s doing.

Written by PAYATE Team

The PAYATE team builds free tools for merchants and developers.