To retire a subdomain safely, remove its DNS record before you delete the service behind it. If the resource goes first, the record points at a name anyone may claim. Then clean up certificates, allowlists, cookies, verification records and monitoring, and note the change in your inventory.
Why order matters
The takeover pattern Microsoft describes starts when a cloud resource is deleted while the DNS record that points to it stays behind. For a window of time, the hostname is live in DNS and unowned on the platform. MDN describes the same condition: a CNAME exists, but no host provides content. An attacker watching for that gap can register the resource name and answer for your hostname.
Reverse the order and the gap closes. With the record gone first, there is nothing to point at the abandoned name. Our audit guide finds old cases. This runbook prevents new ones.
The runbook
- Name an owner and a date. A retirement without an owner stalls.
- Find dependencies. Search code, configs and docs for the hostname. Check mobile apps, partner integrations, webhooks and email templates.
- Check traffic. Review logs for the last 30 days, and note who still calls it.
- Announce to internal teams and, where needed, customers, with a cutover date.
- Lower the record lifetime a day or more before the change so that a rollback is quick.
- Redirect or retire. If users need a destination, redirect to a live page. If not, return a clear gone response for a short time.
- Delete the DNS record. This comes before deleting the resource.
- Delete the resource on the platform, and remove any custom domain binding there.
- Remove certificates. Revoke or let lapse any certificate issued for the hostname, and drop it from deployment automation.
- Clean trust lists. Remove the hostname from CORS, content security policy, OAuth redirect and SSO configurations. See the redirect URI checklist.
- Check cookies. If the host set cookies scoped to the parent domain, consider whether sessions need to be invalidated.
- Remove related records: verification TXT entries, mail records, and monitoring checks. See stale verification records.
- Update the inventory with the date, the reason and the person who approved.
- Verify. Query the name from outside your network, confirm it returns no answer, and check again after the old lifetime has passed.
Roles
| Step group | Owner |
|---|---|
| Dependency search and announcement | Service owner |
| DNS changes | Platform or infrastructure team |
| Trust list cleanup | Application security |
| Inventory update | Whoever keeps the asset register |
Special cases
- Delegated subdomains. If you hand a subdomain to another name server with NS records, remove the delegation as well. Read delegation and glue.
- Mail subdomains. Check DMARC reports for traffic from the name before removing mail records, since a forgotten sender may still use it.
- Short lived environments. For preview and test hosts created by automation, build the DNS deletion into the teardown job, so it cannot be skipped.
- Wildcards. If a wildcard still matches the name, the hostname may keep resolving. See wildcard records.
Make it part of the process
Add a DNS removal step to every service retirement ticket template, and a periodic check that compares your inventory with the live zone. If your DNS lives in version control, deleting the record is a normal reviewed change, see DNS as code.
Safeguard's asset discovery supports keeping a current inventory of what you run, alongside SBOM and dependency scanning. The free scan is at gold.safeguard.sh/scan.
Quick check
What if I delete the resource first by mistake?
Remove the DNS record straight away and check logs for any claim of the resource name. The window is risky while the record still points at it.
Do I need to revoke certificates?
Revocation is a sensible step if the key could be reused or the host was ever exposed. At minimum remove the hostname from deployment so it is not renewed.
Sources
Last reviewed: 19 October 2026.
