An A record maps a hostname to an IPv4 address, which is how a browser turns a domain such as example.com into the numeric address it actually connects to. A single name can have several A records for load spreading, and its close cousin the AAAA record does the same job for IPv6 addresses.

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

An A record points a name directly at an IP address, while a CNAME points a name at another name that is then resolved to find the address. Use a CNAME when you want an alias that should always follow wherever the target moves, such as pointing www at your root domain. A CNAME cannot coexist with other records on the same name and is not allowed at the zone apex, which is why some providers offer ALIAS or ANAME records there instead.

What is an MX record?

An MX record lists the mail servers that accept email for a domain. Each entry has a priority number, and sending servers try the lowest number first, falling back to higher numbers if it is unreachable. MX records point at hostnames, not IP addresses, so each target still needs its own A or AAAA record.

TTL, or time to live, is a value in seconds attached to every record that tells resolvers how long they may cache the answer before asking again. A low TTL such as 300 makes changes propagate quickly but increases lookups, while a high TTL such as 86400 reduces traffic but means edits take longer to take effect. Lowering the TTL a day before a planned change is a common way to make a cutover smooth.

How do SPF, DKIM, and DMARC work together?

All three are published as TXT records and act as layers of email authentication. SPF lists which servers may send mail for the domain, DKIM adds a cryptographic signature that a matching public key in DNS can verify, and DMARC at _dmarc ties the two together by telling receivers what to do when a message fails and where to send reports. Together they make it much harder to forge mail from your domain.

What is a DNSSEC record such as DNSKEY or DS?

DNSSEC adds cryptographic signatures to DNS so answers can be verified as authentic. A DNSKEY record holds the public key for a zone, RRSIG records carry the signatures, and a DS record in the parent zone is a hash of the child key that links the two into a chain of trust. Resolvers that validate DNSSEC use this chain to reject forged or tampered answers.

Does this tool send the records I search to a server?

No. The full list of record types is embedded in the page, and all filtering happens in your browser with JavaScript. You can confirm this by opening DevTools and watching the Network tab: typing in the search box makes zero requests.

DNS Records Reference

Every common DNS record type, searchable. Filter by category and see what each record does.

Filter

DNS record types with their category and purpose
Record	Purpose
`A` common	Maps a hostname to an IPv4 address. Example: A example.com -> 93.184.216.34
`AAAA` common	Maps a hostname to an IPv6 address. Example: AAAA example.com -> 2606:2800:220:1:248:1893:25c8:1946
`CNAME` common	Aliases one name to another canonical name, which is then resolved to find the address. Example: CNAME www.example.com -> example.com
`NS` common	Delegates a zone to its authoritative nameservers. Example: NS example.com -> ns1.example.com
`SOA` common	Start of authority; one per zone, holding the primary nameserver, contact, serial number, and refresh timers.
`TTL` common	Time to live, a field on every record; the seconds a resolver may cache it before fetching again. Example: 3600 = 1 hour
`HTTPS` common	Service binding for HTTPS (type 65); points clients at endpoints and can supply ALPN, port, and HTTP/3 hints before connecting.
`DNAME` common	Redirects an entire subtree of names to another subtree, like a CNAME applied to everything under a name.
`MX` email	Names the mail servers that accept email for the domain, each with a priority; the lowest number is tried first. Example: MX 10 mail.example.com
`TXT` email	Holds arbitrary text, widely reused for domain verification and email policy. Example: TXT "google-site-verification=abc123"
`SPF` email	Published as a TXT record listing which servers may send mail for the domain. Example: v=spf1 include:_spf.google.com -all
`DKIM` email	Published as a TXT record at selector._domainkey; holds the public key that verifies a signature added to outgoing mail.
`DMARC` email	Published as a TXT record at _dmarc; sets policy for mail that fails SPF or DKIM. Example: v=DMARC1; p=reject; rua=mailto:reports@example.com
`MTA-STS` email	Published as a TXT record at _mta-sts plus a policy file; tells sending servers to require TLS for SMTP delivery.
`BIMI` email	Published as a TXT record at default._bimi; points to a brand logo shown by supporting mail clients once DMARC passes.
`CAA` security	Restricts which certificate authorities may issue certificates for the domain. Example: CAA 0 issue "letsencrypt.org"
`DNSKEY` security	Holds the public key that DNSSEC resolvers use to verify signatures in the zone.
`DS` security	Delegation signer; a hash of a child DNSKEY placed in the parent zone to extend the DNSSEC chain of trust.
`TLSA` security	Binds a TLS certificate or public key to a name for DANE. Name: _443._tcp.example.com
`RRSIG` security	A DNSSEC signature over a record set, proving the records are authentic and unmodified.
`NSEC` security	Provides authenticated denial in DNSSEC by proving that a given name or record type does not exist.
`NSEC3` security	Like NSEC but uses hashed names to make zone enumeration harder.
`SSHFP` security	Publishes SSH host key fingerprints so clients can verify a server key through DNS.
`CDS` security	A child-side copy of the DS record that lets a child zone signal key changes to its parent automatically; CDNSKEY does the same for DNSKEY.
`SRV` other	Locates a service by protocol, carrying priority, weight, port, and target host. Name: _sip._tcp.example.com; Example: SRV 10 60 5060 sip.example.com
`PTR` other	Reverse DNS; maps an IP address back to a hostname under in-addr.arpa or ip6.arpa. Example: PTR 8.8.8.8 -> dns.google
`ALIAS / ANAME` other	A provider-specific record that flattens a CNAME-like target at the zone apex, where a plain CNAME is not allowed.
`Wildcard (*)` other	A record whose name begins with * that answers for any subdomain not defined explicitly. Example: *.example.com -> 93.184.216.34
`NAPTR` other	Naming authority pointer; applies rewrite rules used in ENUM phone-number lookups and SIP service discovery.
`SVCB` other	General service binding record (type 64) that advertises how to reach a service; HTTPS is the HTTP-specific form.
`URI` other	Maps a name to a target URI, with priority and weight fields like SRV. Example: URI 10 1 "https://example.com/"
`LOC` other	Stores a geographic location for a name as latitude, longitude, and altitude.
`CERT` other	Stores a certificate or related certificate data directly in DNS.

Runs entirely in your browser. Nothing you type is sent anywhere; open DevTools and watch the Network tab to verify zero requests.

What this tool does

This is a searchable reference for the DNS record types you meet when you set up a domain. Every entry lists the record name, a category badge (common, email, security, or other), and a one-sentence plain-English purpose, often with a short example value. Type in the filter box to narrow the table by record name or by any word in the purpose, or tap a category button to show just one family. The whole dataset is baked into the page, so it works offline and sends nothing anywhere.

How to use it

Start typing in the Filter box. Entering MX jumps to the mail exchanger record; entering reverse surfaces PTR; entering DNSSEC pulls up the signing records. The category buttons (All, Common, Email, Security, Other) combine with the text filter, so you can, for example, pick Email and type txt to see just the TXT-based policy records. Clear the box to see every record again. Nothing is submitted and there is no result limit.

Common use cases

Deciding which record to create when pointing a new domain or subdomain somewhere.
Setting up email authentication by comparing MX, SPF, DKIM, and DMARC side by side.
Reading an existing zone file or DNS provider dashboard and understanding each line.
Learning the DNSSEC records (DNSKEY, DS, RRSIG, NSEC) and how they chain together.
Looking up reverse DNS, service discovery, or certificate-related records like PTR, SRV, TLSA, and CAA.

Common pitfalls

A CNAME cannot sit at the zone apex. The root of a domain needs an A or AAAA record, not a CNAME. To alias the apex, use a provider ALIAS or ANAME record, which flattens the target into address records behind the scenes.
MX records point at names, not IPs. An MX target must be a hostname that itself has an A or AAAA record. Pointing an MX straight at an IP address, or at a CNAME, is invalid and breaks mail delivery.
Only one SPF policy per domain. SPF lives in a TXT record, and publishing two separate spf1 records is a permanent error. Keep a single record and stay within the limit of ten DNS lookups it may trigger.
DNSSEC breaks if the DS is wrong. The DS record lives in the parent zone and must match your published DNSKEY. A stale or missing DS after a key change makes validating resolvers reject the whole domain, not just one record.

Frequently asked questions

What is an A record?: An A record maps a hostname to an IPv4 address, which is how a browser turns a domain such as example.com into the numeric address it actually connects to. A single name can have several A records for load spreading, and its close cousin the AAAA record does the same job for IPv6 addresses.
What is the difference between an A record and a CNAME?: An A record points a name directly at an IP address, while a CNAME points a name at another name that is then resolved to find the address. Use a CNAME when you want an alias that should always follow wherever the target moves, such as pointing www at your root domain. A CNAME cannot coexist with other records on the same name and is not allowed at the zone apex, which is why some providers offer ALIAS or ANAME records there instead.
What is an MX record?: An MX record lists the mail servers that accept email for a domain. Each entry has a priority number, and sending servers try the lowest number first, falling back to higher numbers if it is unreachable. MX records point at hostnames, not IP addresses, so each target still needs its own A or AAAA record.
What is TTL in DNS?: TTL, or time to live, is a value in seconds attached to every record that tells resolvers how long they may cache the answer before asking again. A low TTL such as 300 makes changes propagate quickly but increases lookups, while a high TTL such as 86400 reduces traffic but means edits take longer to take effect. Lowering the TTL a day before a planned change is a common way to make a cutover smooth.
How do SPF, DKIM, and DMARC work together?: All three are published as TXT records and act as layers of email authentication. SPF lists which servers may send mail for the domain, DKIM adds a cryptographic signature that a matching public key in DNS can verify, and DMARC at _dmarc ties the two together by telling receivers what to do when a message fails and where to send reports. Together they make it much harder to forge mail from your domain.
What is a DNSSEC record such as DNSKEY or DS?: DNSSEC adds cryptographic signatures to DNS so answers can be verified as authentic. A DNSKEY record holds the public key for a zone, RRSIG records carry the signatures, and a DS record in the parent zone is a hash of the child key that links the two into a chain of trust. Resolvers that validate DNSSEC use this chain to reject forged or tampered answers.
Does this tool send the records I search to a server?: No. The full list of record types is embedded in the page, and all filtering happens in your browser with JavaScript. You can confirm this by opening DevTools and watching the Network tab: typing in the search box makes zero requests.

Embed this tool

Free for any use; attribution appreciated. Paste this on your site:

<iframe
  src="https://glunty.com/dns-records?embed=1"
  width="100%"
  height="600"
  style="border:1px solid #e5e5e5;border-radius:6px;max-width:100%;"
  title="DNS Records Reference (via glunty.com)"
  loading="lazy"
  referrerpolicy="strict-origin-when-cross-origin"
></iframe>

The embed runs the same tool that lives at this URL. No tracking; no ads inside the embed. Resize height as needed for your layout.

Cite this tool

For academic, journalistic, or technical references. Pick a format:

https://glunty.com/dns-records

Citations use 2026 as the publication year. Access date is left as a fillable placeholder where the citation style expects one.

Embedded tool from glunty.com