I audit networks for a living. DNS configuration errors are in every single engagement — not occasionally, not mostly, but in every single one. The mistakes aren't exotic. They're the same 10 problems, over and over, across startups and mid-sized companies alike.

Developers own DNS more than they realize. You set up the subdomain for your staging environment, you configure SPF when the marketing team complains about email deliverability, you manage the certificate workflow. You are doing DNS work. Most of it is probably misconfigured.

Here's what I keep finding, and how to check yourself.

1. No DNSSEC

DNSSEC signs your DNS records so resolvers can verify they haven't been tampered with. Without it, a cache poisoning attack can redirect your users to an attacker-controlled server and there's nothing in the DNS layer to detect it.

# Check if DNSSEC is enabled for a domain
dig +dnssec example.com A

# Look for the AD flag in the response header — "ad" means authenticated data
# Also check the RRSIG records in the answer section
dig @8.8.8.8 example.com DNSKEY +short

If you get no RRSIG records, DNSSEC isn't configured. Most registrars support it now. It takes 30 minutes to set up and you do it once.

2. SPF with +all (or no SPF at all)

SPF records specify which servers are allowed to send email for your domain. +all means "and also anyone else" — which defeats the entire purpose.

# Check your SPF record
dig TXT yourdomain.com | grep spf

# Red flags:
# v=spf1 +all              ← allows everyone
# v=spf1 include:sendgrid.net +all  ← same problem
# (no result)              ← no SPF at all

The correct terminator is -all (fail) or ~all (softfail, useful during migration). +all is worse than no SPF because it creates a false sense of protection.

3. SPF with too many DNS lookups

SPF has a hard limit of 10 DNS lookups during evaluation. Each include: costs one lookup, and some includes contain nested includes. Exceed 10 and the record is considered invalid — meaning SPF fails for your legitimate emails.

# Count your lookups manually or use an online SPF checker
# Each "include:", "a:", "mx:", "ptr:", "exists:" costs one lookup
dig TXT yourdomain.com | grep spf
# Then recursively check each include's lookups

The fix is to flatten your SPF record — enumerate the IP ranges directly instead of chaining includes. It's tedious but necessary if you use multiple email services.

4. DMARC is missing or set to p=none

DMARC ties SPF and DKIM together and tells receiving mail servers what to do when checks fail. Without it, your SPF and DKIM records are advisory at best.

p=none is the monitoring policy — it collects reports but takes no action. It's appropriate for initial deployment, not for production. If your DMARC is still p=none a year after you set it up, you set it and forgot it.

Target is p=reject. Most organizations that haven't thought about it are at p=none or have no DMARC at all.

5. No CAA records

CAA (Certification Authority Authorization) records specify which certificate authorities are allowed to issue certificates for your domain. Without them, any CA can issue a certificate — and there have been several cases of CAs issuing fraudulent certificates for domains they shouldn't have.

dig CAA yourdomain.com
# If empty, any CA can issue certs for your domain
# Correct example: yourdomain.com. CAA 0 issue "letsencrypt.org"

If you use Let's Encrypt exclusively, your CAA record should say so. This is a five-minute fix with real security impact.

6. Wildcard certificates without CAA constraints

Related to the above: if you use wildcard certificates (*.yourdomain.com), you're implicitly trusting the CA's validation process for every possible subdomain. A CAA record with the issuewild tag limits which CAs can issue wildcards specifically.

# Specific CAA tag for wildcard issuance
# yourdomain.com. CAA 0 issuewild "letsencrypt.org"

7. No MTA-STS

MTA-STS (Mail Transfer Agent Strict Transport Security) tells other mail servers that they must use TLS when sending email to your domain — and that they should fail delivery rather than fall back to plaintext.

Without it, an attacker who can intercept SMTP traffic can strip TLS and read your email in transit. It's 2026. This is not an acceptable risk for a domain that handles business email.

MTA-STS requires a policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt and a DNS TXT record. It's not complicated but it has moving parts, which is probably why adoption is still low.

8. Subdomain takeover risk

This one is embarrassing when it happens. You spin up a staging environment on staging.yourdomain.com, point it at an AWS S3 bucket or a Heroku dyno, then shut down the project. You delete the resource but forget to remove the DNS record. Now staging.yourdomain.com points at an unclaimed resource that anyone can claim.

The attacker creates an S3 bucket with the same name, or a Heroku app with the same app name, and suddenly staging.yourdomain.com serves their content — under your domain, with your implicit trust.

# Check for dangling CNAME records
dig CNAME staging.yourdomain.com
# If you get a CNAME to a cloud provider resource that no longer exists,
# you're vulnerable

Audit your DNS records quarterly and remove anything that no longer corresponds to an active resource.

9. Missing PTR records

PTR records are the reverse DNS lookup — they map an IP address back to a hostname. Mail servers use them to verify that your sending IP has a PTR record matching your A record (forward-confirmed reverse DNS, or FCrDNS). Without them, your email is more likely to be marked as spam.

This is especially common with self-hosted mail or newly allocated IP ranges. Your hosting provider usually handles PTR records, but you have to request them — they're not set automatically.

10. No monitoring

You can get everything above right today and have it broken in six months when someone edits the wrong record, a third-party integration changes their IP range, or your registrar auto-renews with different defaults.

DNS monitoring doesn't have to be expensive. A cron job that runs dig checks daily and alerts on unexpected changes covers most cases. Commercial options add history and change attribution if you need them.

If you want a complete checklist of DNS security controls with implementation notes, I've put together a detailed DNS security checklist for 2026 that covers all of the above plus DANE, negative TTL configuration, resolver security, and monitoring setup. It's free, available as PDF and Excel.

The broader security checklists library also covers firewall configurations, Active Directory hardening, Windows and Linux system hardening, and more — 17 checklists total.

None of these DNS problems are hard to fix. The hard part is knowing they're broken. Most organizations I audit had no idea their SPF had a +all or that three of their CNAME records were pointing at deleted resources. A one-time audit of your DNS configuration probably takes two hours and finds at least three of the items on this list.

I run AYI NEDJIMI Consultants, a cybersecurity consulting firm. We publish free security hardening checklists for FortiGate, Palo Alto, pfSense, Sophos, Active Directory and more — PDF and Excel.