Short answer: do not delete an unfamiliar TXT record merely because a registrar export labels it stale. During an e-commerce zone migration, keep it until you can name its owner, prove that owner has retired the verification, and check the record's effect on mail and third-party integrations. The operational cost is a little inventory work. The failure cost can be a broken checkout email, a lost analytics feed, or a domain that cannot be re-verified during an incident.
The bill is not the DNS query itself. The expensive part is retention: keeping an undocumented token forever increases review time, incident ambiguity, and the chance that a future team edits the wrong record. My rule is to pay that small carrying cost while ownership is unknown, then remove records in a controlled change with a rollback window.
Should you keep stale vendor TXT records or start cleaning them?
A TXT value is just data at a name; its meaning comes from the system that reads it. A verification service may look for an exact token. Mail systems may evaluate SPF or DMARC policy. A security tool may use a different namespace altogether. Seeing a string that resembles a vendor token is not proof that the vendor still has authority, or that no other workflow depends on it.
DMARC, specified in RFC 7489, is evaluated from a policy record at _dmarc.example.com. Removing an unrelated token at the zone apex does not clean up DMARC, and deleting a policy record to tidy an inventory can change mail handling. Treat each owner and name as a separate dependency.
I initially treated four unknown values as harmless clutter. Later I found that the hard part was proving a deletion, not storing the bytes. In a migration I would rather carry those values for one release than create an outage with one confident-looking deletion. That is a deliberate trade: retention buys time to identify an owner; it does not grant the old system permanent control.
A customer-owned versus platform-owned decision
For customer-owned zones, the customer is the authority of record. The migration service should request a change, record the exact name and value, and never assume it can later remove that value. For platform-owned zones, the platform can manage lifecycle, but it still needs an internal owner, purpose, creation timestamp, and expiry condition.
The distinction matters when a merchant moves away from a registrar-specific API. Importing the zone file is not enough. Preserve unknown TXT values, attach them to an ownership queue, and ask the customer or integration owner to confirm retirement. A token with no response remains retained but flagged; it is not silently normalized away.
Unknown is a valid state.
A compact inventory record can make the choice reviewable:
from dataclasses import dataclass
from datetime import date
@dataclass
class TxtDependency:
name: str
value: str
owner: str | None
purpose: str | None
last_confirmed: date | None
removal_ticket: str | None
def can_remove(item: TxtDependency, today: date) -> bool:
return (
item.owner is not None
and item.purpose is not None
and item.removal_ticket is not None
and item.last_confirmed is not None
and (today - item.last_confirmed).days >= 30
)
The 30-day interval here is a process gate, not a DNS standard. Choose a period your support and compliance teams can actually meet, and document it as policy.
Which checks make cleanup reversible?
First, snapshot the authoritative zone and the proposed diff. Second, test the exact verification flow that depends on the TXT value, including a fresh customer account where possible. Third, inspect mail authentication separately: SPF syntax, DKIM selectors, and the DMARC policy should each have an identified owner. A successful DNS lookup alone proves very little.
Deploy removal as a small, named change. Keep the previous value in the change record, monitor verification failures and mail reports, and define a restore action before pressing apply. If a customer cannot identify a token, leave it in place and escalate with evidence rather than guessing.
Do not use a wildcard cleanup script. TXT records can be multi-valued, and a script that treats the set as one opaque string can delete a still-valid value while preserving the obsolete one. Compare individual values and require an explicit ticket for every deletion.
After ownership is confirmed, remove the token at the next maintenance window and close the ticket with the evidence used. What you deliberately stop keeping is not just text in DNS; it is an unbounded exception in the migration system. The cost of a bad removal is a rollback and a customer conversation, so the system should make rollback boring.
The decision is therefore asymmetric: unknown ownership means retain and investigate; confirmed retirement means remove with a recorded diff; disputed ownership means leave the record untouched. The trade-off has a clear limitation: this approach is not suitable for emergency domain seizure or an active compromise, where incident responders may need an immediate quarantine decision and a separate chain of authority. For ordinary migrations, it works across registrar changes because it relies on evidence, not on a particular API's labels.
Top comments (0)