DNS / email · Check
Subdomain takeover risk — dangling CNAME at a third-party host
A subdomain on your DNS has a CNAME that points at a third-party service (GitHub Pages, Heroku, Fastly, Shopify, etc.), but the resource on that platform is unclaimed. The vendor served its standard "this site is unavailable" page when we fetched the hostname, which means anyone who can register that resource on the third-party platform can host arbitrary content under your trusted subdomain.
Why it matters
Takeovers are weaponized quickly: attackers serve phishing pages from your own brand-owned hostname, set cookies on your origin, or pivot trusted integrations. The fix is to either re-claim the resource on the vendor (recreate the GitHub Pages site, Heroku app, etc.) or remove the stale DNS record entirely.
Real-world risk
An unclaimed third-party resource (GitHub Pages, Heroku app, Fastly service, Shopify store, etc.) lets anyone who can register that resource serve content from your trusted subdomain. That is enough to host phishing, distribute malware, or set cookies on your origin.
Fix steps (in order)
- Re-claim the resource on the vendor (recreate the GitHub Pages site, Heroku app, Shopify store, Fastly service, etc.) so the CNAME points at something you control.
- If the resource is no longer needed, remove the CNAME record from DNS so nothing else can claim it.
- Audit DNS for any other CNAMEs pointing at third-party hosting (look for SaaS hostnames you no longer use).
- Add a quarterly review of DNS records as part of offboarding any decommissioned vendor.
Topic explainer
DMARC, SPF, and DKIM explained: the email authentication trio →
A practical guide to email authentication: what SPF, DKIM, and DMARC each do, why all three are needed, and how to roll out a DMARC policy that actually blocks spoofed mail.
Verify the fix in 30 seconds
Run a Scorifya scan on the affected host after deploy. The same finding id (dns_subdomain_takeover_risk) clears once the externally-observable signal is in place.