The DNS Records That Actually Matter

Every time I get access to a client's DNS zone, I see the same pattern. There are records from services tried once and never removed. There's an SPF record pointing to a mail provider they ditched two years ago. And usually, a record that actually matters is missing or misconfigured, quietly causing problems.

DNS zones accumulate cruft because removing a record feels riskier than leaving it, even when nobody knows what it does. Here is the short list I actually check, in the order I check it.

A and AAAA: The basics

The A record (IPv4) is rarely missing. But AAAA (IPv6) is often either absent or, much worse, pointing at an IPv6 address that no longer exists. A stale AAAA record means dual-stack clients will try IPv6 first, fail, and then fall back to IPv4, adding a massive delay to every connection.

If you are not actively running IPv6 on your server, it is better to have no AAAA record at all than a broken one.

MX and the mail-related TXT records

If the domain sends or receives mail, MX records point to the mail server. SPF, DKIM, and DMARC (all TXT records) govern whether mail sent from that domain is trusted.

I've written about setting these up properly before, but the check here is simpler: do these records still describe reality? An SPF record listing a legacy mail provider isn't just useless cruft—it can actively cause legitimate mail from the current provider to fail SPF alignment and land in spam.

NS records: Do they match the registrar?

It sounds basic, but always confirm that the NS records returned by the zone match what the domain registrar has configured.

A mismatch usually happens during a DNS provider migration that wasn't fully completed. It means some resolvers see the old provider's records and some see the new one, depending on caching. This produces exactly the kind of "it works for me but not for them" issue that takes hours to debug if you don't check this first.

dig NS example.com
whois example.com | grep -i "name server"

CAA: The easy one that's always missing

CAA (Certification Authority Authorization) records specify exactly which certificate authorities are allowed to issue SSL certificates for your domain. Almost nobody sets this.

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

It doesn't prevent every attack, but it completely closes off a category of misissuance from CAs you've never used. It costs you one record that only needs updating if you change CAs. It's low effort, genuinely useful, and signals that whoever set up the zone knew what they were doing.

TTL: Low for changes, high for stability

This isn't a record type, but it trips people up constantly. A low TTL (e.g., 300 seconds) during a migration means changes propagate quickly if you need to roll back.

Once things are stable, a higher TTL (a few hours to a day) reduces query load on your DNS provider and slightly speeds up resolution for end users, since their local resolvers cache the answer longer. The mistake I see most often is a permanently low TTL left over from a migration that finished months ago. It's harmless, but it's a clear sign nobody went back to clean up after the dust settled.

The habit worth building

None of these records are exotic, and checking them requires nothing beyond dig and five minutes. The real value is in treating a DNS zone as something that must reflect current reality—not an archaeological dig site of every service that ever touched the domain.

When I finish a project that involves DNS, removing the now-unused records takes thirty seconds. It saves the next person (often me) from wondering, six months later, whether that mysterious TXT record is safe to delete.