The internet runs on a sprawling mesh of infrastructure that’s invisible to most of us. Under the hood it’s wildly complex, but at the application layer it’s been tamed so anyone can use it with a browser and a few clicks.

A core piece of that foundation is the domain name system (DNS) and its DNS records. These records tell browsers and apps where to go and how to connect—linking a website’s human-readable domain name to its machine-readable IP address and guiding email, verification, security, and more.

In this guide, you’ll learn what DNS records are, why they matter, and how each common record type works—plus quick ways to look them up when you’re troubleshooting.

What Is DNS?

To understand DNS records, it helps to see the bigger picture of DNS itself—a distributed, hierarchical database that translates domains into IP addresses.

In simple terms, DNS directs traffic on the internet by matching domain names to IP addresses. When you type a domain into your browser, a recursive resolver asks the root, then the top-level domain (TLD) servers (like .com), then the authoritative nameserver for the domain to find the right answer. Records such as A and AAAA ensure you don’t have to memorize a string of numbers to visit a site.

Instead, you enter the domain name and DNS points you to the correct hosting server. Caching along the way (controlled by each record’s TTL, or time to live) keeps lookups fast and reduces needless traffic.

Just like a mailing address helps you find a building, DNS converts domain names into IP addresses and uses DNS records to resolve the name to the right server.

Beyond choosing a website builder, understanding DNS records is handy when you’re managing domains—like when you transfer a domain name, move hosts, set up email, or verify site ownership.

DNS Records and Why They Are Important

DNS records store information about a domain (IP addresses, aliases, mail routing, verification data, and more), plus instructions for resolvers on how to answer queries. You’ll also hear them called resource records (RR) because they hold the “resources” that map names to addresses and services.

These records—often represented in plain-text zone files—live on authoritative nameservers (DNS servers). An authoritative nameserver is the source of truth for a domain and tells clients which web or mail server to reach. Together, DNS records and authoritative servers enable fast, accurate lookups.

Domain registrars and third-party DNS providers host and update these records on your nameservers.

Types of DNS Records

The primary job of DNS records is to map a human-readable hostname (like quicksprout.com) to an IP address (like 141.193.213.11). That’s what an A record does. You’ll also see other record types—AAAA, CNAME, MX, TXT, NS, SOA, and security-focused records (like CAA, DNSKEY, DS, and TLSA). Newer types such as HTTPS/SVCB are increasingly common for performance and modern protocols. Managing TTLs on these records helps control propagation and caching.

How to access DNS records

Every time you visit a site, DNS lookups are happening behind the scenes. Type quicksprout.com in your browser and the resolver fetches the IP address from the domain’s authoritative nameserver based on its DNS records.

Public tools make this visible. You can find the IP address of a website with services like the Google Dig tool. Results often include the answering nameserver, record type, data, and TTL.

A record

The most fundamental DNS record—an address record—points a domain or subdomain to an IPv4 address. An A record tells the world which web server hosts your site. You can use multiple A records for the same name to provide basic load distribution or failover.

A records are also handy when you temporarily override DNS on your own machine via the local hosts file—useful during migrations or when configuring software that depends on a working domain.

Note that A records point only to IPv4 addresses. If you also serve the site over IPv6, you’ll publish an AAAA record alongside the A record. Keep TTLs sensible so changes propagate quickly when you switch servers.

When you query an A record in Google Dig, you’ll see the hostname’s IPv4 mapping and related metadata in the answer.

Toggle the Raw view to see a more verbose response—authority and additional sections, TTLs, and the nameserver that answered.

You can also query A records from the command line using nslookup or dig +short A.

AAAA record

Similar to an A record, an AAAA record points a hostname to an IPv6 address. Many sites now operate in dual-stack mode, publishing both A (IPv4) and AAAA (IPv6) so clients can connect over either protocol.

In tools like Google Dig, IPv6 addresses are longer and use colons between fields, unlike IPv4’s dotted quads.

Because unique IPv4 space is limited, IPv6 massively expands the address pool and supports modern networking at scale.

CNAME record

A CNAME (canonical name) record makes one hostname an alias of another. Instead of pointing to an IP, it points to another domain name.

Commonly, www.example.com is a CNAME to example.com, or a subdomain like blog.example.com is a CNAME to a hosted service.

This reduces maintenance. Change the target once (the root domain’s A/AAAA record or the service endpoint) and every alias follows automatically.

Important: standard DNS doesn’t allow a CNAME at the zone apex (the bare domain). If you want “apex-style” behavior, use your provider’s ALIAS/ANAME or CNAME-flattening feature instead.

As a real-world example, a blog such as blog.hubspot.com may have a CNAME target like 53.group3.sites.hubspot.net, letting the vendor manage IPs behind the scenes.

By using CNAMEs for subdomains, you can run multiple services behind one IP (or a changing set of IPs) without editing many records.

MX record

MX (mail exchange) records direct email for a domain to the correct mail servers. Each MX record points to a hostname (not an IP) and includes a priority (lower preference number = higher priority).

For example, you might route mail for example.com to a provider’s servers. Multiple MX records provide redundancy—mail will try the lowest-numbered preference first, then fall back to others.

Querying the MX record for a domain in Google Dig returns the mail hostnames and their preferences, which SMTP servers use to deliver mail.

TXT record

TXT records store free-form text. They’re widely used for domain verification (ownership checks), configuration, and—critically—email security frameworks such as SPF, DKIM, and DMARC.

For SPF, a TXT record lists the servers allowed to send mail for your domain; receivers check this to spot spoofing. DKIM publishes a public key so recipients can verify a message’s signature. DMARC (also via TXT) tells receivers how to handle authentication failures and where to send reports.

TXT records also carry service tokens (like Google site verification) and other metadata. Note: the legacy SPF record type exists but best practice is to publish SPF as TXT.

Together, these records make life harder for spammers and provide visibility into abuse attempts via DMARC aggregate and forensic reports.

SRV record

SRV records specify the hostname and port for particular services, not just an IP. They’re common for SIP/VoIP, XMPP, LDAP, and some Microsoft and gaming services.

Protocols that rely on SRV (like XMPP) won’t work correctly without them. An SRV record includes a priority and a weight so admins can route traffic to preferred or more capable servers.

Priority is evaluated first (lower value is tried before higher). When priorities match, weight distributes load among equals—the higher the weight, the more traffic a server receives.

For example, if servers A, B, and C have priorities 100, 200, and 300, resolver traffic will always try A first regardless of weight values.

NS record

NS (nameserver) records indicate which nameservers are authoritative for a domain. Domains typically list at least two—primary and secondary—for resilience.

Authoritative nameservers host the actual DNS records for your domain. NS records point to those nameservers by name; registries may also publish “glue” A/AAAA records so resolvers know the nameservers’ IPs.

In short, NS records tell the DNS system where to find your domain’s zone data so lookups can be answered correctly.

SOA record

SOA (start of authority) holds administrative details for a DNS zone. It lists the primary nameserver (MNAME), the responsible party’s email (RNAME), a serial number, and timers for refresh, retry, expire, and minimum TTL.

The serial number typically increments on each change (some admins use a date-based format). Resolvers use the timers to decide how frequently to check for updates and how long to cache negative answers.

SOA data is also used during zone transfers to ensure secondaries are in sync with the primary.

PTR record

A PTR (pointer) record enables reverse lookups—given an IP address, it returns the associated hostname. Think of it as the inverse of an A record.

Reverse DNS lives under special zones (in-addr.arpa for IPv4 and ip6.arpa for IPv6). PTRs are important for email reputation; many receiving servers expect the sending IP to have a matching reverse DNS entry that aligns with its HELO/EHLO.

TSIG record

TSIG (transaction signature) secures DNS messages—most notably dynamic updates and zone transfers—using shared secrets and one-way hashing to authenticate that a message came from an authorized sender.

TSIG isn’t a typical public record you publish in your zone; it’s applied to DNS transactions between servers to prevent tampering and spoofing.

CAA records

CAA (Certificate Authority Authorization) records specify which certificate authorities are allowed to issue SSL/TLS certificates for your domain or subdomains. Major CAs check CAA before issuance to reduce mis-issuance risk.

As a domain owner, publish CAA to allow specific CAs and optionally add an iodef parameter so CAs can report policy violations.

TLSA records

TLSA (Transport Layer Security Authentication), used by DANE, strengthens security by specifying which keys or certificates are valid for a service. It’s most commonly deployed for SMTP over TLS.

TLSA requires DNSSEC to be enabled so resolvers can trust the published keys. Each TLSA record includes a usage, selector, and matching type—plus the port, protocol, and hostname of the service.

In practice, this lets administrators pin expected keys at the DNS layer, reducing the impact of compromised or mis-issued certificates.

DS records

A DS (delegation signer) record secures a child zone’s delegation in DNSSEC. It lives at the parent zone and contains a hash of the child’s DNSKEY, creating a chain of trust from parent to child.

With DNSSEC and DS in place, attackers can’t easily poison or manipulate responses because resolvers can cryptographically verify that answers are authentic.

DNSKEY records

DNSKEY publishes a zone’s public keys so resolvers can verify DNSSEC signatures. Zones often use separate keys: a key-signing key (KSK) and a zone-signing key (ZSK).

DNS Records: Quick Summary & Next Steps

DNS is the address book of the internet. Records live on authoritative nameservers and tell browsers, apps, and mail servers how to reach your services. Keep TTLs reasonable, use the right record for each job, and verify changes with lookup tools before and after you go live.

• A: Points a name to an IPv4 address.
• AAAA: Points a name to an IPv6 address (often used alongside A for dual-stack).
• CNAME: Aliases one hostname to another (not allowed at the zone apex without a provider feature like ALIAS/ANAME).
• MX: Routes email to mail servers by priority (lower number = higher priority).
• TXT: Stores free-form text for verification and email authentication (SPF, DKIM, DMARC).
• SRV: Publishes hostname and port for services (uses priority and weight for traffic distribution).
• NS: Lists the authoritative nameservers for your domain.
• SOA: Zone metadata (primary server, admin contact, serial, timers) used for synchronization and caching behavior.
• PTR: Reverse DNS—maps an IP back to a hostname (important for mail deliverability).
• CAA: Limits which certificate authorities can issue TLS certificates for your domain.
• DNSKEY & DS: Publish keys and parent-side signatures for DNSSEC, creating a chain of trust.
• TLSA: DANE records that pin keys/certs for a service (requires DNSSEC).

Troubleshooting & Best Practices

• Plan TTLs: Use lower TTLs before migrations; raise them when stable to improve caching.
• Check propagation: Verify updates with tools like dig/nslookup (answer section, TTL, authoritative server).
• Apex caution: Don’t place a standard CNAME at the root; use ALIAS/ANAME/CNAME-flattening if needed.
• Email hardening: Publish SPF (TXT), DKIM (TXT with selector), and DMARC (TXT); ensure PTR matches sending host.
• Redundancy: Keep multiple MX and NS records where appropriate; ensure they point to working hosts.
• Avoid conflicts: Don’t mix A/AAAA and CNAME on the same name; remove stale records after changes.
• Secure issuance: Add CAA with an iodef email/URL to be alerted to certificate policy violations.
• Consider DNSSEC: Enable DNSSEC (DNSKEY/DS) for authenticity; add TLSA for SMTP-over-TLS if your provider supports DANE.
• Document changes: Track who changed what and when (serials, TTL adjustments, and intended outcomes).

Mastering these records makes common tasks—site moves, email setup, third-party integrations, and security hardening—faster and less error-prone. Use the right record, verify the result, and your users (and inboxes) will thank you.