After a few years, a domain's DNS zone collects records from different eras: an A record for the old hosting server, an MX from a mail service someone once tried, a verification TXT nobody remembers adding, a CNAME pointing to a long-closed online shop. Wanting to clean up is natural, because clutter causes confusion. But a single line removed on the assumption that "it's probably not needed" can stop email or take an important service offline.
Why an "old-looking" record may still be in use
DNS records carry no note about who added them, when or why. Names like old, test or srv2 look like junk from outside, yet an internal system, accounting software or a point-of-sale app may connect to exactly that name. TXT records are especially deceptive: some are needed only for one-time verification, but certain services re-check periodically that the record is still there. If it disappears, the service may decide you no longer control the domain and disconnect.
Mail records deserve extra care. SPF, DKIM and DMARC look like ordinary text strings, but removing any of them pushes your messages into recipients' spam folders. A DKIM key usually lives under a name like selector._domainkey, which many people mistake for leftover noise.
A real scenario: a clinic after moving its website
A private clinic in Tashkent moved its website to new hosting, and the administrator decided to tidy up the misol.uz zone. He deleted every A record pointing to the old server, including mail.misol.uz. The site worked fine in its new home, but the next day reception staff reported that the mail apps on their phones could not connect: the apps were configured with mail.misol.uz, and the mailboxes were still on the old server. It was fixed within hours, but patients' emails went unanswered in the meantime. Checking what each name served before deletion would have prevented it.
How to check a record before deleting it
First, capture the full current state of the zone. Copy all records from the DNS page in your cabinet and save them to a dated file. Then check what each record returns right now. These commands work on Linux, macOS or WSL on Windows:
# Core records
dig +short A misol.uz
dig +short MX misol.uz
dig +short TXT misol.uz
dig +short TXT _dmarc.misol.uz
# Where a specific subdomain points
dig +short CNAME shop.misol.uz
dig +short A mail.misol.uz
# If dig is not available on Windows
nslookup -type=MX misol.uzTo see whether anything is actually running at the IP in an A record, send a request straight to it. The --resolve option of curl maps a name to a given address without touching DNS:
curl -I --resolve old.misol.uz:443:203.0.113.10 https://old.misol.uz/If you get a response showing a live application, find out who uses it first. If nothing answers or the server is already gone, the record is most likely safe to remove.
Questions for each record type
| Record type | What to confirm before deleting |
|---|---|
| A / AAAA | Is a service running on this IP, and do devices or programs connect to this name? |
| MX | Which server hosts mail now, and does this MX match it? |
| TXT | Is it SPF, DKIM, DMARC or a service verification that gets re-checked? |
| CNAME | Is your account at the external service it points to still open? |
| CAA | Does your SSL certificate authority rely on it? |
Sometimes not deleting is riskier: the dangling CNAME
Cleanup has a flip side. If shop.misol.uz pointed via CNAME to an external shop platform and you closed that account, the record is left dangling. On some platforms a stranger can open a new account and claim that exact subdomain, so a foreign page appears under your name. This is subdomain takeover, and it is handy for phishing. When you drop a service, remove the CNAME pointing to it promptly, after confirming the service really is closed.
A safe removal sequence
- Save a full copy of the zone and note the date.
- A day ahead, lower the record's TTL to 300 seconds so a rollback spreads quickly.
- Ask your developer, accountant and mail users about the name.
- Delete the record and watch complaints, errors and mail logs for one to two weeks.
- If nothing breaks, archive the copy and document the change.
Lowering TTL is the step most often skipped. If the TTL is a full day and you restore a record after noticing a mistake, some users will keep seeing the problem because their provider's cache still holds the "no such record" answer.
Keeping the zone in order
A simple change log prevents these questions in the future: record name, type, value, who added it, why, and when to review it. The DNS page in the sayt.uz cabinet makes adding and removing records easy, but only such a log remembers whose decision each record reflects. Reviewing the zone once or twice a year keeps both the domain and mail stable.