Subdomain Takeover Check

The common pattern is a dangling DNS record. A company creates a CNAME or similar record that points to a hosting platform, SaaS service, CDN, storage bucket, landing page tool, help desk, campaign site, or cloud app. Later, the external resource is deleted, renamed, or deprovisioned, but the DNS record remains.

If the external provider allows the resource name to be registered again, an attacker may be able to publish content on the trusted subdomain. That can affect phishing risk, brand reputation, cookies, links, search results, and customer trust.

• CNAME records pointing to old SaaS, hosting, CDN, or cloud resources.
• Campaign, staging, help, docs, status, blog, landing page, or support subdomains that were retired.
• Cloud storage buckets, static hosting sites, or app services that no longer exist.
• DNS records that return service-specific error pages indicating the resource is unclaimed.
• Subdomains that still appear in sitemap, robots, old emails, ad links, or search results.

A responsible check should combine DNS enumeration, provider fingerprinting, and manual validation. Automated tools can produce false positives, so high-risk results should be verified before escalation.

1. Enumerate known public subdomains from DNS, certificates, links, sitemaps, old campaigns, and documentation.
2. Resolve DNS records and identify CNAME, ALIAS, A, AAAA, and service-specific targets.
3. Look for external services that indicate missing, deleted, unconfigured, or unclaimed resources.
4. Validate suspicious findings without taking control of third-party resources.
5. Prioritize records linked from production pages, customer emails, login flows, assets, or trusted documentation.
6. Remove, fix, or reclaim the resource through the legitimate owner account.

Not every DNS oddity is a takeover risk. The strongest signals combine an active DNS record, an external provider, an unclaimed or deprovisioned resource, and a subdomain that users may trust.

• The DNS record resolves but the service says the site, app, project, bucket, or page does not exist.
• The subdomain was used for marketing, customer support, documentation, apps, downloads, or authentication-related journeys.
• The subdomain is linked from the main website, emails, social profiles, old ads, or search results.
• The external provider supports user-created resources with names that can be reclaimed.
• The record is owned by a team, agency, vendor, or old project no longer responsible for the service.

The safest fix is usually to remove the DNS record or restore the legitimate resource under an account the organization controls. Choose the fix based on whether the subdomain still needs to exist.

1. Confirm ownership and business purpose of the subdomain.
2. If the subdomain is no longer needed, remove the DNS record.
3. If the subdomain is still needed, recreate or reconnect the legitimate third-party resource from the correct account.
4. Remove stale links from the website, sitemap, email templates, ads, documentation, and social profiles.
5. Check whether cookies, CORS policies, CSP rules, redirects, or API trust relationships include the subdomain.
6. Document the owner and renewal process for the service behind the subdomain.
7. Add recurring monitoring so retired services do not leave DNS behind.

The best prevention is operational discipline. DNS should have owners, lifecycle rules, and monitoring just like application code.

• Keep an inventory of subdomains, DNS records, owners, vendors, and business purpose.
• Remove DNS records as part of vendor offboarding and campaign shutdown.
• Require teams and agencies to document third-party services attached to subdomains.
• Review certificate transparency, DNS records, sitemaps, and public links periodically.
• Monitor for provider-specific error pages and unclaimed resource messages.
• Include subdomain checks before launches, migrations, rebrands, and agency handoffs.

Fixnx can help review public website and DNS-adjacent signals that often reveal stale infrastructure: links to old subdomains, redirects, exposed paths, inconsistent HTTPS, suspicious service pages, and report evidence.

For a full takeover assessment, pair public website scanning with DNS inventory, certificate transparency review, and manual validation of third-party provider signals.

• Identify linked subdomains and external service exposure from public pages.
• Review redirects, HTTPS behavior, headers, and canonical signals across public routes.
• Document evidence so DNS, hosting, agency, or vendor owners can fix records.
• Retest after DNS cleanup, domain migration, or vendor offboarding.