I'll write this post directly. DNS is a topic where the kief.dev DNS Lookup tool is a natural fit, and the research has strong material.

DNS Lookup Deep Dive: What Every Record Type Actually Means

You set up DNS once, mass-pasted some records your hosting provider told you to add, and never looked again. That was fine in 2020.

It's not fine now. 17% of all emails fail to reach recipients because of DNS misconfigurations. Google and Microsoft permanently reject non-compliant bulk mail at the SMTP level -- no bounce, no warning, just gone. And researchers found 8,000 legitimate domains hijacked through dangling DNS records nobody bothered to clean up.

DNS isn't just "the thing that points your domain at a server." It's the trust layer that decides whether your emails arrive, whether someone else can impersonate you, and whether your TLS cert is legit. Every record type exists for a reason. Here's what they actually do, what breaks when they're wrong, and what you should check on your own domains right now.

A Records and AAAA Records: Where Things Live

The simplest records. An A record maps a domain to an IPv4 address. AAAA does the same for IPv6.

example.com.    A       93.184.216.34
example.com.    AAAA    2606:2800:220:1:248:1893:25c8:1946

When these are wrong, your site is down. Pretty obvious. The less obvious failure: you migrate servers, update your A record, but forget about the AAAA. Half your traffic goes to the old box -- or worse, an IP someone else now owns.

Check both. Always.

CNAME Records: The Most Misunderstood Record Type

A CNAME (Canonical Name) aliases one name to another. It's not a redirect. It's a "go look over there instead" instruction to the resolver.

blog.example.com.    CNAME    example.ghost.io.

Simple enough. But CNAME has hard constraints that trip people up constantly:

It cannot exist at the zone apex. You can't CNAME example.com itself -- only subdomains. This is per RFC 1034. The reason: CNAME means "this name has no other records," but the apex always has SOA and NS records. Every "why doesn't my root domain work with Netlify/Vercel/CloudFront?" support ticket traces back to this.

It can't coexist with other records at the same name. If blog.example.com has a CNAME, you can't also put an MX or TXT record there. The CNAME wins and everything else is invalid.

Dangling CNAMEs are a takeover vector. You pointed staging.example.com at an Azure App Service, then deleted the Azure resource. The CNAME still exists. An attacker creates a new Azure resource, claims that hostname, and now they control your subdomain. Azure alone generates roughly 15,000 takeover-vulnerable subdomains per month from this pattern. Government subdomains in the US, UK, Canada, and Australia have been taken over by researchers demonstrating this exact attack.

# Check for dangling CNAMEs -- if the target doesn't resolve, you have a problem
dig +short CNAME staging.example.com
# returns: myapp-old.azurewebsites.net
dig +short A myapp-old.azurewebsites.net
# returns: nothing -- this is a takeover risk

Most DNS providers now offer ALIAS or ANAME pseudo-records to solve the apex limitation. Cloudflare calls it "CNAME flattening." Use it if you need apex aliasing.

MX Records: Where Your Email Goes

MX (Mail Exchange) records tell other mail servers where to deliver email for your domain.

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

The number is priority -- lower wins. If mail1 is down, delivery falls back to mail2. The target must be an A/AAAA record, never a CNAME (RFC 2181). Some servers will follow the CNAME anyway. Some won't. Don't rely on undefined behavior.

The most common MX mistake: migrating email providers and leaving the old MX records alongside the new ones. Now some of your mail routes to a server you no longer control.

TXT Records: The Junk Drawer of DNS

TXT records hold arbitrary text. They were originally meant for human-readable notes. Now they're the backbone of email authentication and domain verification for half the SaaS industry.

Here's a typical domain's TXT records:

example.com.  TXT  "v=spf1 include:_spf.google.com include:mailchimp.com ~all"
example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
example.com.  TXT  "google-site-verification=abc123..."
example.com.  TXT  "facebook-domain-verification=xyz789..."
example.com.  TXT  "atlassian-domain-verification=..."
example.com.  TXT  "adobe-idp-site-verification=..."
example.com.  TXT  "MS=ms12345678"

See the problem? Every SaaS vendor demands a root-domain TXT record for "verification." Google, Microsoft, Facebook, Adobe, Atlassian, HubSpot -- they all pile on. Most orgs never remove these after initial setup.

The result: TXT record bloat. DNS responses have a traditional 512-byte UDP limit. Domains with 10-15 TXT records can exceed this, causing truncation, TCP fallback, and outright verification failures. Atlassian has a known issue (ACCESS-680) where domain verification fails because the DNS response is too large for their resolver to handle.

The fix nobody uses: CNAME-based verification on unique subdomains. Instead of adding yet another TXT record to the root, you create _atlassian.example.com CNAME .... Keeps the root clean. Not enough vendors offer this option.

SPF: The 10-Lookup Trap

SPF (Sender Policy Framework) lives in a TXT record and declares which servers can send email for your domain.

v=spf1 include:_spf.google.com include:servers.mcsv.net include:spf.protection.outlook.com ~all

Every include: triggers a DNS lookup. Each included domain can itself include others. The spec (RFC 7208) hard-limits this to 10 DNS lookups total. Hit 11 and SPF fails entirely. Not "degrades gracefully." Fails. Your email stops authenticating and you get no notification.

This is the #1 DNS misconfiguration that bites growing businesses. You add Google Workspace (2-3 lookups), then Mailchimp (1), then HubSpot (2), then Zendesk (2), then Microsoft 365 (2-3). You're at the limit before you know it.

# Count your SPF lookups
dig +short TXT example.com | grep spf
# Then recursively check each include -- or just use a tool

You can check this instantly with the kief.dev DNS Lookup tool -- punch in your domain and look at the TXT records. Count the include: directives and any a: or mx: mechanisms. If you're close to 10, you need SPF flattening (replacing include: with the actual IP ranges) or a service like _spf.example.com that consolidates them.

DKIM: Proving You Sent It

DKIM (DomainKeys Identified Mail) uses a TXT record at a selector subdomain to publish a public key. Your mail server signs outgoing messages with the private key. Recipients verify the signature against DNS.

selector1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCS..."

The selector name varies by provider. Google uses google._domainkey. Microsoft uses selector1._domainkey and selector2._domainkey. Each sending service needs its own DKIM record.

When DKIM is missing or misconfigured, your email still sends -- but it fails authentication checks that Gmail and Microsoft now enforce. Combined with no DMARC, this means your legitimate email lands in spam while anyone can forge email from your domain.

DMARC: The Policy Layer

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a TXT record at _dmarc.example.com that tells receiving servers what to do when SPF and DKIM both fail.

_dmarc.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

Three policy levels: - p=none -- monitor only, deliver everything (useful during rollout) - p=quarantine -- failed mail goes to spam - p=reject -- failed mail is dropped

Only 16% of domains have DMARC deployed. The other 84% are wide open to spoofing. Since November 2025, Gmail permanently rejects non-compliant bulk mail (550 errors, no retry). Microsoft followed in May 2025. If you send more than 5,000 emails per day across all subdomains and you don't have SPF + DKIM + DMARC, your mail is getting dropped.

p=none is not a long-term answer. It's a monitoring phase. Set rua= to get aggregate reports, fix your authentication, then move to p=reject.

CAA Records: Controlling Who Issues Your Certs

CAA (Certificate Authority Authorization) records specify which CAs are allowed to issue certificates for your domain.

example.com.  CAA  0 issue "letsencrypt.org"
example.com.  CAA  0 issuewild "letsencrypt.org"
example.com.  CAA  0 iodef "mailto:security@example.com"

CAs have been required to check CAA records before issuance since 2017. But only ~15% of top websites actually set them. Without CAA, any CA on Earth can issue a cert for your domain. If an attacker compromises a single CA's domain validation (say, via BGP hijacking), they get a valid cert for your site.

Starting February 2026, CAs must perform multi-perspective CAA checks from 3+ geographically distributed locations across 2+ Regional Internet Registries. This counters BGP-based attacks but only matters if you've set CAA records in the first place.

With cert max validity dropping to 6 months in 2026 and eventually 47 days by 2029, your DNS automation around certificate issuance becomes critical. Set your CAA records now.

NS Records: The Chain of Authority

NS (Name Server) records delegate authority for a zone. They're the foundation everything else depends on.

example.com.  NS  ns1.cloudflare.com.
example.com.  NS  ns2.cloudflare.com.

You rarely touch these after initial setup, but when they're wrong, everything is wrong. The most dangerous failure: you switch DNS providers but forget to update the NS records at your registrar. Your domain resolves against stale nameservers, and every other record is ignored.

Never point NS records at a CNAME. Some resolvers (especially BIND) will refuse to resolve the entire zone.

SRV and Other Records Worth Knowing

SRV records define the host and port for specific services. Microsoft 365, XMPP, SIP, and other protocols use them for service discovery.

_sip._tcp.example.com.  SRV  10 60 5060 sipserver.example.com.

PTR records are reverse DNS -- mapping an IP back to a hostname. Mail servers check PTR records as an anti-spam signal. If your mail server's IP doesn't have a matching PTR record, expect deliverability problems.

SOA records define the authoritative nameserver for a zone and control caching behavior. You rarely edit these directly, but the serial number must increment on every zone change or secondary nameservers won't pick up updates.

What to Do Right Now

Run your domain through the kief.dev DNS Lookup. Then check these:

Do you have DMARC? Query _dmarc.yourdomain.com. If it's empty, you're in the 84%.
Count your SPF lookups. If you're at 8+, start planning SPF flattening.
Look for orphaned CNAMEs. Any CNAME pointing at a service you cancelled is a takeover waiting to happen.
Set CAA records. Restrict cert issuance to the CA you actually use.
Audit your TXT records. If you can't identify what each one is for, it's probably stale.

While you're checking DNS, run your domain through the kief.dev SSL Checker and Security Headers too. DNS is one layer -- your transport and response headers are the others.

DNS isn't set-and-forget infrastructure. It's your domain's source of truth for identity, authentication, and trust. Treat it like code: audit it, version it, and clean up what you're not using.

meta_title: "DNS Record Types Explained: What Each One Actually Does"
meta_description: "A practical guide to DNS record types -- A, CNAME, MX, SPF, DKIM, DMARC, CAA, and more. What breaks when they're wrong and what to check now."
tags: ["dns", "email-security", "infrastructure", "developer-tools"]