Dangling DNS Checker

Q: How can dangling DNS affect email security?

A dead SPF include: lets the new owner of that domain authorize their servers to send as you, which can pass SPF and DMARC. A dead MX host can let someone else receive your mail. Mail from a hijacked subdomain can also align with your organizational domain under relaxed DMARC alignment, so set an explicit sp= policy.

Find DNS records that still point to deleted cloud resources, dead mail servers or expired SPF domains, before an attacker claims them and serves content or sends email from your domain.

How the Dangling DNS Checker Works

Dangling records are DNS entries left behind after the resource they point to is deleted. This tool looks for them across your subdomains and mail setup, and tells you which ones an attacker could take over.

Enter your domain

Type your root domain (e.g. company.com). We check names from public certificate logs and common names like blog, shop, staging and status, plus any subdomains you add. A random-name probe detects wildcard DNS first so it isn't reported as a finding.

Records are resolved

Each CNAME is followed to its final target. We flag targets that return NXDOMAIN, confirm them on a second DNS server, and check platforms with known takeover cases for their "not found" page. MX hosts, name servers and SPF include: domains are resolved too.

Get a fix list

See every dangling and at-risk record ordered by severity, with the exact record to delete or the resource to reclaim, so your DNS owner knows what to do first.

What Is a Dangling DNS Record?

A dangling DNS record points to a resource you no longer control. The common case is a CNAME for a subdomain like blog.company.com that still points to a Heroku app, S3 bucket or Azure site that was deleted. If the provider lets anyone register that resource name again, an attacker can claim it and your subdomain starts serving their content. This is called a subdomain takeover.

$ dig blog.example.com blog.example.com. 300 IN CNAME example-blog.herokuapp.com. example-blog.herokuapp.com. status: NXDOMAIN ; The app was deleted. The CNAME was not. ; Anyone who creates "example-blog" on Heroku now controls blog.example.com.

Phishing on your real domain

A taken-over subdomain serves the attacker's pages over HTTPS with your domain in the address bar. Users, filters and URL scanners trust it.

Email sent as you

A dead SPF include: lets whoever registers that domain authorize their own servers to send as you. Those messages can pass SPF and DMARC.

Check your SPF record →

Cookies and sessions exposed

Cookies scoped to .company.com are sent to every subdomain, including a hijacked one. Attackers can also get valid TLS certificates for it.

Read: dangling DNS and subdomain takeover →

Common Dangling DNS Findings and How to Fix Them

These are the record types this checker flags, what each one means, and the fix.

Dangling CNAME

CNAME target doesn't exist

The subdomain points to a host that returns NXDOMAIN. If the target lives on a cloud or SaaS platform, it may be claimable by anyone.

Delete the CNAME, or recreate the resource with the exact same name under your own account.

Takeover-prone service

CNAME to S3, Azure, Heroku, GitHub Pages and similar

Some platforms keep resolving after the resource is deleted and only show a "not found" page. DNS alone can't tell an active resource from an abandoned one, so we also look for that page.

Confirm the resource still exists in your provider account. Remove the record if the project is retired.

Dead SPF include

SPF includes a domain that no longer exists

An expired vendor domain in your SPF record can be registered by anyone, who can then publish SPF that authorizes their own mail servers for your domain.

Remove the include: from your SPF record. It also frees one of your 10 DNS lookups.

Dead MX host

Mail exchanger doesn't resolve

Mail to that host fails. If the host's domain has lapsed, a new owner could receive mail addressed to your domain.

Remove the MX record or point it to an active mail server.

Released IP

A record points to a cloud IP you gave up

Cloud providers reassign released public IPs to other customers. DNS alone can't show who owns an IP, so this checker lists A records for you to verify.

Compare A records against the IPs allocated in your cloud accounts and delete the rest.

Orphaned delegation

NS records for a deleted hosted zone

A subdomain delegated to a DNS zone that was deleted at the provider lets someone recreate that zone and control every record below it.

Delete the NS delegation, or recreate the hosted zone in your own account.

How to Prevent Dangling DNS Records

Delete DNS first

When a project ends, remove the DNS record before deleting the cloud resource, not after.

Keep an inventory

Track which team owns each subdomain and which provider hosts it.

Clean up SPF

Remove vendors you no longer send through from your SPF record during every vendor offboarding.

Monitor continuously

Dangling records appear whenever a resource is deleted. Scan after every infrastructure change, or set up DNS takeover alerts.

Frequently Asked Questions

What causes dangling DNS records?

They appear when a cloud resource, SaaS account or mail host is deleted but the DNS record pointing to it stays in place. It's common when one team manages DNS and other teams create and retire services.

Is a dangling CNAME always exploitable?

No. It depends on whether the provider lets someone else register the same resource name. AWS S3, Azure App Service, Heroku and GitHub Pages all have documented takeover cases. Even when a takeover isn't possible, the record is broken and should be removed.

Why is a record marked "Review" when it resolves?

Some platforms keep resolving your CNAME after the resource is deleted and only show a "not found" page over HTTP. We check for that page on the platforms where it can be told apart from a working site. Where it can't, we flag the record for you to confirm in the provider's console.

Does this tool find every subdomain I have?

It checks names from public Certificate Transparency logs and common names, plus any you add. For a complete audit, export your DNS zone and paste the host names into "Add your own subdomains". You can also use our Subdomain Security Checker to grade the email authentication of your subdomains.

How can dangling DNS affect email security?

A dead SPF include: lets the new owner of that domain authorize their servers to send as you, which can pass SPF and DMARC. A dead MX host can let someone else receive your mail. Mail from a hijacked subdomain can also align with your organizational domain under relaxed DMARC alignment, so set an explicit sp= policy.

Is my domain data stored?

We don't keep a permanent record of the domains you check. To run a scan, your domain is sent to public DNS resolvers (Google and Cloudflare, with Quad9 as a backup) and to public certificate log services. A platform your records point to gets a request for that subdomain, so we can read its "not found" page, and a domain that looks unregistered is checked with its registry. A result is held for about two minutes so repeat scans do not hit your DNS again, certificate and registry lookups for up to an hour, and then they are discarded.

Keep your DNS and email authentication clean with PowerDMARC

Monitor DMARC, SPF, DKIM, MTA-STS and DNS changes across all your domains, get alerts when records break, and reach enforcement without guesswork.

Book a demo Start 15-day trial