Security audits of DNS infrastructure turn up the same handful of dangerous misconfigurations again and again, and most organizations have no idea these issues exist until someone goes looking for them. Anyone who has run a DNS security audit across a mid-sized domain portfolio knows the pattern: dozens of records that made sense three years ago, a few that were never supposed to be permanent, and at least one that could hand an attacker a foothold if left unnoticed. This article walks through the misconfigurations that show up most often, why they’re dangerous, and what to actually do about them.
Why DNS misconfigurations keep slipping through
DNS is one of the few systems in an organization that almost nobody owns end to end. Marketing spins up a subdomain for a campaign landing page, DevOps points a record at a staging environment, a contractor sets up a quick API integration – and none of it goes through change management the way a firewall rule or a database migration would.
The result is a zone file that grows for years without anyone pruning it. Audits routinely uncover records tied to services that were decommissioned, vendors that were dropped, or employees who left the company without a handoff. Each of these is a small gap, but attackers only need one.
Dangling CNAME records pointing to deprovisioned services
This is consistently the most common and most serious finding in DNS audits. A CNAME record still points to a cloud service – an S3 bucket, a Heroku app, an Azure endpoint, a GitHub Pages site – that was deleted or allowed to expire, but the DNS record itself was never removed.
If the underlying service name is available for anyone to claim on the provider’s platform, an attacker can register it and instantly serve content under the victim’s own subdomain. This is subdomain takeover, and it’s dangerous precisely because the domain still shows as trusted: valid TLS certificates can be issued, cookies can be captured, and phishing pages look completely legitimate because the URL is real.
A typical scenario: a company runs a six-week product demo on demo.example.com hosted through a third-party platform. The campaign ends, the hosting account is closed, but nobody tells whoever manages DNS. Eighteen months later, an audit – or an attacker running automated subdomain enumeration – finds the dangling CNAME and claims the underlying resource. For a deeper technical breakdown of how this chain of events unfolds, see Dangling CNAME Records: The Silent Threat to Your Domain.
Missing or overly permissive SPF records
SPF misconfigurations show up in nearly every audit, usually in one of two forms. Either the record is missing entirely, leaving the domain with no defined list of authorized senders, or it’s technically present but uses a soft fail (~all) or, worse, a pass-all (+all) mechanism that defeats the point of having SPF at all.
Both versions leave the domain open to spoofing – attackers sending email that appears to come from the organization, which is a foundation for business email compromise and phishing campaigns targeting customers or partners.
A less obvious but equally common problem is exceeding the 10 DNS lookup limit in an SPF record by chaining too many include mechanisms across multiple mail providers. When that limit is hit, SPF evaluation fails entirely, and receiving mail servers may treat every message as unauthenticated regardless of whether it’s legitimate.
DKIM and DMARC gaps that undercut each other
SPF alone isn’t enough, but audits frequently find it deployed in isolation. Without DKIM signing, there’s no cryptographic proof that a message wasn’t altered in transit. Without DMARC, there’s no policy telling receiving servers what to do when SPF or DKIM checks fail – so even a well-configured SPF record does nothing if DMARC is absent or set to p=none with no monitoring.
The myth worth busting here: many teams believe that having any DMARC record at all means they’re protected. A p=none policy only requests reports – it doesn’t instruct receivers to quarantine or reject failing mail. Plenty of domains have carried a p=none DMARC record for years, technically “compliant” while providing zero actual enforcement.
Orphaned A and MX records
Beyond CNAMEs, audits regularly find A records pointing to IP addresses that were reassigned by the hosting provider to a different customer, and MX records referencing mail servers that were migrated or shut down. Reassigned IPs are particularly risky in cloud environments where address space gets recycled quickly – a record left pointing at a released IP can end up resolving to infrastructure controlled by a stranger.
Wildcard records that overshare
A wildcard DNS record (*.example.com) is sometimes set up for convenience, routing any unrecognized subdomain to a default server. This can mask the fact that dozens of specific subdomains were never intentionally created, and it can also be exploited to serve attacker-controlled content under an unlimited number of subdomain variations if the catch-all target is ever compromised.
How to catch these before an attacker does
Fixing existing misconfigurations matters, but the more important shift is moving from a one-time cleanup to an ongoing process. A few practical steps:
Inventory every subdomain and DNS record tied to the domain, including ones created outside official channels – this is where most surprises turn up.
Cross-reference every CNAME and A record against the service it claims to point to, confirming the destination is still owned and active.
Validate SPF, DKIM, and DMARC together, not individually, and check the DMARC policy level rather than just its presence.
Set a recurring review cadence rather than treating the audit as a one-off event, since new subdomains and records get created continuously.
Organizations that go through this process manually tend to run it once a year at best, which leaves a wide window for a dangling record to be discovered and abused. A structured walkthrough of the process itself is covered in How to Perform a DNS Security Audit in Under an Hour, and the mechanics of how attackers actually weaponize these gaps are detailed in How Attackers Exploit Misconfigured DNS Records.
Frequently asked questions
How often should DNS records be audited?
At minimum quarterly, but any organization that regularly stands up subdomains for campaigns, testing, or vendor integrations should treat DNS review as continuous rather than scheduled, since new risky records can appear between audit cycles.
Can a dangling DNS record be exploited even if the subdomain gets little traffic?
Yes. Low traffic doesn’t reduce risk – attackers scan for dangling records using automated tools regardless of how visible the subdomain is, and the value to them comes from the trusted parent domain, not from visitor volume.
Is having SPF, DKIM, and DMARC records enough to consider email fully protected?
Not by itself. The records need to be correctly scoped – SPF without exceeding lookup limits, DKIM keys properly rotated, and DMARC set to a policy that actually enforces action, such as quarantine or reject, rather than just monitoring.
The common thread across every one of these findings is the same: DNS misconfigurations aren’t usually caused by bad actors, they’re caused by good records that nobody remembered to remove. Treating DNS hygiene as an ongoing discipline rather than an annual chore is the single most effective way to keep audit findings from turning into incident reports.