Email and DNS

DNS security check: 9 misconfigurations to find

By Matt Chapman/Published 31 October 2026/Updated 2 November 2026/8 min read

Your Domain Name System (DNS) records are public. Anyone can look them up, and attackers routinely do, because DNS is a map of everything a business runs online: websites, mail servers, remote access portals and the cloud services behind them.

Most DNS security problems aren’t clever attacks. They’re leftovers: a record pointing at a server that was switched off two years ago, a test subdomain nobody removed, or a provider that was replaced but never taken out of the zone. Each one is a small gap that someone else can use.

This guide walks through nine misconfigurations I look for when I take on a new client or tidy up an old domain. You don’t need special software, and every check uses public information. Do it once now, then repeat it every few months or after any website, email or hosting change.

Only check domains you own or manage. Looking up public records is harmless, but if you find a problem on someone else’s domain, report it to them rather than testing it.

Before you start: make a list of your hostnames

A DNS lookup answers questions about names you give it. It can’t list every subdomain for you, so the first job is to build that list. Pull it from:

1. Your DNS host. Most control panels (Cloudflare, your registrar, cPanel) can export the whole zone as a file. This is the most complete source.
2. Certificate transparency logs. Every public SSL/TLS certificate is logged. Searching your domain on a site such as crt.sh shows names that have had certificates, including ones you’ve forgotten.
3. Old documentation and tickets. Look for past projects: a staging site, a booking system, a VPN portal, an old intranet.

Write the names in a spreadsheet with three columns: the name, what it’s for, and who owns it. Any name you can’t explain is your first lead.

To check the records, run each name through the free DNS lookup. It shows A, AAAA, CNAME, MX, TXT, NS, SOA, CAA, SRV and PTR records with plain-English notes. You can also use nslookup or dig from a command line if you prefer; the checks below work the same way.

The 9 checks

1. Check who actually controls the domain (NS and SOA)

Look up the domain’s NS (name server) and SOA (start of authority) records. The name servers should belong to the DNS host you expect, and nothing else.

Red flags:

• Name servers from a provider you left years ago. Whoever controls that account can still change your records.
• A mix of two providers’ name servers. Visitors get different answers depending on which one they ask.
• Name servers on a domain that isn’t yours, for example ns1.old-web-designer.co.uk. If that domain expires, someone else can register it and answer DNS for your domain.

Fix: point the name servers at the one DNS host you use, at the registrar, and make sure that account uses two-factor authentication.

2. Find dangling CNAMEs (subdomain takeover)

This is the most serious problem on the list. A CNAME (canonical name) record makes one name an alias for another, often a cloud service: shop.example.co.uk pointing at a hosted store, or app.example.co.uk pointing at an azurewebsites.net address.

If the cloud resource is deleted but the CNAME stays, the record is "dangling". On many platforms, an attacker can create a new resource with the same name and your subdomain starts serving their content: phishing pages, malware, or cookie theft from your main site.

1. Look up the CNAME for each subdomain on your list.
2. Follow the chain to the final name. The DNS lookup shows the whole alias chain.
3. Look up that final name. If it doesn’t exist (an NXDOMAIN or "no records" result), or it lands on a provider’s "site not found" page, treat it as urgent.

Fix: delete the CNAME today. In future, remove the DNS record before you delete the cloud resource, not after.

3. Test for wildcard records

A wildcard record (*.example.co.uk) answers for any name, including ones that don’t exist. Look up a nonsense name such as zz-test-4821.example.co.uk. If it returns an address, you have a wildcard.

Wildcards aren’t always wrong, but a wildcard CNAME to a third-party service is a takeover risk across every possible subdomain. It also makes phishing links like login.example.co.uk look convincing. If you don’t know why the wildcard exists, remove it and add the specific names you need.

4. Check A and AAAA records still point at your servers

A records hold IPv4 addresses; AAAA records hold IPv6 addresses. Cloud providers recycle IP addresses, so a record pointing at a server you switched off may now point at someone else’s.

For each address, confirm it belongs to a server you still pay for. A reverse (PTR) lookup on the IP address helps: if it resolves to another company’s host name, the address has moved on. Delete records for anything you can’t account for.

5. Look for records that expose your real server

If your website sits behind Cloudflare or another proxy or web application firewall (WAF), DNS should only show the proxy’s addresses. The DNS lookup flags Cloudflare addresses, so you can see at a glance which names are proxied and which aren’t.

Common leaks:

• A direct., origin., cpanel., ftp. or dev. record pointing straight at the web server.
• A mail. record on the same IP address as the website. Mail records can’t go through Cloudflare’s proxy, so they reveal the server.
• An AAAA record that bypasses the proxy, because only the A record was set up through it.

Attackers who know the real address can go around the firewall. Fix: remove the extra records, move mail to a separate host, and set the server’s own firewall to accept web traffic only from the proxy.

6. Check for private IP addresses in public DNS

Addresses such as 10.x.x.x, 172.16.x.x to 172.31.x.x and 192.168.x.x only work inside a network, so they have no place in public DNS. The DNS lookup flags them for you.

They don’t let anyone in, but they give away your internal layout (sql01.example.co.uk at 192.168.1.20, for example). They usually appear when someone adds an internal server to the public zone instead of the office’s internal DNS. Move them to internal DNS.

7. Read your TXT records like an attacker would

TXT records hold verification codes and email settings, and they’re a handy list of which services you use. Look for:

• Verification codes for services you’ve stopped using. They tell attackers which platforms to try phishing you through. Remove ones you’re sure about, and keep any you aren’t.
• Anything that looks like a password, key or internal note. TXT records are never private.
• More than one SPF record (TXT records starting v=spf1). Two SPF records make SPF fail completely, and the DNS lookup warns you about this.

8. Check CAA records

CAA (Certification Authority Authorisation) records list which certificate authorities may issue SSL/TLS certificates for your domain. With none, any authority can issue one, as long as the requester can prove control of the domain.

That’s the default, not a fault, but adding CAA records is a cheap extra layer. For example, a site that only uses Let’s Encrypt can publish 0 issue "letsencrypt.org".

Before you add one, list every service that issues certificates for you: your host, your CDN (content delivery network), and Microsoft 365 or other cloud services on your subdomains. Leave one out and its next renewal fails.

9. Check your email records

Email settings are the DNS records attackers abuse most, because weak ones let them send mail that looks like it came from you. In the DNS lookup:

• MX records should point only at your current email provider. An old provider left in the list can still receive some of your mail.
• SPF should list only the services that send for you and end in -all or ~all. An SPF record ending +all allows anyone in the world to send as you.
• DMARC lives in a TXT record at _dmarc.example.co.uk. A missing record, or p=none left in place for years, means nothing stops spoofed mail.

For a fuller test, check your SPF, DKIM and DMARC records with the email DNS checker. It also recognises Microsoft 365 and Google Workspace and explains each fix.

While you’re there, look up SRV records. Old _sip or _autodiscover entries pointing at a decommissioned Exchange or Skype for Business server are common, and they reveal internal host names and ports. Remove any that point at servers you’ve retired.

If your DMARC record is missing or stuck at p=none, the guide to setting up DMARC takes you from monitoring to p=reject without blocking your own mail.

What a DNS lookup can’t check

A lookup shows the records you ask for, through a public resolver. A few related checks need other methods:

• Zone transfers. If your name servers allow anyone to request a full zone transfer (AXFR), the whole zone can be downloaded. Test your own domain from a command line with dig axfr example.co.uk @ns1.yourdnshost.com; it should be refused. Most hosted DNS providers block this by default.
• DNSSEC (DNS Security Extensions). This signs your records so they can’t be faked in transit. Check whether it’s switched on in your DNS host and registrar.
• Registrar account security. The best records in the world don’t help if someone takes over the registrar account. Use two-factor authentication and turn on the transfer lock.

Quick checklist

• List every hostname from the zone export and certificate logs
• Name servers belong to one current DNS host
• No CNAME points at a deleted cloud resource
• No unexplained wildcard record
• Every A and AAAA address belongs to a server you still run
• No record reveals the real server behind your proxy
• No private IP addresses in public DNS
• TXT records tidied, with exactly one SPF record
• CAA records list every certificate authority you use
• MX, SPF and DMARC are current and strict, with no stale SRV records
• Zone transfers refused, DNSSEC considered, registrar locked

Repeat it every few months, and every time a website, email system or hosting provider changes.