Before You Delete That Service, Clean Up Its DNS

An old documentation site is ready to retire. You delete the project, cancel the subscription, and close the ticket. The CNAME at docs.example.com stays exactly where it was.

That leftover record is still an instruction to visitors. Depending on the provider and the resource, it may point to a dead endpoint or a service someone else can claim.

The safest time to account for DNS is while you still control the service you're removing.

Start with ownership, not deletion

Build a small inventory for the retirement:

• Which hostname or hostnames reach this service?
• Which team and account own the destination?
• Which DNS records make it work?
• Which other applications depend on those names?
• What should a visitor or client receive after retirement?

A DNS export is useful, but it doesn't tell you which records are safe to remove. Confirm ownership with the team that uses the service.

Also inspect the service's custom-domain configuration. A hostname can appear in provider settings that nobody remembers when looking at the DNS zone alone.

Follow the references

For a web service, start with the visible hostname:

dig docs.example.com CNAME
dig docs.example.com A
dig docs.example.com AAAA

Follow any CNAME chain and compare the destination with the resource you're retiring. A successful DNS answer doesn't prove that the resource remains under your control.

Look for less visible dependencies too: redirects from other sites, webhook URLs, API clients, certificate renewal automation, and links in customer emails.

The CNAME guide explains the underlying alias behavior. Here the task is to decide what should replace or remove that dependency.

Distinguish obsolete records from shared records

A retired tool may have added several different records, and they don't all have the same lifetime.

A dedicated verification TXT record may be removable once the provider confirms it is no longer needed. An SPF include may authorize more than the one workflow you are deleting.

A DKIM selector needs a short grace period. Messages already sent, or sitting in a retry queue, are verified against the published key when they arrive, so removing the key the moment sending stops can make those messages fail. Leave it in place for a few days after the last message goes out.

Mail records deserve the most care, because "we stopped using that tool" is often only partly true. A forgotten workflow may still send invoices or password resets through it. DMARC aggregate reports answer that directly: they list every source sending mail as your domain. MyDMARC turns those reports into a per-source view, so you can confirm a service has actually gone quiet before removing its SPF include or DKIM selector, rather than finding out from the failures afterward.

Do not remove a shared MX or SPF configuration simply because one application has stopped using it. Identify the specific dependency and change that part of the configuration.

Similarly, deleting a delegated child zone requires a plan for its parent NS referral. Leaving the referral in place points resolvers at a zone that may no longer exist.

Choose the retirement behavior

There are usually three sensible outcomes:

Move the hostname to a replacement service. Prepare and verify the replacement before changing DNS, then retain the old service while cached answers expire.

Keep a controlled retirement page or redirect. The hostname still needs working hosting and, for HTTPS, a valid certificate. DNS alone cannot issue an HTTP redirect.

Remove the hostname entirely. Clients will eventually receive a negative DNS answer. Confirm that this is an acceptable result for every known consumer.

Write the chosen outcome into the retirement ticket. “Delete the account” is an action, but it doesn't describe the user experience you're trying to produce.

Remove the reference before releasing the resource

For a hostname that should disappear, remove its DNS reference while you still control the target. Keep the old resource or the provider's supported ownership protection in place through the previous DNS cache window before releasing it.

If you lower a TTL to shorten that window, do it in advance and wait for the old TTL first. Lowering it after deletion won't change answers already cached.

Provider-specific protections matter. Some platforms verify domain ownership or reserve deleted names; others have different reclamation rules. Microsoft's subdomain takeover guidance describes dangling references and preventive controls in Azure. Check the equivalent process for the service you're retiring.

A 404 page alone doesn't establish that a resource is claimable. Equally, don't use a provider's usual protections as a reason to leave obsolete references indefinitely.

Verify the public result

Check the authoritative answer and more than one recursive resolver after the edit. If you moved the hostname, test the destination over HTTPS. If you removed it, confirm that the expected record is gone.

Then review the inventory once more before closing the account:

• No active hostname still points at the retired resource.
• Shared mail and verification records remain intact.
• The previous DNS cache window has been accounted for.
• The replacement or retirement behavior works.
• The change and responsible owner are recorded.

Keep a copy of the removed configuration with the ticket. It makes an accidental removal much easier to diagnose.

How DNS monitoring fits in

Retirements rarely fail on the day. They fail weeks later, when someone notices a record that should have been removed, or one that was removed by mistake. OneDollarDNS keeps a dated history of every monitored record, so the removal alert doubles as a record of the change: what was removed, when, and what it pointed to. If a shared SPF or MX record was edited along the way, that shows up too.

It's worth keeping the retired hostname monitored for a few weeks after the change. A CNAME added back by an old automation script, or a verification record reappearing after someone restores a zone backup, shows up as a new alert instead of a surprise. CNAME monitoring explains how this helps with the takeover risk described above.

Monitoring can't tell you whether an unchanged CNAME target is still owned by you, so complete the ownership checks separately. Once the retirement has held, remove the retired hostnames from your monitored hosts so your host list matches the services you actually run.