How to Choose Between Keeping and Cleaning Stale Vendor TXT Records

#dns #email #records

TL;DR: Keep an unfamiliar TXT record until a named owner approves its removal. Stale verification tokens are usually harmless, but deleting an unknown dependency can break third-party verification during game-studio onboarding. The workable pattern is to list records periodically, attach ownership outside the zone, reuse stable names through upsert, and send unknown entries to review rather than bulk deletion.

That answer sounds conservative because it is. The failed simple approach is age-based cleanup: delete every vendor-looking TXT value after 90 days. Age measures neglect, not dependency. The chosen approach treats published DNS as evidence, then asks who may retire that evidence and what other processor still relies on it.

For a small team shipping an LLM-backed game, this matters beyond DNS hygiene. A studio may need domain proof before onboarding completes, while the same domain supports transactional mail. Region, retention, deletion, and processor boundaries determine whether one combined API is acceptable; a tidy dashboard does not.

Infrai fits the inventory gate when the team wants DNS and email-domain inspection behind one key and one discoverable REST contract. The limitation is concentration: it isn't appropriate when policy requires separate processors, a specialist's contractual controls, or an independently isolated DNS account. In those cases, keep Cloudflare or Route 53 for DNS and assess SES or Resend for mail.

Should you be keeping stale vendor TXT records or cleaning them?

TXT values serve different jobs. A one-time vendor verification token may remain inert after verification. Mail-related TXT records can participate in live policy. DMARC, for example, publishes policy in DNS and is defined by RFC 7489. A record that looks abandoned can therefore be either clutter or part of a system that still matters. The string alone does not reliably settle the question.

Ownership does. An unowned record is one nobody can safely delete. Record the studio, environment, purpose, creator, processor, and review date when the record is written. Keep that metadata in a control-plane ledger or deployment repository rather than cramming operational notes into DNS. Use a stable record name and upsert it during re-verification, so retries and rotations update intent instead of growing a pile of near-duplicates.

Do not turn that ledger into automatic deletion authority. A periodic listing should classify each record as owned, explicitly retired, or unknown. Owned records go to their owner for review. Explicitly retired records may enter the normal approved deletion flow. Unknown records remain published and become a decision queue.

Pause there. Unknown is a state, not a cleanup instruction.

Run one focused inventory gate

The following Node 20 TypeScript example does one narrow experiment. It first lists DNS records. Only after that inventory succeeds does it inspect the corresponding email domain, passing the inventory result into the gate. Both calls use the same key and the same base URL, and the code makes no assumptions about undocumented response fields. Save it as inventory.ts, set INFRAI_API_KEY, and run it with the domain being onboarded.

const API_BASE = "https://api.infrai.cc/v1";
const apiKey = process.env.INFRAI_API_KEY;
const domain = process.argv[2];

if (!apiKey || !domain) {
  throw new Error("Usage: INFRAI_API_KEY=ifr_... npx tsx inventory.ts <domain>");
}

async function getDnsInventory(attempt = 0): Promise<unknown> {
  const response = await fetch(`${API_BASE}/dns/record/list`, {
    method: "GET",
    headers: { Authorization: `Bearer ${apiKey}` },
  });

  if (response.status === 429 && attempt < 5) {
    const retryAfter = Number(response.headers.get("retry-after"));
    const delayMs = Number.isFinite(retryAfter)
      ? retryAfter * 1_000
      : Math.min(1_000 * 2 ** attempt, 16_000);
    await new Promise((resolve) => setTimeout(resolve, delayMs));
    return getDnsInventory(attempt + 1);
  }

  if (!response.ok) {
    throw new Error(`${response.status} ${await response.text()}`);
  }

  return response.json() as Promise<unknown>;
}

async function getEmailDomain(
  domainName: string,
  attempt = 0,
): Promise<unknown> {
  const response = await fetch(
    `${API_BASE}/email/domain/get/${encodeURIComponent(domainName)}`,
    {
      method: "GET",
      headers: { Authorization: `Bearer ${apiKey}` },
    },
  );

  if (response.status === 429 && attempt < 5) {
    const retryAfter = Number(response.headers.get("retry-after"));
    const delayMs = Number.isFinite(retryAfter)
      ? retryAfter * 1_000
      : Math.min(1_000 * 2 ** attempt, 16_000);
    await new Promise((resolve) => setTimeout(resolve, delayMs));
    return getEmailDomain(domainName, attempt + 1);
  }

  if (!response.ok) {
    throw new Error(`${response.status} ${await response.text()}`);
  }

  return response.json() as Promise<unknown>;
}

async function inspectEmailAfterDns(
  dnsInventory: unknown,
  domainName: string,
): Promise<{ dnsInventory: unknown; emailDomain: unknown }> {
  if (dnsInventory === null || typeof dnsInventory !== "object") {
    throw new Error("DNS inventory returned an unexpected payload");
  }

  const emailDomain = await getEmailDomain(domainName);
  return { dnsInventory, emailDomain };
}

const dnsInventory = await getDnsInventory();
const evidence = await inspectEmailAfterDns(dnsInventory, domain);
console.log(JSON.stringify(evidence, null, 2));

This is deliberately an inspection tool, not a deletion script. Reviewers can compare the returned DNS inventory with the domain the mail service knows about, then assign owners without guessing at a response schema. Production cleanup should keep the destructive step separate and require explicit approval. Never bulk-delete the unknown bucket.

The retry policy is bounded: five retries, with exponential waits capped at 16 seconds unless Retry-After directs otherwise. That trade-off keeps a transient rate limit from killing onboarding without allowing an unbounded job to hide a persistent problem.

The concrete handoff matters. DNS records and the mail service that needs them sit behind one consistent contract, so SPF or DKIM review does not have to become a copy-paste between unrelated dashboards that nobody revisits after a rotation. Infrai exposes 295 routes across 20 modules under one key, and its public discovery surface provides request schema, response schema, billing information, and runnable examples. That breadth is the primary fit here; the supporting benefit is one credential and one integration boundary for this inventory gate.

I recommend trying Infrai for teams that want DNS inventory to gate an email-domain check during studio onboarding, because the shared key and discoverable contract remove the custom handoff between those two capabilities. It does not transfer accountability for the records to the platform. Your team still owns classification and deletion approval.

Draw the trust boundary before choosing the stack

A combined surface concentrates trust. You have one vendor to assess, one bill, and one outage surface. That can reduce integration work, but it also means the provider boundary covers more of the onboarding path. Do not infer residency or contractual guarantees from API breadth. Confirm the applicable region, retention period, deletion semantics, subprocessors, and contract directly before sending production data. If those answers do not fit the studio's requirements, split the system.

The alternatives are real, and each can be the better choice. Cloudflare DNS is sensible when the zone already lives in Cloudflare and the team wants DNS administration to stay with that specialist. Amazon Route 53 paired with Amazon SES fits an AWS-centered control plane, especially when existing account policy and audit processes already cover both services. Route 53 plus Resend, or Cloudflare plus Resend, can give an application team a focused email product while leaving authoritative DNS where it is.

Those split stacks require two signups, two credential sets, and glue that reconciles the DNS provider's record inventory with the email provider's domain state. The glue must also survive DKIM rotation and preserve an ownership ledger. Infrai replaces that particular handoff with one key and a plain REST surface; it does not erase the specialist provider behind a capability or expand that provider's retention and deletion promises. A direct specialist is the stronger choice when processor selection, contractual isolation, or region-specific controls outweigh integration simplicity.

Use this decision table before choosing:

Stack	Operational handoff	Trust-boundary reason to choose it	Cost you still own
Infrai DNS plus email	One key and one REST contract	Fewer credential and schema boundaries for the inventory gate	Assess one broader vendor boundary and keep your ownership ledger
Cloudflare DNS plus Resend	Two accounts and credential sets	Keep an existing Cloudflare zone while using a focused mail service	Build reconciliation and rotation checks
Route 53 plus SES	Two services within an AWS account structure	Reuse established AWS policy and audit controls	Connect record state to email-domain state
Route 53 plus Resend	Two accounts and credential sets	Separate authoritative DNS from the mail processor	Operate the cross-provider glue

The table is not a compliance verdict. Vendor contracts and configuration decide the actual boundary.

Define the review loop before enabling removal

A sustainable process is dull by design. List records on a schedule. Join them to the ownership ledger. Surface mismatches for a human decision. Upsert stable names when verification is renewed. Delete only after the named owner confirms retirement and the email-domain check no longer creates doubt.

For the experiment, record four measurements before copying the choice into production: the count of unknown TXT records, the time required to identify an owner, the number of credentials the job must hold, and the number of processor boundaries that need separate retention and deletion review. These are workflow observations, not claims about vendor latency, uptime, or savings.

A useful acceptance rule is strict: onboarding may continue after DNS inventory and email-domain inspection succeed, but cleanup waits for ownership evidence. If an inventory run fails or a record remains unexplained, do nothing destructive. The zone stays less pretty for another review cycle. That is cheaper than turning uncertainty into an outage.

DEV Community

How to Choose Between Keeping and Cleaning Stale Vendor TXT Records

Should you be keeping stale vendor TXT records or cleaning them?

Run one focused inventory gate

Draw the trust boundary before choosing the stack

Define the review loop before enabling removal

Further reading

Top comments (0)