Yes, delete verification TXT records for services you no longer use, after confirming the service is gone. They are proof that someone once controlled your domain, they reveal your vendor history to anyone who looks, and they can let an old account keep its standing. Keep records for tools you still run.
What these records are
Many services ask you to prove you own a domain before they enable email sending, single sign on or a custom hostname. The usual proof is a TXT record at the apex or at a named label, containing a token the service gave you. When the service checks DNS and finds the token, it marks the domain verified.
Over years, a busy zone collects dozens of these. Most are never removed because nobody remembers what they were for, and deleting an unknown record feels risky.
Why stale ones matter
- They show your tools. TXT records are public. Anyone can list them and learn which vendors you have tried, which helps targeted phishing.
- Old tenants may stay verified. A forgotten account at a vendor may still list your domain as verified. If that account is ever reused or taken over, it carries your domain's standing. Check each vendor's documentation for how they treat a domain whose record is gone.
- Clutter hides real problems. A crowded zone is harder to audit for records that are dangerous, such as dangling CNAME entries.
- SPF mixed into the mess. Several TXT records at the apex are normal. Two SPF records is a fault. Cleaning makes that error easier to see.
Our post on domain verification as the root of tenancy explains why verification carries real authority in multi tenant products.
A cleanup routine
- Export all TXT records at the apex and at every subdomain.
- Classify each one. Group them as email authentication (SPF, DKIM, DMARC), vendor verification, or unknown.
- Match vendors. For each verification token, find the service. Search your finance records, SSO app list and admin consoles.
- Check the account. Is the service still in use? Log in to see whether the domain is still listed as verified there.
- Remove the domain on the vendor side first where the service allows it, then delete the TXT record.
- Handle unknowns carefully. Lower the TTL, delete one unknown record, wait a week and watch for complaints. Keep a copy so you can restore it.
- Write it down. Record which service each remaining record belongs to, with an owner.
Records you should keep
Keep SPF, DKIM, DMARC, MTA-STS, CAA and any record for a service you still use. Do not remove a verification record for a tool in production without checking that it does not need re-verification. Some vendors ask again at renewal.
Check CAA carefully, because it controls which certificate authorities may issue for the domain, see CAA records explained.
Prevent the pile
Add a line to your tool offboarding checklist: remove the domain from the vendor, then remove the DNS records. Pair it with an annual zone review as in the DNS hygiene checklist.
Safeguard's asset discovery helps inventory the software and services you run, and its free scan is at gold.safeguard.sh/scan.
Quick check
Can I have many TXT records on the same name?
Yes. A name can hold many TXT records. The exception is SPF: publish one SPF record per name, since two cause an error.
What if I cannot identify a record?
Lower its TTL, back it up, remove it and watch for a week. Restore it if something breaks, and then document what it was.
Sources
Last reviewed: 19 October 2026.
