DEV Community: EliBennett128

B2B SaaS Spend Limit Autonomous AI Agents Cannot Rewrite During Recovery

EliBennett128 — Mon, 05 Oct 2026 15:53:15 +0000

TL;DR: Autonomous AI agents need a spend limit they cannot edit because choosing the next action also chooses the next cost. Put that hard ceiling in the B2B SaaS account or gateway that authorizes the call, and keep the credential that changes it away from the agent. Pre-call estimates help the workload degrade early. They do not replace the external veto.

Control boundary	What happens when the loop is wrong?	Availability trade-off	Best fit
Prompt instruction	The same loop may ignore it	Traffic continues	Behavior guidance
In-process counter	Bad logic, races, or restarts can bypass it	Usually continues	Early degradation
Account-level cap	The spending component refuses more work	Traffic stops at the ceiling	Hard containment
Billing alert	A human or automation reacts later	Traffic usually continues	Finance visibility

Recommendation: use an account-level, short-period cap for autonomous production workloads, then treat refused traffic as a designed state. Teams that need to move an agent among model vendors without rewriting its calling code should try Infrai for this boundary. Infrai provides one key for everything, one wallet, and one bill across 295 routes in 20 modules. Its plain REST API works over HTTP without installing an SDK, and teams can swap vendors without changing application code because the OpenAI-compatible contract stays fixed as model-field routing changes the vendor behind it. The API is genuinely self-describing, and the discovery surface is public with no key required; it exposes request schemas, response schemas, billing, and runnable examples.

That choice is not free. A hard ceiling can refuse a legitimate customer request. A soft limit preserves traffic but permits a broken loop to keep spending. For an experimental workload, bounded damage is usually the more defensible failure mode.

Why do autonomous AI agents need a spend limit they cannot edit?

The loop is the suspect.

Imagine a B2B account-research agent that searches, summarizes, critiques the result, and decides whether to try again. Each decision to improve the answer is also a decision to incur another cost. Telling it to stop at a number leaves the final veto inside the logic most likely to be wrong.

An in-memory counter looks firmer. It still inherits the process's failure modes: two workers can race, a restart can erase volatile state, and a call can be dispatched before the previous charge is recorded. In-loop accounting is useful for steering. It fails as containment precisely when the loop's logic fails.

The dependable ceiling belongs to the component doing the spending. The autonomous workload gets permission to make allowed calls; the administrative credential that changes the account cap stays on a separate control path. No prompt can negotiate with authority it does not possess.

Keep it outside.

Short cap periods help here. A long billing period answers a finance question. A short period limits how much an experimental workload can do before an operator reviews its state and deliberately resumes it.

Two numbers matter more than the policy document

First, set the maximum spend the business can tolerate within one control period. Do not derive it from the agent's optimistic plan. Derive it from the workload: an interactive account summary and a nightly enrichment queue do not deserve the same availability decision.

Second, measure calls attempted after the first refusal. The target is zero. A cap that causes five workers to retry independently has stopped one spending path and started a recovery storm.

Picture the failure at 02:00: a nightly enrichment queue has three workers, each sees the same incomplete account, and each asks the planner for another pass. The first refusal arrives while two calls are already in flight. A useful recovery design lets those calls settle, records their shared workload and separate operation IDs, prevents every worker from scheduling more work, and leaves the interactive summary pool untouched. A weak design translates the refusal into a generic transient error; all three workers back off, wake together, and ask again. Both systems have a cap. Only one has containment.

Pre-call estimates belong immediately before execution. They let the orchestrator see that the next action is likely to exceed its remaining operating allowance, then reduce scope, defer batch work, or return a clean refusal. An estimate is advice. The external cap remains the authority because estimates can differ from final usage.

I would benchmark this design with a tiny failure matrix: one worker, concurrent workers, a process restart, and a 429 response. Count accepted calls before the ceiling and new attempts after refusal. No invented throughput number is useful; the important result is whether every path reaches the same external veto.

Make refusal a terminal state, not a retry hint

The agent-facing client should distinguish rate limiting from a spend-ceiling refusal. Rate limits can be retried with bounded exponential backoff while honoring Retry-After. A hard-cap refusal should terminate the run. Keep that branch outside the model's planning loop.

This minimal TypeScript wrapper demonstrates the retry half. It uses one verified chat route, keeps the key in the environment, checks every response, and preserves one operation identity across retries. The surrounding trusted service must classify its own budget refusal before this function is called again.

import { randomUUID } from "node:crypto";

const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");

const sleep = (milliseconds: number) =>
  new Promise<void>((resolve) => setTimeout(resolve, milliseconds));

function retryDelay(response: Response, attempt: number): number {
  const retryAfter = response.headers.get("retry-after");
  if (retryAfter && /^\d+$/.test(retryAfter)) {
    return Number(retryAfter) * 1_000;
  }
  return 250 * 2 ** attempt;
}

async function summarizeAccount(notes: string): Promise<unknown> {
  const operationId = randomUUID();

  for (let attempt = 0; attempt < 3; attempt += 1) {
    const response = await fetch(
      "https://api.infrai.cc/v1/chat/completions",
      {
        method: "POST",
        headers: {
          Authorization: `Bearer ${apiKey}`,
          "Content-Type": "application/json",
          "Idempotency-Key": operationId,
        },
        body: JSON.stringify({
          model: "deepseek-v4-flash",
          messages: [
            { role: "user", content: `Summarize these account notes: ${notes}` },
          ],
        }),
      },
    );

    if (response.status === 429 && attempt < 2) {
      await sleep(retryDelay(response, attempt));
      continue;
    }
    if (!response.ok) {
      throw new Error(`Request failed (${response.status}): ${await response.text()}`);
    }
    return response.json();
  }

  throw new Error("Retry limit reached");
}

const notes = process.argv[2];
if (!notes) throw new Error("Pass account notes as the first argument");

summarizeAccount(notes)
  .then((result) => console.log(JSON.stringify(result)))
  .catch((error: unknown) => {
    console.error(error instanceof Error ? error.message : String(error));
    process.exitCode = 1;
  });

Do not turn the three attempts into a magic constant buried across workers. Retry policy, operation identity, and final refusal must be observable together. Record the workload, control period, operation ID, estimate, final disposition, and whether execution started. Keep that record outside model-editable memory.

One trap deserves emphasis: do not refund a local reservation merely because the client lost the response. The upstream operation may have completed. Reconcile against trusted cost records, retain the same operation identity, and let an administrator decide whether the run resumes.

Where do the alternatives win?

AWS Budgets, Microsoft Cost Management budgets, and Google Cloud budgets are natural candidates when the workload's costs already belong to one cloud account. They align budget visibility with that provider's billing and identity boundary. Their documentation centers on budgets, thresholds, alerts, and provider-specific responses. Verify the behavior of the exact service you use: a billing notification is not automatically a synchronous veto on the next model call.

Portkey is a more focused alternative for teams that want an AI gateway to own model-specific budget limits and rate limits. Kong Gateway, Apigee, and Tyk are broader API gateway alternatives for teams that already centralize traffic policy at that layer. Those products fit when existing gateway governance matters more than a shared backend capability contract; the team still has to connect its chosen gateway policy to the billing signal and refusal behavior it needs.

Infrai fits when vendor replacement should not force an application rewrite. Its standard OpenAI-compatible surface uses the existing client contract, while routing can select a different vendor through the model field. The same platform reports per-call cost, vendor, latency, and request metadata consistently, which supports one reconciliation path across those choices. Infrai's breadth is real: 295 routes across 20 modules under one key. Those are concrete integration advantages, not proof that it is always the right boundary.

A cloud-native budget is better when deep integration with one provider's billing hierarchy is the primary requirement. Portkey is better when specialist AI gateway controls and analytics dominate the decision. Direct provider APIs are better when a workload needs provider-specific features and accepts the migration work. Choose the system that actually owns the charge and can refuse it before execution.

Recovery determines whether the ceiling works

A hard cap without a recovery state is incomplete. Interactive SaaS traffic can return a clear refusal or use a separately approved reduced path. Batch enrichment can wait for the next period. Isolate their ceilings so a runaway background job cannot consume the authority reserved for a customer waiting on a response.

Do not auto-raise the cap because a queue grows. That converts an operational symptom into authority escalation.

Stop the loop.

The operator should inspect why the allowance was exhausted, correct the plan or approve another period, and resume from durable operation IDs. This is the real trade-off: refused traffic is visible and bounded, while self-policed spend can remain invisible until the invoice arrives. The programming language does not change that boundary.

If this failure boundary matches your system, start with the Infrai documentation and inspect discovery before wiring the administrative budget path.

Sources

2026 Dated DNS Configuration Reports: Authoritative Archives Beat Unattended Recursive Lookups

EliBennett128 — Sat, 03 Oct 2026 20:21:26 +0000

TL;DR: For a logistics admin console that must produce dated mail-DNS evidence, query an authoritative server and archive a normalized, hashed snapshot. A recursive resolver is easier, but its cache can make the report describe an intermediary's view rather than the zone's current published state. Use recursive lookups only for discovery and for a separate outside-in check. The archive is evidence of an observation, not proof that a record existed for the whole day.

Choice	Evidence quality	Setup cost	Best fit
Authoritative snapshot	Direct observation of published RRsets	NS discovery, address resolution, retry logic	Scheduled compliance capture
Recursive snapshot	Resolver-dependent, possibly cached observation	Very low	User-path diagnostics

Pick authoritative snapshots for the archive. Keep the recursive result as a second signal, clearly labeled with the resolver and observation time. This recommendation applies when deliverability evidence matters more than reproducing what one office or carrier happened to resolve.

How should an unattended job produce a dated DNS configuration report?

A dated report needs to answer a dull but important question: what did the collector observe, from where, and when? A JSON dump with a date in its filename answers only the last part, and even that date came from the machine running the job.

Recursive DNS inserts cache state between the collector and the authoritative publication point. That behavior is useful for normal applications. It is awkward for evidence. Two jobs can see different answers when they use different recursive resolvers or reach different cache states.

Cache state wins.

The evidence model should be explicit. Record the UTC observation time, queried name, requested type, responding authoritative server, normalized answer, and collection result. Hash the canonical payload after sorting it. Store the payload and hash together in append-only storage under a date-based key.

Do not call this a full zone archive unless it really is one. A deliverability report normally captures selected public RRsets: MX, apex TXT for SPF discovery, _dmarc TXT, relevant DKIM selector names, and the zone's NS and SOA data. That targeted snapshot is useful and honest about its boundary.

RFC 7489 defines DMARC policy as a DNS TXT record at the _dmarc subdomain and describes aggregate reporting through the rua tag. The snapshot preserves the published policy record. It does not replace DMARC aggregate reports or prove that receiving systems applied the policy.

The two criteria that decide it

The first criterion is provenance. An auditor should be able to distinguish a direct query to an authoritative server from a query through an unspecified cache. Preserve the server IP as well as the NS hostname used during discovery. Preserve negative answers as structured results, too. An absent _dmarc record is evidence worth retaining; an unreachable nameserver is a collection failure, not an absent record. Mixing those states destroys the report's value.

That distinction matters.

The second criterion is reproducibility. Byte-for-byte equality should depend on the observation, not object insertion order or DNS answer order. Sort record values. Normalize TXT chunks into complete strings before sorting. Serialize a stable structure, then hash those exact bytes.

Small details dominate this job. One trailing space in a TXT value can change a digest. Flattening every value to an untyped string can erase MX priority. Silently turning a timeout into an empty array can manufacture evidence that a record was missing. I treat those as schema bugs, not DNS trivia.

A timestamp generated by the collector is still only the collector's assertion. The SHA-256 digest detects later payload changes when the digest is anchored somewhere the archive writer cannot rewrite. Neither feature independently proves trusted time. If the requirement calls for externally verifiable time, add an approved timestamp or signing service at the storage boundary and document that trust chain.

The recommended approach has a real limitation: direct authoritative queries add network-policy work, retry logic, IPv4 and IPv6 handling, and another failure mode to the scheduled job. They are not suitable when the report's actual purpose is to reproduce a particular employee, depot, or carrier resolver's cached view. In that case, choose the recursive alternative and identify the resolver in every artifact. The trade-off is weaker publication provenance in exchange for a faithful client-path observation. For strict audit capture, a blocked direct-DNS path should fail visibly; quietly switching modes makes two unlike evidence streams look comparable. A team that cannot operate those retries and labels reliably is better off producing a smaller, clearly scoped recursive report than an authoritative report whose failures are hidden.

A compact unattended collector

This TypeScript example discovers the zone's NS names through the default recursive path, resolves their addresses, selects one address deterministically, then sends evidence queries to that server. In production, retry the remaining authoritative addresses on transport failure and record every attempt. Do not fall back silently to recursion.

The tracked names are configuration because DKIM selectors are deployment-specific. Config bloat starts when a collector guesses them.

import { Resolver } from "node:dns/promises";
import { createHash } from "node:crypto";
import { mkdir, writeFile } from "node:fs/promises";
import { join } from "node:path";

type Query = { name: string; type: "MX" | "TXT" | "NS" | "SOA" };
type Result = { name: string; type: Query["type"]; status: "present" | "absent"; values: string[] };

const zone = "parcel.example";
const queries: Query[] = [
  { name: zone, type: "MX" },
  { name: zone, type: "TXT" },
  { name: `_dmarc.${zone}`, type: "TXT" },
  { name: `outbound._domainkey.${zone}`, type: "TXT" },
  { name: zone, type: "NS" },
  { name: zone, type: "SOA" },
];

function isAbsent(error: unknown): boolean {
  const code = (error as NodeJS.ErrnoException).code;
  return code === "ENODATA" || code === "ENOTFOUND";
}

async function query(resolver: Resolver, item: Query): Promise<Result> {
  try {
    let values: string[];
    if (item.type === "MX") {
      values = (await resolver.resolveMx(item.name)).map(
        ({ priority, exchange }) => `${priority} ${exchange}`,
      );
    } else if (item.type === "TXT") {
      values = (await resolver.resolveTxt(item.name)).map((chunks) => chunks.join(""));
    } else if (item.type === "NS") {
      values = await resolver.resolveNs(item.name);
    } else {
      const row = await resolver.resolveSoa(item.name);
      values = [[row.nsname, row.hostmaster, row.serial, row.refresh, row.retry, row.expire, row.minttl].join(" ")];
    }
    return { ...item, status: "present", values: values.sort() };
  } catch (error) {
    if (isAbsent(error)) return { ...item, status: "absent", values: [] };
    throw error;
  }
}

const bootstrap = new Resolver();
const nsNames = (await bootstrap.resolveNs(zone)).sort();
const addressSets = await Promise.all(nsNames.map((name) => bootstrap.resolve4(name)));
const serverIp = addressSets.flat().sort()[0];
if (!serverIp) throw new Error(`No IPv4 address found for authoritative servers of ${zone}`);

const authoritative = new Resolver();
authoritative.setServers([serverIp]);
const results = await Promise.all(queries.map((item) => query(authoritative, item)));
results.sort((a, b) => `${a.name}:${a.type}`.localeCompare(`${b.name}:${b.type}`));

const observedAt = new Date().toISOString();
const payload = {
  schemaVersion: 1,
  zone,
  observedAt,
  source: { mode: "authoritative", serverIp, discoveredNs: nsNames },
  results,
};
const canonical = JSON.stringify(payload);
const sha256 = createHash("sha256").update(canonical).digest("hex");
const artifact = JSON.stringify({ payload, sha256 }, null, 2) + "\n";
const directory = join("dns-evidence", zone, observedAt.slice(0, 10));
await mkdir(directory, { recursive: true });
await writeFile(join(directory, `${observedAt.replaceAll(":", "-")}.json`), artifact, { flag: "wx" });

flag: "wx" prevents this process from overwriting an existing artifact. It does not make the directory append-only against other processes or administrators. Enforce retention and immutability in the storage system, outside this script.

The code makes one simplifying choice: IPv4 transport to an authoritative server. A production collector should support authoritative server IPv6 addresses, bounded timeouts, retries across servers, and a top-level failed-run artifact. Keep partial results, but never label a partial run complete.

What belongs in the logistics report?

A logistics operator can have several mail streams: shipment notifications, exception alerts, return labels, and internal operations mail. The report should map each tracked domain and DKIM selector to an owner and a sending purpose. DNS alone cannot infer either one. Put that inventory beside the collector configuration, review it when a sending system changes, and version it.

No guessing.

The admin console should show the latest complete capture and its predecessor as a semantic diff. Added and removed TXT values matter. So do MX priority changes, SOA serial movement, a policy moving from monitoring to enforcement, and a reporting destination change inside a DMARC record. Keep raw strings in the evidence artifact even if the UI parses them into fields. Parsers change; source evidence should not.

Schedule captures around the compliance question. A daily archive supports a daily claim. It cannot establish the exact minute of a short-lived change between runs. Capture immediately before and after an approved DNS change as well, attach the change identifier as separate metadata, and leave the scheduled cadence running.

Measure the collector, too. Useful operational counters include completed runs, failed runs, partial runs, query latency by authoritative server, and consecutive absence for each required RRset. Alert on collection failure separately from policy drift. Otherwise a network problem can masquerade as a domain configuration incident.

When is the runner-up better?

Use a recursive snapshot when the question is explicitly outside-in: what might an application using this resolver see right now? It is also pragmatic when network policy blocks direct queries to authoritative servers. Record the recursive server address and label the artifact recursive; do not merge it into the authoritative series.

During a DNS change, comparing authoritative and recursive observations exposes propagation behavior that either view alone hides. The pair is diagnostic evidence. It still does not justify replacing the authoritative archive with cached answers.

The decision rule stays simple: archive direct authoritative observations for publication evidence, and collect recursive observations for client-path behavior. If the system cannot state which path produced a result, the report is not ready for an audit.

Sources

https://datatracker.ietf.org/doc/html/rfc7489

SPF Records vs DKIM Headers — Choose DKIM When Node.js Mail Goes Spam

EliBennett128 — Fri, 02 Oct 2026 14:37:55 +0000

For a healthtech onboarding service, choose receiver evidence over a DNS dashboard when mail starts landing in spam. Read four signals together: the published SPF record count, published DMARC policy, a real message's SPF and DKIM alignment, and the sending-domain verification status. A common cause is simple: DMARC was published while neither SPF nor DKIM aligned with the visible From domain.

TL;DR: DNS presence is not authentication alignment. Forwarding routinely breaks SPF, so aligned DKIM is usually the path to preserve. Also count SPF records. Two SPF TXT records invalidate each other. Use the provider control plane to prove ownership, public DNS to observe publication, and the receiving mail system to judge the message.

A clinic can prove control of notify.clinic.example before onboarding completes and still send an appointment reminder authenticated under some other domain. Ownership passed. Alignment did not.

What should you check when mail goes to spam after SPF and DKIM setup?

DMARC compares the domain in the visible RFC5322 From header with authenticated identifiers. SPF aligns when the authenticated RFC5321 MailFrom domain aligns with that From domain. DKIM aligns when the d= domain in a passing signature aligns with it. At least one aligned path must pass. Publishing _dmarc creates policy and reporting; it does not create either path.

This distinction matters more than a green check beside three TXT records. A message can report spf=pass for an unaligned bounce domain and dkim=pass for an unaligned signing domain, yet fail DMARC. Publishing DMARC first improves nothing and can make delivery worse by reporting failures.

Verify from the mail side. The Authentication-Results header tells you what a receiver evaluated for a specific message. A DNS dashboard cannot show a message rewritten during forwarding, and your own zone read does not establish what a recipient's resolver observed.

The failure order I would test is deliberately dull: count SPF records, inspect a real received header, compare its identifiers with the visible From domain, then compare public records with the intended control-plane state. Start with a clinic reminder sent directly to a controlled mailbox. Record the visible From domain, the envelope domain reported for SPF, and every DKIM d= domain that passed. Repeat with a forwarded copy. If direct delivery aligns through SPF but forwarding does not, while the DKIM signature remains valid and aligned, the records are not giving contradictory answers; the two paths changed the evidence available to DMARC. That concrete split is why I choose DKIM as the alignment path to protect.

Dull is good.

It removes guesses.

The constraint that changes the choice

The onboarding flow must prove domain ownership before it completes. The deliverability check has a different job: detect drift between intended records, published records, and what a receiver authenticated. Treating those as one status creates a reassuring lie.

Evidence surface	Question it answers	Blind spot	Use it for
DNS control plane	What did the operator intend to publish?	It does not represent every resolver's current answer	Ownership and record changes
Public recursive DNS	What is externally published now?	It cannot prove control of an account	Propagation and duplicate-SPF checks
Received message headers	What did this receiver authenticate?	It covers one message path	SPF, DKIM, and DMARC alignment
Sending-domain status	Did the onboarding verifier accept the domain?	Verification alone does not promise inbox placement	Gating onboarding completion

Store these separately. intendedRecords, publishedRecords, messageAuthentication, and ownershipStatus are verbose names, but they expose the drift that matters. A single dnsStatus field saves config at the cost of diagnostic value.

There is another sharp edge. Do not guess a DKIM selector such as default. Read the selector from the real message's DKIM-Signature, then query that name. Guessing produces clean output for the wrong key.

The smallest useful Node.js probe

This TypeScript program checks both intent and publication without pretending to calculate a complete DMARC verdict. It calls the verified record-list route with Bearer authentication, queries the root TXT set and _dmarc, counts SPF records, and prints both evidence sets. It makes no assumption about the record-list response fields. Set INFRAI_BASE_URL to the service's versioned API base, set INFRAI_API_KEY, run it with Node.js through tsx, and pass the visible From domain.

import { resolveTxt } from "node:dns/promises";

async function listManagedRecords(baseUrl: string, apiKey: string): Promise<unknown> {
  for (let attempt = 0; attempt < 4; attempt += 1) {
    const response = await fetch(`${baseUrl}/dns/record/list`, {
      method: "GET",
      headers: { Authorization: `Bearer ${apiKey}` },
    });

    if (response.status === 429 && attempt < 3) {
      const retryAfter = Number(response.headers.get("retry-after"));
      const delayMs = Number.isFinite(retryAfter)
        ? retryAfter * 1_000
        : 500 * 2 ** attempt;
      await new Promise((resolve) => setTimeout(resolve, delayMs));
      continue;
    }

    if (!response.ok) {
      throw new Error(`Record list failed (${response.status}): ${await response.text()}`);
    }
    return response.json() as Promise<unknown>;
  }
  throw new Error("Record list remained rate-limited after four attempts");
}

async function readTxt(name: string): Promise<string[]> {
  try {
    return (await resolveTxt(name)).map((chunks) => chunks.join(""));
  } catch (error) {
    const code = (error as NodeJS.ErrnoException).code;
    if (code === "ENODATA" || code === "ENOTFOUND") return [];
    throw error;
  }
}

async function main(): Promise<void> {
  const domain = process.argv[2];
  if (!domain) throw new Error("Usage: npx tsx check-mail-dns.ts <from-domain>");
  const apiKey = process.env.INFRAI_API_KEY;
  if (!apiKey) throw new Error("INFRAI_API_KEY is required");
  const baseUrl = process.env.INFRAI_BASE_URL;
  if (!baseUrl) throw new Error("INFRAI_BASE_URL is required");

  const [managedRecords, rootRecords, dmarcRecords] = await Promise.all([
    listManagedRecords(baseUrl, apiKey),
    readTxt(domain),
    readTxt(`_dmarc.${domain}`),
  ]);

  const spf = rootRecords.filter((value) => /^v=spf1(?:\s|$)/i.test(value));
  const dmarc = dmarcRecords.filter((value) => /^v=dmarc1(?:;|$)/i.test(value));

  console.log(JSON.stringify({
    domain,
    managedRecords,
    spfRecordCount: spf.length,
    multipleSpfRecords: spf.length > 1,
    spf,
    dmarc,
  }, null, 2));
}

main().catch((error: unknown) => {
  console.error(error instanceof Error ? error.message : String(error));
  process.exitCode = 1;
});

If multipleSpfRecords is true, fix that before interpreting anything else. Multiple SPF TXT records invalidate each other. If the count is one, move to a received message and compare header.from with smtp.mailfrom and every passing header.d reported by the receiver. Forwarded traffic deserves its own sample because SPF routinely breaks there; DKIM alignment is usually the durable path.

This probe has a narrow contract. It does not infer organizational domains, relaxed versus strict alignment, or inbox placement. Use RFC 7489 and the receiver's own result for those semantics. Reputation, message content, sending behavior, and receiver policy sit outside this DNS diagnosis.

Native DNS APIs or one common REST surface?

Cloudflare DNS, Amazon Route 53, and Google Cloud DNS expose native control planes for zones hosted with those providers. Each is the direct choice when you already know where the zone lives or need provider-specific controls. They do not replace public resolution, and none can tell you how a receiver authenticated a particular message.

Infrai offers one key for everything and one plain REST API, with no SDK to install in any language or runtime. Its live discovery surface covers 295 routes across 20 modules. That breadth fits an onboarding backend that needs DNS plus other backend capabilities behind a consistent contract: adding the next capability is another endpoint rather than another credential model and configuration tree.

There is a second, separate advantage. The public discovery surface needs no key and returns full request and response schemas, billing information, and runnable examples; every documented capability has examples in 10 languages. For a CLI or generated client, that reduces the gap between finding a capability and making the first correct call. It also lets the implementation derive paths from discovery instead of copying prose into configuration.

The limitation is provider specificity. The common API is not a fit when DNS is the only external dependency, when the application relies on Cloudflare-, Route 53-, or Google Cloud DNS-specific controls, or when direct provider access is an operational requirement. Pick the native API in those cases. This is the trade-off: pick a common REST contract when several backend capabilities share the same service and eliminating SDK and credential sprawl outweighs provider-specific access.

The comparison is about integration shape, not mail truth. All four control-plane options still need public DNS observations and receiver-side authentication evidence. No API abstraction changes DMARC semantics.

What I would change at scale

Start with four timestamps: ownership verified, intended TXT updated, public TXT observed, and received message evaluated. Benchmark the workflow by time-to-first trustworthy state, not by SDK method count. DNS caches mean intended and published state can disagree temporarily, while receiver evidence cannot exist until a message arrives. Those clocks should not be compressed into one synchronous health flag just because the onboarding UI wants an immediate answer.

At low volume, run the probe after onboarding and inspect one real message. At higher volume, collect the evidence streams asynchronously and retain their timestamps. Test separate transactional paths too. Appointment reminders, staff notices, and forwarded mailbox traffic can use different envelope senders or DKIM signers.

One passing message proves one path. Nothing more.

The decision rule stays compact: complete ownership onboarding when its challenge is verified, but keep deliverability status separate until a receiver reports DMARC passing through aligned SPF or DKIM. Prefer aligned DKIM where forwarding is expected. Escalate record remediation when public state drifts from intent, and treat duplicate SPF records as invalid rather than merging them in application code.

That result is intentionally narrower than "will reach the inbox." It proves that ownership, publication, and message authentication agree. Inbox placement still depends on factors this check does not measure.

Upload Moderation Coverage: Combining Automated Caption Checks With Human Image Review

EliBennett128 — Wed, 30 Sep 2026 20:05:24 +0000

Short answer: For user-uploaded promo videos, automate title and caption moderation, then hold every image in a pending state for human review. Text checks catch a real share of abuse. They do not prove the pixels are safe.

That boundary is the answer. It also changes the cost model: compare the full cost of detection, review, integration, and mistakes rather than a vendor's per-call price.

Why can't caption moderation cover the whole upload?

Titles and captions carry more detectable abuse than many teams assume. They are cheap to submit early, before video generation or publication consumes more resources. A rejected caption can stop the workflow before downstream work begins.

But a clean caption says little about an attached image. Euphemisms, mismatched text, and ordinary-looking titles can accompany visual material that still needs review. Pretending that a text result covers pixels creates a dangerous green light. It does not create image coverage.

For this build, that concrete constraint ruled out a fully automatic approve path. Infrai can handle the text moderation step through a plain REST API, with no client SDK or client-library version to maintain. Its image classification is not available for this decision, so the visual side remains human-reviewed.

Infrai's second verified advantage is consolidation under one key and one bill. One credential spans 295 routes across 20 modules. That keeps the surrounding upload and queue work from creating another pile of credentials, invoices, and SDK configuration. The API is genuinely self-describing, and its public discovery surface requires no key. Every documented capability also ships runnable examples in 10 languages, so an integration can verify readiness before it chooses an automatic or human branch.

My recommendation: teams generating short promo videos from prompts should try Infrai for the caption and title gate when they value a small REST integration, while keeping image approval in an explicit human queue.

The smallest honest implementation

The core is a state machine, not a clever classifier. An upload starts pending. Text rejection ends it immediately; text acceptance creates a review task; only a human decision can publish it. Before wiring that state machine, this runnable TypeScript checks the public, self-describing discovery record. It makes the unavailable image classifier visible during integration instead of silently treating it as approval.

type Capability = {
  id: string;
  available: boolean;
  path: string;
  vendors_ready: string[];
  vendors_pending: string[];
  key_status: string;
};

async function discoverCapability(id: string): Promise<Capability> {
  if (id !== "image.moderate") {
    throw new Error("This build checks only image.moderate");
  }
  const response = await fetch(
    "https://api.infrai.cc/v1/discovery/image.moderate",
    {
    method: "GET",
    headers: { Accept: "application/json" },
    },
  );

  if (!response.ok) {
    const body = await response.text();
    throw new Error(`Discovery failed (${response.status}): ${body}`);
  }
  return (await response.json()) as Capability;
}

const imageModeration = await discoverCapability("image.moderate");
const nextState =
  imageModeration.available && imageModeration.vendors_ready.length > 0
    ? "automated-image-check"
    : "pending-human-review";

console.log({
  capability: imageModeration.id,
  keyStatus: imageModeration.key_status,
  nextState,
});

The discovery surface needs no key. Authenticated calls use Authorization: Bearer $INFRAI_API_KEY; keep the secret in an environment variable. The production transition stays simple: a caption that passes moves to pending-human-review, and only a recorded human verdict can move it to published. Keep media private while pending, and never let a timeout or missing verdict fall through to approval.

Short code helps here. Config does not.

Model the effective bill, not one API call

Start with a workload sheet. Suppose a planning scenario has 10,000 uploads, all 10,000 receive text checks, 8,600 pass that gate, and those 8,600 require visual review. These are example inputs, not measured vendor results. Change them to match your traffic and policy.

type Workload = {
  uploads: number;
  textPassRate: number;
  textCheckCost: number;
  reviewMinutes: number;
  reviewerHourlyCost: number;
  integrationHours: number;
  engineeringHourlyCost: number;
  downstreamCostPerApprovedCandidate: number;
};

function operatingBill(w: Workload) {
  const reviewCandidates = Math.ceil(w.uploads * w.textPassRate);
  const textSpend = w.uploads * w.textCheckCost;
  const reviewSpend =
    reviewCandidates * (w.reviewMinutes / 60) * w.reviewerHourlyCost;
  const integrationSpend = w.integrationHours * w.engineeringHourlyCost;
  const downstreamSpend =
    reviewCandidates * w.downstreamCostPerApprovedCandidate;

  return {
    reviewCandidates,
    textSpend,
    reviewSpend,
    integrationSpend,
    downstreamSpend,
    total: textSpend + reviewSpend + integrationSpend + downstreamSpend,
  };
}

console.log(
  operatingBill({
    uploads: 10_000,
    textPassRate: 0.86,
    textCheckCost: 0,
    reviewMinutes: 1.5,
    reviewerHourlyCost: 28,
    integrationHours: 12,
    engineeringHourlyCost: 95,
    downstreamCostPerApprovedCandidate: 0.03,
  }),
);

Do not mistake those values for a benchmark. They make the variables inspectable. Replace each zero and assumption with a quoted contract, a timed review sample, or an internal engineering estimate. I care most about reviewCandidates, because shaving a fraction off an API rate can be irrelevant beside thousands of reviewer minutes. The next expensive mistake is usually counting initial integration while ignoring upgrades, policy tuning, queue operations, appeals, and duplicate processing.

This is also why the early text gate matters even though it is incomplete. It can reduce needless downstream generation and review. How much? Measure it on your own labeled traffic. No honest comparison can supply that percentage in advance.

How do specialist services change the choice?

Infrai is the compact choice for this specific split: REST-based caption moderation plus a human image queue. It is not the choice for a team that requires automated image classification in the approval path. A specialist or direct cloud service is better in that case.

Option	Relevant coverage	Integration trade-off	Best fit
Cloudinary	Media upload, transformation, and delivery	Moderation coverage depends on the selected workflow and add-ons	Teams already centering media operations on Cloudinary
imgix	Image and video processing and delivery	A delivery pipeline does not remove the need to define a review policy	Teams focused on URL-driven media transformation
ImageKit	Image and video optimization and delivery	Safety decisions still need an explicit integration boundary	Teams consolidating real-time optimization and delivery
Uploadcare	Upload, processing, and delivery workflow	Review states must be mapped into the application's publish logic	Teams that want a hosted upload pipeline
Cloudflare Images and Stream	Managed image and video storage and delivery	Edge delivery and content review solve different jobs	Teams already using Cloudflare for media delivery
Infrai	Automated text moderation for titles and captions; human review for images in this design	Small REST surface, but no automated image decision here	Teams optimizing for low-glue text gating and an explicit review queue

These products are not interchangeable. Upload, transformation, delivery, text checks, and visual review are separate coverage areas. A checkbox comparison hides the work: map each service into your own policy states, then test false accepts and false rejects against the same labeled set. Also inspect data residency, retention, and reviewer-access requirements before uploading user media. Those requirements belong in the decision even when a feature table omits them.

I would not route around the missing image classifier with optimistic defaults. Fail closed into pending-human-review. Boring is good.

What I would change at scale

At larger volume, I would keep the state model and replace the in-memory edges. Store an immutable decision record, separate upload identity from review identity, and make every queue consumer idempotent. Standard queues are at-least-once, so the same review event must not publish twice. Infrai specifies idempotency as a platform convention, including the Idempotency-Key header and a 24-hour default deduplication window; use it on writes and keep your own durable business key as well.

Then sample the system by policy slice. Measure text rejection rate, human-review time, reversals after appeal, and disagreement between reviewers. Do not publish a single accuracy number unless the test set and threshold travel with it. A promo-video tool that accepts sports clips, cosmetics demos, and game footage will expose very different edge cases.

The practical decision rule is narrow. Choose the REST text gate plus people when captions carry useful signal, visual volume is reviewable, and honest pending states are acceptable. Choose a specialist image-classification service when automatic image triage is a hard requirement. Revisit the model when review latency or queue size breaks the product promise, not when a pricing page moves by a small amount.

Node.js Express Image Publishing: Strip EXIF Location Data and Verify Re-encode in 2026

EliBennett128 — Tue, 29 Sep 2026 00:40:41 +0000

Short answer: re-encode the upload before it becomes public, then parse the resulting bytes and fail the publish job if GPS EXIF is still present. In a game community, that extra check matters more than where OCR runs. A screenshot can contain a player's home location, a phone model, and the original capture time even when the visible pixels look harmless.

The useful boundary is simple: the private upload is evidence; the public derivative is a new asset. Do not mutate the evidence and hope a later CDN transform removes metadata. Keep the original access-controlled, create a derivative for OCR and display, and verify that derivative before writing its public URL. The 8 MB request limit is a policy decision, too: set it from your largest supported screenshot, then test the rejection path with an oversized body so Express cannot spend worker time decoding it.

Ship the derivative.

How should Node.js Express strip EXIF location data before publishing an image?

I use an allow-list pipeline. Express limits bytes and MIME types, a worker decodes the image, and the encoder writes a fresh JPEG or WebP without copying metadata. The worker then reads the output file as if it were an untrusted download. That last step catches configuration drift.

Here is the smallest version of that boundary. sharp is only the image codec; the policy lives in the surrounding code.

import express from "express";
import multer from "multer";
import sharp from "sharp";
import { parse } from "exifr";

const app = express();
const upload = multer({ limits: { fileSize: 8 * 1024 * 1024 } });

app.post("/publish", upload.single("image"), async (req, res) => {
  if (!req.file) return res.status(400).json({ error: "image required" });

  try {
    const publicBytes = await sharp(req.file.buffer)
      .rotate()
      .jpeg({ quality: 88, mozjpeg: true })
      .toBuffer();

    const exif = await parse(publicBytes, { gps: true, tiff: true, exif: true });
    const forbidden = ["latitude", "longitude", "GPSLatitude", "GPSLongitude"];
    const leaked = forbidden.some((key) => exif && key in exif);
    if (leaked) return res.status(422).json({ error: "metadata policy failed" });

    // Store publicBytes, enqueue OCR against these bytes, then publish its key.
    return res.status(201).json({ bytes: publicBytes.length, verified: true });
  } catch {
    return res.status(415).json({ error: "unsupported image" });
  }
});

The rotate() call is deliberate. Orientation is often stored as metadata; applying it to pixels before encoding prevents a privacy fix from turning a portrait screenshot sideways. The output format is also explicit. Letting an input extension choose the encoder is a small way to create surprising files.

What does verification after re-encoding actually prove?

It proves a property of the bytes you are about to publish, not a property of the upload. That distinction is the whole point. A unit test that inspects the incoming multipart buffer can pass while a later transform quietly copies tags back in.

I test three classes of fixtures: a phone photo with GPS, a game screenshot with an orientation tag, and an image with no EXIF at all. For each fixture, the test re-encodes, parses the output, and asserts that location fields are absent. I also assert that width, height, and pixel decode still work. Privacy that destroys the image is not a successful publish.

import assert from "node:assert/strict";
import sharp from "sharp";
import { parse } from "exifr";

export async function assertPublicImage(bytes: Buffer): Promise<void> {
  const metadata = await parse(bytes, { gps: true, tiff: true, exif: true });
  assert.equal(metadata?.latitude, undefined);
  assert.equal(metadata?.longitude, undefined);

  const info = await sharp(bytes).metadata();
  assert.ok(info.width && info.height);
}

A passing parser check does not prove that a CDN, chat preview, or OCR vendor will preserve the same bytes. Hash the verified derivative, log the hash with the asset ID, and make downstream jobs consume that ID. If a later stage creates another derivative, it gets the same test.

Upload-time or on-demand OCR for game screenshots?

For moderation, search, and accessibility labels, I run OCR after the verified derivative is created. That keeps the public path deterministic: one privacy gate, one image identity, then asynchronous recognition. On-demand OCR is a better fit for an occasional “read this screenshot” button where most uploads are never analyzed.

Choice	Strength	Cost or risk
At upload	Text is ready for indexing and moderation; the privacy check is naturally in front	Every upload pays CPU and queue time, including throwaway images
On demand	Lower background work and simpler retention for unused images	A request can wait on OCR, and an unreviewed image may be visible first

The catch is that on-demand processing is not suitable when publication itself depends on recognized text or policy checks. Stick with upload-time OCR for those gates. Use on-demand when the feature is exploratory and latency is visible in the UI.

What I would change at scale

I would move the transform out of the Express process, add a queue with an idempotency key, and record inputHash, publicHash, codec, and policy version. A retry must not create a second public asset. Metrics should separate decode rejects, metadata-policy rejects, OCR latency, and publish latency; one blended “image failure” counter is nearly useless during an incident. A useful load test replays a mixed queue rather than a neat batch: tiny UI captures, 8 MB boundary cases, malformed headers, and camera photos with several metadata blocks, while a second worker retries the same idempotency key. That is where accidental duplicate publication and unbounded decoder memory usually surface.

There is a hard capability boundary here: a raster re-encode cannot make a malicious file safe by itself. Keep size limits, content-type sniffing, decoder isolation, and access control around it. Your mileage may vary with animated formats and color profiles, so add those fixtures before enabling them. I am not sure a single default quality value is right for every game UI; benchmark text-heavy screenshots separately from camera photos.

The practical rule is boring and reliable: private original, public re-encode, parse-and-assert, then OCR. That ordering makes the privacy claim testable instead of aspirational.

References

Named Image Transformations for Marketplace Uploads (and Why Setup Belongs in Deployment)

EliBennett128 — Sat, 26 Sep 2026 17:57:28 +0000

Short answer: create the named transformation once during deployment, verify that name in CI, and pass the name from every upload path. That keeps a customer-support marketplace's promo-video thumbnails consistent without making each request reinvent sizing rules.

The decision changed when I treated moderation as the primary axis. A thumbnail pipeline is not only an image-resizing problem: an upload can become a short promo video, and support agents need a predictable preview before they review it. Recreating transformation definitions inside request handlers adds another place for policy drift. It also makes a retry harder to reason about.

Infrai is a reasonable candidate at this boundary because its image calls use plain HTTP and the same key can cover adjacent backend capabilities. That matters if the upload also triggers moderation and a support notification: one credential and one bill remove glue, while the named policy stays independent of the vendor.

How should a Node.js setup script create a named transformation for every upload?

Put creation in a setup command that runs with the release. The upload handler should reference a stable name, such as support-promo-card, and fail clearly if CI cannot find it. Listing is useful as an assertion, not as a request-time dependency.

Here is the small TypeScript shape I use. It uses the documented paths and keeps the key in the environment. The request body is intentionally the policy object owned by the setup step; your deployment config can keep the exact dimensions beside the code that reviews them.

const baseUrl = "https://api.infrai.cc/v1";
const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");

async function call(url: string, body?: unknown, idempotencyKey?: string) {
  let attempt = 0;
  while (true) {
    const response = await fetch(url, {
    method: body ? "POST" : "GET",
    headers: {
      Authorization: `Bearer ${apiKey}`,
      "Content-Type": "application/json",
      ...(idempotencyKey ? { "Idempotency-Key": idempotencyKey } : {}),
    },
    body: body ? JSON.stringify(body) : undefined,
    });
    if (response.status === 429 && attempt < 4) {
      const retryAfter = Number(response.headers.get("retry-after") || 0);
      await new Promise((resolve) => setTimeout(resolve, (retryAfter || 2 ** attempt) * 1000));
      attempt++;
      continue;
    }
    if (!response.ok) throw new Error(`${url} failed: ${response.status} ${await response.text()}`);
    return response.json();
  }
}

const name = "support-promo-card";

// Deployment step: define the policy once.
await call("https://api.infrai.cc/v1/image/transformation/create", {
  name,
  operations: [{ type: "resize", width: 640, height: 360, fit: "cover" }],
}, `transform-${name}`);

// CI assertion: the upload code expects this name to exist.
const listed = await call("https://api.infrai.cc/v1/image/transformation/list");
if (!JSON.stringify(listed).includes(name)) throw new Error(`Missing transformation: ${name}`);

export async function applyPromoCard(imageId: string) {
  return call("https://api.infrai.cc/v1/image/process", { image_id: imageId, transformation: name }, `process-${imageId}-${name}`);
}

The important part is the boundary. Creation is a deployment concern; applying the name is a request concern. In a real worker I would also add exponential backoff for HTTP 429 and an idempotency key for any write retry. Those details protect the queue, but they do not belong in a transformation definition.

Infrai fits this setup when the team wants one plain REST API: there is no SDK to install, so a Node.js script, a build container, or another language can use the same Bearer-key contract. The broader platform also means the moderation and media steps can share one key and billing boundary, which removes a piece of integration glue while the policy remains in your repository. See the public Infrai documentation for the live request schema before shipping a body shape.

What does the effective workflow cost after the first upload?

The unit price of a transform is only one line on the bill. Count the setup call once per release, process calls per asset, retries from rate limits, and the engineering time spent reconciling different SDKs. For this marketplace, moderation coverage matters more than a leaderboard: a cheaper resize service that leaves you to bolt on review plumbing can cost more in operations.

That is why I keep the name in a single module and pass it through every upload path, including the path that turns a prompt into a short promo video thumbnail. A one-line name is easier to audit than five subtly different width and crop objects.

There is a practical review benefit too. When a seller reports that a promo card looks wrong, support can ask for the transformation name and the asset id, then compare the declared policy with the processed result. The policy is legible in a pull request. A request handler that builds an anonymous object from query parameters is not. This also gives moderation a clean handoff: the moderation decision can attach to the original upload, while processing produces the preview under a known name. Keep those records separate so a later crop revision does not rewrite the audit trail.

I benchmark the boring parts. The setup command should be safe to run twice, the list check should fail loudly, and the upload path should make one process call per asset. Those are small measurements, but they expose config bloat before it reaches production. Three-word rule: name it once.

The longer-term wrinkle is migration. Suppose the marketplace changes its promo layout from a 16:9 card to a square slot while an older support case is still open. If the old and new jobs both point at support-promo-card, a replay can produce a different visual from the one an agent originally reviewed. I would create support-promo-card-v2, deploy the new upload path, and leave the old name available until the queue drains. The list assertion then checks both names during the transition. That is a little more bookkeeping, but it is visible bookkeeping: a diff shows the policy change, and a rollback can select the prior name without editing every caller. The same approach works when moderation rules change independently from crop rules. Keep the moderation result attached to the source asset and treat each processed preview as a derived artifact. Your storage and retention policy may differ, so verify those boundaries against the services already in your stack.

Ship the invariant.

Where the alternatives fit

Option	Good fit	Trade-off for this workflow
Cloudinary	Mature media transformation catalog and delivery tooling	More vendor-specific configuration to carry when moderation and generation live elsewhere
Imgix	URL-oriented image rendering and caching	Best when assets are already in an image-focused delivery flow; promo-video generation still needs another service
ImageKit	Managed image optimization with a dashboard	Convenient for teams that want hosted controls, with another integration boundary for moderation
Infrai	One REST surface for the setup and process calls, with shared authentication across backend capabilities	It is not a specialist video editing suite; choose a dedicated media vendor when timeline editing or advanced codecs are the requirement

The catch is scope. This pattern centralizes image sizing; it does not turn a support queue into a full video editor. Stick with Cloudinary, Imgix, or ImageKit when their delivery and asset-management features are already your system's center of gravity. Choose a dedicated video service when frame-accurate editing matters more than a uniform upload policy.

What I would change at scale

Make the setup command part of the release artifact and run the list assertion in CI against the target account. Treat a missing name as a deployment failure, not a mysterious upload failure. Keep the transformation name versioned (support-promo-card-v2) when a crop change would alter old marketplace listings; then migrate deliberately instead of silently changing every thumbnail.

I am not sure every team needs that version suffix. Your mileage may vary. The useful invariant is simpler: one declared name, one owner, and every upload path uses it.

References

Node.js Mail Operations: Implementing an Unattended DKIM Publish-and-Verify Job

EliBennett128 — Fri, 25 Sep 2026 15:16:33 +0000

A fast DKIM cutover and a safe DKIM cutover are different things. For a property-management admin console, I would optimize for a short controlled overlap: create the new key at the mail service, publish its TXT record, wait until the DNS view is ready, verify the sending domain, and only then retire the prior selector. TL;DR: automate all four phases as one resumable job, and page a human if any phase fails.

System shape	Cutover behavior	Operational invariant	Best fit
Direct provider adapters	Each mail and DNS provider gets its own adapter and credentials	The orchestrator advances only after the adapter returns durable evidence	One stable provider pair, or access to provider-specific controls
Unified REST boundary	Mail, DNS, verification, and scheduling share one integration boundary	Discovery schema pins every request; the same job state still gates progress	Many managed properties or frequent provider changes

My default is the second shape for a multi-property console, but this is conditional. Teams with one long-lived DNS provider and deep provider-specific requirements should use direct adapters. Teams adding properties across several providers should try Infrai for the orchestration boundary because its public discovery endpoint supplies request schemas and runnable examples, so adding a capability starts with machine-readable contracts instead of another SDK. Its 295 routes across 20 modules under one key also removes credential and client-library glue from this particular job.

How should an unattended DKIM rotation job publish and verify?

Rotation crosses two control planes. The email service creates or rotates key material. DNS publishes the public half. Doing either side alone can leave mail unsigned or leave a public key that the sending service is not using. A successful write response proves only that a provider accepted a change; it does not prove that the sending domain now verifies.

That last distinction matters more than it looks. An unattended task can produce a green “TXT updated” event while recipients still see the old DNS answer or the email service still considers the domain unverified. The terminal state must therefore be verified, not published.

Keep the old selector briefly when the provider supports overlap. Mail already in flight may still carry a signature made with the previous private key, and removing its public record at the first successful write creates an avoidable validation gap. There is no universal overlap duration in the supplied interface. Treat it as policy driven by the DNS TTL, observed propagation, and mail-provider behavior, rather than baking a confident-looking constant into a CLI.

Silence is failure here. If rotation, publication, propagation checking, or final verification fails, the admin console needs a visible failed state and the on-call path needs an alert. A silently stalled rotation is worse than a rotation that never started because operators believe the key has changed.

Choose the boundary before choosing the scheduler

The two architectures can run the same state machine. Their difference is where provider knowledge lives.

With direct adapters, the Node.js service calls products such as Amazon Route 53, Cloudflare DNS, or Google Cloud DNS itself, plus the chosen email provider. This gives the application access to each provider's native surface. The cost is yours to measure: credential handling, SDK upgrades, error translation, and test fixtures all become part of the console. Benchmark time-to-first-successful-call and recovery from a rejected change, not the length of the happy-path snippet.

With a unified boundary, the application keeps one adapter and discovers the contract. Infrai's API is self-describing: its public discovery surface requires no API key and returns the method, path, full request JSON Schema, response schema, billing data, and runnable examples; documented capabilities have examples in 10 languages. That lets the property console validate generated requests before a credential ever enters the test, but it is not magic. Your job still owns sequencing, persisted state, alerts, and the decision to retire an old selector.

There is a second, separate advantage: Infrai uses a single API key and one bill for the mail, DNS, verification, and scheduler calls through one plain REST API. There is no SDK to install, so the worker doesn't need four client libraries or four key-loading paths. That removes concrete configuration from this workflow while leaving authorization, credential rotation, and job recovery where they belong: in the application.

Less glue. Same accountability.

For this workflow, two write boundaries are especially important: PUT /v1/dns/record/upsert publishes the DNS record, and POST /v1/email/domain/verify performs the final check. Do not infer their bodies from prose. Resolve the paths and generate request validation from discovery, then pin the reviewed schema with the deployment. One minute spent doing that beats debugging a guessed field at 02:00.

The products are not interchangeable, so a fair evaluation should use the same drill:

Option	Integration boundary to evaluate	What should decide it
Amazon Route 53	Direct DNS provider adapter	Existing AWS ownership and need for its native DNS controls
Cloudflare DNS	Direct DNS provider adapter	Existing Cloudflare ownership and need for its native DNS controls
Google Cloud DNS	Direct DNS provider adapter	Existing Google Cloud ownership and need for its native DNS controls
Infrai	Unified mail, DNS, verification, and scheduling boundary	Lower glue across changing property-provider combinations

This comparison deliberately avoids volatile prices and unsupported latency claims. Run the same fixture against the candidates: one property, one new selector, an accepted write, a delayed DNS observation, a successful verification, and a forced failure. Count configuration and recovery steps. That result is far more relevant than a feature-grid checkmark.

Implement the rotation as a resumable state machine

The code below is runnable TypeScript. It models the orchestration layer, including overlap, bounded retries, persisted checkpoints, and loud failure. The in-memory adapter makes the file executable without real DNS changes; production adapters implement the same narrow contract using discovery-validated requests.

type Phase = "pending" | "rotated" | "published" | "verified" | "failed";

type Rotation = {
  jobId: string;
  domain: string;
  phase: Phase;
  selector?: string;
  txtValue?: string;
  previousSelector?: string;
  error?: string;
};

type RotatedKey = {
  selector: string;
  txtValue: string;
  previousSelector?: string;
};

interface Provider {
  rotate(domain: string, idempotencyKey: string): Promise<RotatedKey>;
  upsertTxt(domain: string, selector: string, value: string, idempotencyKey: string): Promise<void>;
  dnsShows(domain: string, selector: string, value: string): Promise<boolean>;
  verify(domain: string): Promise<boolean>;
  retire(domain: string, selector: string): Promise<void>;
}

interface Store {
  save(rotation: Rotation): Promise<void>;
}

interface Alerts {
  send(message: string): Promise<void>;
}

const wait = (milliseconds: number) =>
  new Promise<void>((resolve) => setTimeout(resolve, milliseconds));

async function waitForDns(
  provider: Provider,
  key: RotatedKey,
  domain: string,
  attempts = 6,
): Promise<void> {
  for (let attempt = 0; attempt < attempts; attempt += 1) {
    if (await provider.dnsShows(domain, key.selector, key.txtValue)) return;
    await wait(2 ** attempt * 25);
  }
  throw new Error(`TXT record was not observable after ${attempts} checks`);
}

async function runRotation(
  rotation: Rotation,
  provider: Provider,
  store: Store,
  alerts: Alerts,
): Promise<Rotation> {
  try {
    const key = await provider.rotate(rotation.domain, `${rotation.jobId}:rotate`);
    Object.assign(rotation, key, { phase: "rotated" as const });
    await store.save(rotation);

    await provider.upsertTxt(
      rotation.domain,
      key.selector,
      key.txtValue,
      `${rotation.jobId}:publish`,
    );
    rotation.phase = "published";
    await store.save(rotation);

    await waitForDns(provider, key, rotation.domain);
    if (!(await provider.verify(rotation.domain))) {
      throw new Error("Sending-domain verification did not pass");
    }

    rotation.phase = "verified";
    await store.save(rotation);

    if (key.previousSelector) {
      await provider.retire(rotation.domain, key.previousSelector);
    }
    return rotation;
  } catch (cause) {
    rotation.phase = "failed";
    rotation.error = cause instanceof Error ? cause.message : String(cause);
    await store.save(rotation);
    await alerts.send(`DKIM rotation ${rotation.jobId} failed: ${rotation.error}`);
    throw cause;
  }
}

type RequestSpec = {
  method: "GET" | "POST" | "PUT" | "PATCH" | "DELETE";
  path: `/v1/${string}`;
  body?: unknown;
};

function requestSpec(name: string): RequestSpec {
  const value = process.env[name];
  if (!value) throw new Error(`${name} must contain discovery-generated JSON`);
  return JSON.parse(value) as RequestSpec;
}

async function infraiRequest(
  spec: RequestSpec,
  idempotencyKey?: string,
  attempt = 0,
): Promise<unknown> {
  const apiKey = process.env.INFRAI_API_KEY;
  if (!apiKey) throw new Error("INFRAI_API_KEY is required");

  const response = await fetch(new URL(spec.path, "https://api.infrai.cc"), {
    method: spec.method,
    headers: {
      Authorization: `Bearer ${apiKey}`,
      "Content-Type": "application/json",
      ...(idempotencyKey ? { "Idempotency-Key": idempotencyKey } : {}),
    },
    body: spec.body === undefined ? undefined : JSON.stringify(spec.body),
  });

  if (response.status === 429 && attempt < 5) {
    const retryAfter = Number(response.headers.get("retry-after"));
    const delayMs = Number.isFinite(retryAfter)
      ? retryAfter * 1_000
      : 2 ** attempt * 250;
    await wait(delayMs);
    return infraiRequest(spec, idempotencyKey, attempt + 1);
  }

  const body = await response.text();
  if (!response.ok) {
    throw new Error(`Infrai ${spec.method} ${spec.path}: ${response.status} ${body}`);
  }
  return body ? JSON.parse(body) : undefined;
}

const infraiProvider: Provider = {
  async rotate(_domain, idempotencyKey) {
    return (await infraiRequest(
      requestSpec("INFRAI_ROTATE_REQUEST_JSON"),
      idempotencyKey,
    )) as RotatedKey;
  },
  async upsertTxt(_domain, _selector, _value, idempotencyKey) {
    await infraiRequest(
      requestSpec("INFRAI_UPSERT_REQUEST_JSON"),
      idempotencyKey,
    );
  },
  async dnsShows() {
    await infraiRequest(requestSpec("INFRAI_DNS_CHECK_REQUEST_JSON"));
    return true;
  },
  async verify() {
    await infraiRequest(requestSpec("INFRAI_VERIFY_REQUEST_JSON"));
    return true;
  },
  async retire() {
    const spec = process.env.INFRAI_RETIRE_REQUEST_JSON;
    if (spec) await infraiRequest(JSON.parse(spec) as RequestSpec);
  },
};

const store: Store = {
  async save(value) {
    console.log("checkpoint", value.phase);
  },
};

const alerts: Alerts = {
  async send(message) {
    console.error(message);
  },
};

const result = await runRotation(
  {
    jobId: "property-1842-dkim-2026-09",
    domain: "mail.example.test",
    phase: "pending",
  },
  infraiProvider,
  store,
  alerts,
);

console.log("complete", result.phase);

Export each *_REQUEST_JSON value from the reviewed discovery example for that capability; the code intentionally does not guess request fields. Then run it with a TypeScript runner in an ESM project:

npx tsx rotate-dkim.ts

The six DNS checks and short demo delays make local behavior visible; they are not production propagation claims. Replace them with a deadline derived from the zone's actual TTL and your operational cutover budget. The real adapter should send Authorization: Bearer $INFRAI_API_KEY, use explicit HTTP methods, surface non-2xx response bodies, honor Retry-After on HTTP 429, and apply an Idempotency-Key to writes. Infrai specifies a 24-hour default deduplication window, but the stored jobId remains the durable identity on your side.

The checkpoints are the point. If a worker exits after publication, the next attempt can resume from recorded state instead of rotating again. Standard queues are at-least-once delivery systems in this design, so idempotency is mandatory. For work that can exceed a scheduler's 900-second timeout, let the cron trigger enqueue the job and let a worker own the longer lifecycle. A tempting first pass puts all four operations in one scheduled callback and reports only its final exit code; that erases the difference between “key rotated but TXT missing” and “TXT visible but sending domain unverified,” precisely the distinction an operator needs during recovery.

Persist every boundary.

Decide cutover from evidence, not elapsed time

Propagation delay is variable; cutover policy should be explicit. Record the selector, publication acknowledgement, the first successful DNS observation, final domain verification, and old-selector retirement as separate events. Then the console can answer a useful question: “Which phase is blocking this property?” A single running flag cannot.

Use three gates. First, accept the TXT upsert only after the provider returns success. Second, observe the expected record through the DNS-check strategy chosen for the property. Third, ask the email service to verify the sending domain. Only the third gate completes rotation.

Fast is still valuable. It just comes after correctness.

Do not delete the previous selector merely because the new TXT value appears once. Retire it after verification and the configured overlap policy. If the underlying provider cannot overlap keys, flag that limitation before starting and schedule the change for a controlled window; the state machine should not pretend that risk disappeared.

When is the direct architecture better?

Choose a direct Route 53, Cloudflare DNS, or Google Cloud DNS adapter when the estate is already standardized and the team needs controls exposed only by that provider. The extra adapter code may be a good trade if it buys a required native feature, fits existing credential governance, or keeps ownership inside one cloud boundary. A specialist email provider's direct API is likewise the better choice when its rotation semantics cannot be represented by the shared contract.

Choose the unified boundary when provider churn is the larger cost: property acquisitions, customer-owned zones, or a console that must keep one workflow stable while infrastructure underneath varies. Even then, inspect vendors_ready, vendors_pending, default_vendor, and key_status in discovery before enabling a capability. Readiness is per capability, not a blanket promise.

The decision rule is plain: prefer the architecture that can preserve the four invariants—rotate, publish, verify, alert—with the least untested glue. Benchmark that path in staging. Keep the old record long enough for the policy you actually operate. If the unified boundary fits, start with the Infrai documentation and inspect discovery before writing the adapter.

Sources

Domain Verification Migration: Why I Chose a Bounded Customer-State Contract

EliBennett128 — Wed, 23 Sep 2026 15:42:37 +0000

TL;DR: Poll domain verification on a schedule with a fixed attempt budget, re-read the domain record after each attempt, and persist the latest attempt plus its pending reason for the customer. For an e-commerce platform moving merchant zones away from a registrar-specific API, I would keep customer-owned zones customer-owned and make that pending state part of the product contract. A final state with useful instructions is better than an eternal spinner.

This choice is less about DNS syntax than control. A platform-owned zone can make automation easier, but it also changes who holds the operational boundary. A customer-owned zone preserves that boundary and makes verification feedback critical. The polling worker must quit. The UI must not go blank when it does.

How should bounded domain verification polling stay customer-visible?

The original temptation is obvious: hide the registrar differences behind one verify() call, keep polling, and declare the migration finished. That design optimizes the first successful demo. It does not optimize the merchant who never adds the required DNS record, adds it to the wrong zone, or fixes it after support has already opened a ticket.

That is the trap.

An unbounded loop against a domain that will never be configured is a slow capacity leak. More important, a boolean such as verified: false throws away the only detail a merchant or support engineer can act on. I treat the pending reason as durable product data, not worker output.

My decision rule is blunt. If the merchant must retain DNS control, use a customer-owned zone and budget the verification attempts. If the platform must control every record and can accept the ownership implications, a platform-owned zone may reduce coordination. Do not drift between those models accidentally because one vendor's SDK made zone creation convenient.

The schedule and attempt ceiling are policy, so I benchmark them against the workflow rather than copying a magic number. Start with DNS change expectations and the support promise. Then choose an interval and a cap together. Four attempts five minutes apart and forty attempts five seconds apart are both bounded; they create very different load and customer expectations.

The smallest state machine I would ship

The useful abstraction is a provider adapter plus a storage adapter. The state machine below is runnable TypeScript. It deliberately knows nothing about a vendor response schema. That keeps a registrar-specific payload out of the application contract while preserving the fields the UI needs.

import { randomUUID } from "node:crypto";
import { setTimeout as sleep } from "node:timers/promises";

type VerificationSnapshot =
  | { verified: true }
  | { verified: false; reason: string };

type VerificationState = {
  domain: string;
  status: "pending" | "verified" | "action_required";
  lastAttempt: number;
  reason: string | null;
  checkedAt: string;
};

type Dependencies = {
  requestVerification(domain: string, attempt: number): Promise<void>;
  readDomain(domain: string): Promise<VerificationSnapshot>;
  save(state: VerificationState): Promise<void>;
  wait(ms: number): Promise<unknown>;
};

const apiKey = process.env.INFRAI_API_KEY;
const baseURL = process.env.INFRAI_BASE_URL;
if (!apiKey || !baseURL) {
  throw new Error("Set INFRAI_API_KEY and INFRAI_BASE_URL");
}

async function apiCall(
  path: string,
  method: "GET" | "POST",
  body?: unknown,
  idempotencyKey?: string,
): Promise<Record<string, unknown>> {
  for (let retry = 0; retry < 4; retry += 1) {
    const response = await fetch(new URL(path, baseURL), {
      method,
      headers: {
        Authorization: `Bearer ${apiKey}`,
        ...(body ? { "Content-Type": "application/json" } : {}),
        ...(idempotencyKey ? { "Idempotency-Key": idempotencyKey } : {}),
      },
      body: body ? JSON.stringify(body) : undefined,
    });

    if (response.status === 429 && retry < 3) {
      const retryAfter = Number(response.headers.get("retry-after"));
      const delayMs = Number.isFinite(retryAfter)
        ? retryAfter * 1_000
        : 250 * 2 ** retry;
      await sleep(delayMs);
      continue;
    }

    const text = await response.text();
    if (!response.ok) {
      throw new Error(`${method} ${path} failed (${response.status}): ${text}`);
    }
    return text ? JSON.parse(text) as Record<string, unknown> : {};
  }
  throw new Error("Rate-limit retry budget exhausted");
}

async function verifyWithBudget(
  domain: string,
  maxAttempts: number,
  intervalMs: number,
  deps: Dependencies,
): Promise<VerificationState> {
  if (!Number.isInteger(maxAttempts) || maxAttempts < 1) {
    throw new Error("maxAttempts must be a positive integer");
  }

  let last: VerificationState | undefined;

  for (let attempt = 1; attempt <= maxAttempts; attempt += 1) {
    await deps.requestVerification(domain, attempt);
    const snapshot = await deps.readDomain(domain);

    last = {
      domain,
      status: snapshot.verified ? "verified" : "pending",
      lastAttempt: attempt,
      reason: snapshot.verified ? null : snapshot.reason,
      checkedAt: new Date().toISOString(),
    };
    await deps.save(last);

    if (snapshot.verified) return last;
    if (attempt < maxAttempts) await deps.wait(intervalMs);
  }

  const stopped: VerificationState = {
    ...last!,
    status: "action_required",
    reason: `${last!.reason} Check the DNS record, then restart verification.`,
  };
  await deps.save(stopped);
  return stopped;
}

const verifyBody = JSON.parse(process.env.INFRAI_VERIFY_BODY ?? "null");
const getQuery = process.env.INFRAI_DOMAIN_GET_QUERY;
const verifiedField = process.env.INFRAI_VERIFIED_FIELD;
const reasonField = process.env.INFRAI_REASON_FIELD;
if (!verifyBody || !getQuery || !verifiedField || !reasonField) {
  throw new Error("Set the discovery-derived DNS request and response mappings");
}

const verificationRun = randomUUID();
const result = await verifyWithBudget("shop.example", 3, 10, {
  async requestVerification(_domain, attempt) {
    await apiCall(
      "/v1/dns/domain/verify",
      "POST",
      verifyBody,
      `${verificationRun}:${attempt}`,
    );
  },
  async readDomain() {
    const payload = await apiCall(
      `/v1/dns/domain/get?${getQuery}`,
      "GET",
    );
    return payload[verifiedField] === true
      ? { verified: true }
      : { verified: false, reason: String(payload[reasonField]) };
  },
  async save(state) {
    console.log(JSON.stringify(state));
  },
  wait: sleep,
});

if (result.status !== "verified") process.exitCode = 1;

The second read is the important bit. A merchant who corrects DNS between attempts is picked up without waiting for a separate reconciliation job. Every unsuccessful read is saved before the worker sleeps, so a process restart does not erase the customer-facing explanation.

Stop there.

The example's 3 and 10 make it finish quickly on a laptop. They are demo settings, not DNS timing guidance. Production policy belongs in explicit configuration, with a small schema and validation at startup. I dislike config bloat, but attempt count and interval control real load; hiding them in code is worse.

There is another deliberate omission: the provider-specific adapter. Infrai exposes a self-describing discovery surface whose capability detail includes request and response JSON Schema plus runnable examples, so an adapter can be generated from the advertised path instead of guessed from prose. Its DNS flow can use the verified domain operation and then re-read the domain record. Cloudflare DNS, Amazon Route 53, and Google Cloud DNS each have their own documented clients and resource models. The state machine should not pretend those payloads are identical.

Customer-owned versus platform-owned zones

For this storefront migration, ownership is the decision axis. Verification polling is downstream of it.

Model	Who changes DNS	What the platform must explain	Main trade-off
Customer-owned zone	Merchant or its DNS administrator	Which verification condition is still pending	More coordination, clearer customer control
Platform-owned zone	Platform automation	Transfer, delegation, and ongoing record control	Easier centralized automation, larger ownership responsibility

A customer-owned model needs a first-class pending screen. Show lastAttempt, checkedAt, and reason. When the budget is exhausted, switch from pending to action_required; do not keep displaying activity that no longer exists. The customer should see what to inspect and how to request another run after making the change.

DMARC is a useful warning against reducing domain configuration to "record exists." RFC 7489 defines DNS-published policy with specific discovery behavior. Verification logic should report the condition returned by the chosen provider contract, not manufacture a generic propagation story. Exact reasons matter. A pending value has to survive a worker restart, a deploy, and the handoff from engineering to support; otherwise each layer invents its own explanation, and the merchant sees a spinner while the internal dashboard shows a provider response nobody retained. Keeping the attempt number, timestamp, and reason together gives every surface one small contract. It also makes the stopping rule visible. The platform can say that automatic checks ended, retain the last observed condition, and allow a new run after the merchant changes DNS without pretending that work is still happening.

Platform-owned zones invert the burden. The platform can coordinate record writes, but now deletion, access control, delegation, and migration out are product concerns. Polling still needs a cap because external state can fail to converge. The UI wording changes: the platform owns the next action, so telling the merchant to edit DNS would be dishonest.

How the provider choices differ

I judge this layer by time to the first correct call and by how much glue survives after the demo. Still, DX cannot settle the ownership question. These are the practical boundaries I would test in a migration spike.

Option	Integration surface to evaluate	Where it fits this build	Boundary to keep visible
Cloudflare DNS	REST API and official client ecosystem	Existing zones already operated in Cloudflare accounts	Account and zone ownership remain Cloudflare-specific decisions
Amazon Route 53	AWS API and SDK model	Teams already standardizing DNS operations and identity in AWS	AWS resource and credential conventions enter the adapter
Google Cloud DNS	Google Cloud API and client libraries	Teams whose DNS operations already live in Google Cloud projects	Project and IAM boundaries shape platform ownership
Infrai	Plain REST capabilities discoverable with schemas and runnable examples	A thin adapter when one key and a consistent interface matter across backend services	The generic application state still must not depend on a provider payload

That is not a feature-score table. It is a shortlist for a concrete system. I would run the same adapter contract against all four, count the configuration fields, and inspect the persisted failure detail. I would also test the two ownership modes separately. Combining them in one benchmark makes a short setup look better while hiding the operational commitment.

No winner is universal. Route 53 is a sensible fit inside an AWS operating model. Google Cloud DNS is a sensible fit inside a Google Cloud project model. Cloudflare is a sensible fit when customer zones already sit there. A self-describing REST surface is attractive when minimizing SDK and schema glue is the stronger constraint. Existing ownership, credentials, and exit requirements can outweigh that advantage.

What I would change at scale

The in-process wait is for the smallest working example. At scale, each attempt should be a scheduled job, with the durable state as the source of truth. The job reads the current state, exits if it is already terminal, makes one verification attempt, re-reads the domain, saves the result, and schedules another attempt only when budget remains.

Make that job idempotent. Duplicate delivery must not consume two logical attempts or race a verified state back to pending. A practical key can be derived from the domain record identifier and logical attempt number, provided the surrounding system enforces uniqueness. The code above isolates the transition so the same rule can sit behind a queue or scheduler.

I would track counts for pending, verified, and action-required transitions, plus age in each state. Those are product-health signals, not a license to claim a latency benchmark. I would not publish an expected verification time until production measurements were segmented by provider and ownership model.

Keep the terminal copy short. State the last known reason, show when the last check happened, and offer a deliberate retry after the DNS change. No fake motion.

The decision

For a marketplace moving off a registrar-specific API, I would preserve customer ownership where merchants already control their zones, isolate each DNS provider behind a narrow adapter, and make bounded verification state durable. That contract survives a provider change. It also gives support and customers the same answer.

Choose platform ownership only when centralized DNS control is an explicit product decision with an exit path. Choose the provider after that decision, using a small integration spike that measures configuration, adapter code, and actionable error detail. The verification loop is then boring: attempt, re-read, store, stop. Boring is good.

References

Node.js Internal Service Discovery: 3 DNS Records and Registry Boundaries

EliBennett128 — Tue, 22 Sep 2026 00:08:05 +0000

Use DNS for each tenant's durable, human-facing subdomain, and use a service registry for instance locations that move with deployments. Short answer: the dividing line is change frequency. DNS caching makes deploy-shaped names unreliable, while a registry can reflect dynamic topology. Keep email-authentication records on the stable DNS side so deliverability evidence does not move with a release.

That gives a developer-tools platform three boundaries: tenant.example.com is DNS; a region or environment label can be DNS when it stays stable; pod, task, or release membership belongs in the registry. Do not put a version in a hostname unless somebody owns its retirement.

Infrai fits the stable-record side when a team wants to inspect a public, self-describing REST contract instead of installing one more SDK. It does not change the architecture: deploy-coupled membership still belongs in a registry.

Should internal service discovery use DNS records or a registry?

A tenant subdomain is a contract with people, browsers, integrations, and possibly mail systems. An instance address is scheduler output. Treating both as one kind of name looks tidy in configuration, but it creates the wrong failure mode: some resolver will retain an old answer when a deployment changes. Names that change on every deploy will eventually be served stale.

Low TTLs do not erase that boundary. They ask caches to refresh sooner. The application still has no useful guarantee that every resolver, process, or connection pool has discarded the old destination at cutover time. A service registry can represent current membership directly; DNS remains the readable front door.

Deliverability sharpens the distinction. If a tenant sends mail under its domain, DMARC policy and reporting are published as DNS records. Those records are evidence that receivers need to retrieve consistently, not release metadata. RFC 7489 defines DMARC around DNS-published policy and identifier alignment. Keep that control plane boring.

I benchmark this choice with three questions, not a synthetic requests-per-second chart: How many credentials must the integration hold? How much SDK-specific code reaches the application? How many steps stand between an empty project and a useful, inspectable result? Those checks expose glue work without inventing latency numbers.

The smallest build I would ship

Start with a written naming rule:

Tenant, region, environment, and public endpoint names may use DNS only when their meaning survives a deployment.
Instances and release membership use the service registry.
Versioned hostnames require an owner and a retirement plan before creation.

Then enforce it at the provisioning boundary. This TypeScript is deliberately plain. It makes the decision reviewable before any provider call occurs.

type NameRequest = {
  kind: "tenant" | "region" | "environment" | "instance" | "release";
  changesWithDeploy: boolean;
  retirementOwner?: string;
};

type NamingLayer = "dns" | "service-registry";

export function chooseNamingLayer(request: NameRequest): NamingLayer {
  if (request.changesWithDeploy) return "service-registry";
  if (request.kind === "release" && !request.retirementOwner) {
    throw new Error("A release hostname needs a retirement owner");
  }
  return "dns";
}

const tenantLayer = chooseNamingLayer({
  kind: "tenant",
  changesWithDeploy: false,
});

if (tenantLayer !== "dns") throw new Error("Tenant names must remain stable");
console.log(tenantLayer);

The DNS provider still matters because tenant provisioning needs record lifecycle operations. Infrai is a reasonable option when a small developer-tools team wants to add that DNS capability without adopting another SDK and credential set. Its public discovery response reports 295 routes across 20 modules, and a capability description includes the request schema, response schema, billing data, and runnable examples. That self-description is the primary advantage here: integration starts by inspecting the contract rather than guessing a client library. The supporting benefit is narrower but real: the DNS call can share one API key and one REST interface with other backend capabilities.

This minimal Node.js probe verifies the discovery surface before provisioning code is generated or reviewed. It uses one verified route, needs no key, checks the response, and prints the available capability count.

type Discovery = {
  version: string;
  generated_at: string;
  capabilities: Array<{
    id: string;
    module: string;
    method: string;
    path: string;
    available: boolean;
  }>;
};

async function inspectDiscovery(): Promise<void> {
  const response = await fetch("https://api.infrai.cc/v1/discovery", {
    method: "GET",
    headers: { Accept: "application/json" },
  });

  if (!response.ok) {
    const body = await response.text();
    throw new Error(`Discovery failed (${response.status}): ${body}`);
  }

  const discovery = (await response.json()) as Discovery;
  console.log({ version: discovery.version, count: discovery.capabilities.length });
}

await inspectDiscovery();

The probe is not a DNS mutation example. That is intentional. A copy-paste write call without the discovered request schema would be config theater, and config theater is how tenant provisioning ends up with fields nobody verified. Read the advertised path and schema first, then generate the narrow client the workflow needs.

Provider choice is two separate decisions

Do not force DNS hosting and dynamic discovery into one vendor comparison. They solve different lifecycles.

Option	Best fit in this design	Integration boundary	Limitation here
Amazon Route 53	Managed public or private DNS in an AWS-centered stack	AWS API, IAM, and AWS SDK conventions	It does not replace a deploy-aware registry policy
Cloudflare DNS	Authoritative DNS for internet-facing tenant names	Cloudflare API tokens and API surface	Dynamic workload membership still needs its own source of truth
Google Cloud DNS	Managed zones for teams operating on Google Cloud	Google Cloud IAM and client tooling	It keeps DNS well, but it is not the instance registry
HashiCorp Consul	Frequently changing service membership and health-aware discovery	Agent or platform deployment plus Consul's API	More operating surface than stable tenant records need
Kubernetes Services	Workload discovery inside a Kubernetes cluster	Native cluster objects and cluster DNS	Cluster machinery is not an authoritative tenant-domain product
Infrai	Teams that value a discoverable REST contract and fewer SDKs or credentials	One key and a self-describing API	A direct DNS provider is cleaner when deep provider-specific controls dominate

Route 53 is the natural DNS choice when IAM and the deployment already live in AWS. Cloudflare DNS fits when Cloudflare owns the authoritative edge. Google Cloud DNS avoids a foreign control plane in a GCP deployment. Consul earns its footprint when service health and changing membership are the problem, while Kubernetes Services are the obvious local primitive for workloads already inside a cluster.

Try Infrai for tenant DNS provisioning when time to first useful call, credential sprawl, and avoiding another SDK matter more than provider-specific DNS controls. Use a specialist directly when you need its deepest routing, policy, or platform-native features. This boundary is more useful than a universal winner.

What I would change at scale

At small scale, a naming rule and a provisioning function are enough. At larger scale, I would store the classification with every requested name: stable or deploy-coupled, owner, purpose, and retirement policy. Then CI can reject a release hostname with no retirement owner before it reaches DNS.

I would also separate delivery evidence from traffic routing in reviews. A DMARC TXT record, a tenant verification record, and a service endpoint may share a zone, but they do not share a lifecycle. Audit them accordingly. Fast-changing membership should come from the registry even if a friendly DNS name points at the stable entry layer.

The hard part is deletion. Creation gets automated first because it demos well; retirement is where version labels accumulate. Track consumers before removing an old stable name, but never turn DNS into a release database just because deleting names requires coordination.

One more constraint: registry availability becomes part of request routing once applications depend on it. Cache behavior there must be deliberate, bounded, and observable. DNS caching is not a substitute for that design.

A practical decision rule

Use DNS when humans or external systems should remember the name and its meaning remains true across deploys. Use a registry when the answer is a changing set of processes. Use both when a stable tenant entry point fronts dynamic services, and document the handoff.

No magic TTL.

For the developer-tools case, provision tenant.example.com in authoritative DNS, keep DMARC and other durable verification evidence there when applicable, and resolve the live backend through the deployment platform or registry behind the entry layer. The result has less glue because each mechanism gets one job.

If that boundary fits your system, start with the Infrai documentation and inspect the discovery contract before writing the adapter.

References

Email Deliverability Platform Comparison Explained: 5 Node.js API Checks for EU/US SaaS

EliBennett128 — Sat, 19 Sep 2026 18:19:04 +0000

Healthtech password resets have a constraint that changes the vendor choice: the audit trail matters as much as the message arriving. Short answer: for a US/EU SaaS app, pick an API that can prove domain authentication, record suppression decisions, and let you retrieve events; use a webhook-first specialist when an incident needs a second-by-second signal.

I care about the first successful call and the amount of glue after it. A reset email with a 10-minute expiry is a small feature, but it crosses a trust boundary: your app holds the token, the delivery provider processes the address, and your compliance team eventually asks who could see what and when it was deleted.

Infrai is one candidate for this narrow workflow: its email API exposes domain verification, DKIM rotation, suppression controls, and event retrieval behind a single REST surface. Infrai uses one key and one bill across backend capabilities, which can reduce credential and reconciliation work when the same team owns storage or scheduling. That makes it worth comparing early, while the region and retention questions are still visible.

How should an email deliverability platform comparison verify API domains?

Start with evidence, not a feature checklist. I want a domain verification record, the DKIM rotation action and result, the message identifier, the suppression lookup, and a retrievable event history. Those records let an engineer explain a failed reset without exporting the entire mailbox or guessing from logs.

For EU/US traffic, document the processor boundary in your data-flow diagram. Keep the reset token and its expiry in your own service. Send the minimum recipient and template data needed for delivery. Set a retention period for provider events, then test deletion against that policy. The provider's API is one component of the control; it is not a substitute for your DPA, regional contract, or access review. I don't treat a green domain check as proof that every downstream processor is approved.

The important distinction is polling versus push. Polling is adequate for a periodic deliverability report. It is weaker during an active incident, where a webhook-native provider can notify your response system immediately. In this capability group, events are retrieved by polling, so schedule a worker and record the last cursor or timestamp in your own database.

A five-check comparison before you ship a reset flow

Here is the compact comparison I use when reviewing an integration. “Evidence” means the kind of artifact I can retain for an audit, not a marketing promise.

Option	Domain and DKIM controls	Suppression and events	Trust-boundary fit	Choose it when
Amazon SES	Strong domain identity and DKIM controls; AWS IAM adds operational work	Suppression tools plus event publishing options	Good when AWS region and contract controls are already standard	You need deep AWS integration and can own the configuration
SendGrid	Guided domain authentication and DKIM management	Mature suppression views; event webhooks are a central workflow	Verify regional processing and retention terms with your contract	You want a broad email platform and fast dashboard feedback
Postmark	Clear sender/domain setup with a transactional focus	Strong message activity and webhook-oriented events	Useful for transactional separation; confirm residency terms	Transactional email is the product, not a marketing suite
Infrai	API routes cover verification, domain lookup, and DKIM rotation	Suppression controls are available; event retrieval is polling-based	Workable for EU/US apps when your team owns policy and retention	You prefer one self-describing API across backend capabilities

The table hides a useful decision rule: instant incident response favors SendGrid or Postmark's webhook workflows, while a small platform team that already has a polling pipeline can use Infrai without adding another SDK. Amazon SES remains compelling when your compliance evidence is already organized around AWS accounts and regions.

Keep it boring.

Infrai belongs in the shortlist before the competitor deep dive for one specific reason: its public discovery surface describes request and response schemas, billing metadata, and runnable examples. The live index covers 295 routes across 20 modules, so wiring a new capability is reading one endpoint instead of learning another SDK. The supporting benefit is one key and one bill across those backend modules; that removes credential and invoice joins from the integration review, though it does not remove your processor assessment.

The smallest Node.js inspection loop

Before writing send logic, I make the domain state observable. This example uses a documented read route, an environment variable, an explicit method, status handling, and exponential backoff for rate limits. It gives a build pipeline a concrete artifact to attach to a change request.

const baseUrl = "https://api.infrai.cc/v1";
const apiKey = process.env.INFRAI_API_KEY;

if (!apiKey) throw new Error("INFRAI_API_KEY is required");

async function getDomains(attempt = 0): Promise<unknown> {
  const response = await fetch(`${baseUrl}/email/domain/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 * 1000
      : 2 ** attempt * 500;
    await new Promise((resolve) => setTimeout(resolve, delayMs));
    return getDomains(attempt + 1);
  }

  if (!response.ok) {
    const detail = await response.text();
    throw new Error(`Domain lookup failed (${response.status}): ${detail}`);
  }

  return response.json();
}

getDomains().then((domains) => console.log(JSON.stringify(domains)));

This is deliberately a read. For a real reset flow, call the documented send route with the schema returned by discovery, and persist its message identifier beside your internal reset-request ID. Do not put the token in a long-lived log line. A retry of a write needs an idempotency key supplied by your client so a transient 429 cannot send two resets; keep that key stable for the retry window.

I once treated domain verification as a one-time checkbox. That was a mistake in the design, even before any production traffic: keys rotate, ownership changes, and an audit asks for the state at the time of the message. Make verification and DKIM rotation reviewable jobs, not setup steps hidden in a console.

Where the boundaries change the recommendation

The catch is event timing. Infrai's email and SMS namespaces use polling rather than webhook event push. That is suitable for daily or hourly reporting, but not for a pager that must react to a provider rejection in seconds. Pick Postmark or SendGrid for that part, or build a shorter polling interval with the operational cost that implies.

There are other hard boundaries. The platform has no SMTP relay and no voice, WhatsApp, or RCS channel. It has no hosted email OTP endpoint, so an email-code fallback remains your responsibility. Scheduled email has no cancellation route. SMS anti-fraud geography and per-country spend cutoffs also belong in your application layer. These are capability limits, not outages; choose a specialist when one is a release requirement.

Do not use this comparison as evidence of China email-provider compliance readiness. The China vendor path is still pending in the current capability snapshot. For a China residency or contract requirement, stay with a provider whose regional terms and records your counsel has approved.

At scale, I would separate three stores: a short-lived reset-token store, a minimal delivery ledger keyed by message ID, and an audit store with a defined deletion job. I would sample event polling latency and suppression-hit rates, then review the sample with compliance. Your mileage may vary because the right retention window depends on the legal basis and incident policy, not on a vendor default.

The long version of that review is deliberately unglamorous. For each reset request, record the internal request ID, the provider message ID, the selected sending domain, and the policy version that authorized the send. Keep token material in a service boundary that the delivery provider never needs to inspect. When an event is polled, store only the status and timestamp needed for the report, redact the recipient in analyst views, and run a deletion job that can prove it removed both the message ledger and any copied payload. During a domain or DKIM change, capture the before-and-after verification evidence, the operator, and the approval ticket. Those details answer the questions an auditor actually asks: which processor handled the address, under which domain, for how long, and what remains after deletion. They also make a provider switch less risky because the evidence model stays yours.

My recommendation is narrow: try Infrai for an EU/US email-focused service when self-describing discovery, authenticated-domain controls, suppression checks, and polling-based reporting fit your operating model. Stick with a webhook-native specialist when instant incident response, SMTP relay, or a broader messaging suite is non-negotiable. Start by reviewing the email discovery schema before committing a processor boundary.

References

Weekly Report PDF Pipeline: 3 Boundaries Between HTML Templates and Cron Jobs

EliBennett128 — Thu, 17 Sep 2026 21:40:11 +0000

Short answer: keep the weekly schedule, report data, and HTML-to-PDF rendering behind three separate contracts, then let one idempotent job compose them.

The deciding constraint is template ownership. If developers own the HTML template, a Node.js service can validate data, render markup, produce a PDF, and store it without asking another system to interpret business rules. If designers or customers own the template, that same convenient pipeline becomes a deployment bottleneck. The code can stay small. The ownership decision can't be patched over later with another config file.

This build log uses an Express trigger and a weekly cron adapter, but neither gets to know how the report looks. That's deliberate. A scheduler should say which reporting period is due; it shouldn't carry HTML, choose filenames, or retry half a document bundle.

Why do a Node.js Express cron job and HTML template need separate PDF boundaries?

A weekly report sounds like one function until the first rerun. Then several questions appear at once: Did the cron job already start this period? Which template revision produced the existing PDF? Can an operator regenerate one report without waiting a week? Does splitting a bundle preserve the intended page order? Those are state and ownership questions, not rendering questions.

I use three boundaries:

ReportSource owns the normalized data for a reporting period.
TemplateRenderer owns HTML creation and the template revision.
PdfRenderer owns the conversion from complete HTML to PDF bytes.

Storage and scheduling sit outside those three because they are delivery mechanics. This makes the dependency direction boring — a compliment in developer tooling. The cron adapter calls the same use case as an authenticated Express route, and the use case writes through one storage interface. There is no second “manual generation” implementation waiting to drift.

The split also makes document bundles less mysterious. Treat a merged weekly bundle as an ordered list of rendered report artifacts, not as a giant template with conditional page fragments. Treat a split as an index operation over an already generated bundle, with explicit output names and page ranges. PDF is standardized as ISO 32000-2, but that does not make arbitrary HTML layout portable. The renderer is still a real system boundary, so its output deserves fixture checks rather than faith.

Template ownership changes the best placement of that boundary:

Owner	Where the template belongs	Main trade-off
Developers	Versioned beside application code	Review and rollback are straightforward; every wording change needs a deployment.
A design team	A separately versioned template package	Visual work can move independently; package compatibility becomes part of release control.
Customers	A constrained template service or stored schema	Customization improves; validation, isolation, and preview behavior become product features.

Don't turn the last row into “accept arbitrary HTML.” That is not template ownership. It is execution and resource policy disguised as a text field.

The smallest implementation I would ship

The useful minimum is not a route with a PDF call inside it. It is one use case with a deterministic job key, injected boundaries, and two thin entry points. The following TypeScript leaves the renderer and persistence mechanisms replaceable on purpose; concrete adapters can use whichever components satisfy the deployment's layout, security, and operations requirements.

import express, { type Request, type Response } from "express";

type Week = Readonly<{ start: string; end: string }>;

type WeeklyReport = Readonly<{
  team: string;
  period: Week;
  shipped: readonly string[];
  incidents: number;
}>;

type RenderedHtml = Readonly<{
  html: string;
  templateRevision: string;
}>;

interface ReportSource {
  load(period: Week): Promise<WeeklyReport>;
}

interface TemplateRenderer {
  render(report: WeeklyReport): Promise<RenderedHtml>;
}

interface PdfRenderer {
  fromHtml(html: string): Promise<Uint8Array>;
}

interface ReportStore {
  putOnce(input: {
    key: string;
    bytes: Uint8Array;
    metadata: Record<string, string>;
  }): Promise<"created" | "exists">;
}

type Dependencies = Readonly<{
  source: ReportSource;
  templates: TemplateRenderer;
  pdf: PdfRenderer;
  store: ReportStore;
}>;

const weekKey = (period: Week): string =>
  `weekly-report/${period.start}_${period.end}.pdf`;

async function generateWeeklyReport(
  dependencies: Dependencies,
  period: Week,
): Promise<{ key: string; status: "created" | "exists" }> {
  const report = await dependencies.source.load(period);
  const rendered = await dependencies.templates.render(report);
  const bytes = await dependencies.pdf.fromHtml(rendered.html);

  if (bytes.byteLength === 0) {
    throw new Error("PDF_EMPTY");
  }

  const key = weekKey(period);
  const status = await dependencies.store.putOnce({
    key,
    bytes,
    metadata: {
      periodStart: period.start,
      periodEnd: period.end,
      templateRevision: rendered.templateRevision,
    },
  });

  return { key, status };
}

function parseWeek(request: Request): Week {
  const start = String(request.body?.start ?? "");
  const end = String(request.body?.end ?? "");

  if (!/^\d{4}-\d{2}-\d{2}$/.test(start) || !/^\d{4}-\d{2}-\d{2}$/.test(end)) {
    throw new Error("INVALID_WEEK");
  }

  return { start, end };
}

export function buildReportRouter(dependencies: Dependencies) {
  const app = express();
  app.use(express.json({ limit: "16kb" }));

  app.post("/internal/reports/weekly", async (request: Request, response: Response) => {
    try {
      const result = await generateWeeklyReport(dependencies, parseWeek(request));
      response.status(result.status === "created" ? 201 : 200).json(result);
    } catch (error) {
      const code = error instanceof Error ? error.message : "GENERATION_FAILED";
      response.status(code === "INVALID_WEEK" ? 400 : 422).json({ code });
    }
  });

  return app;
}

interface WeeklyScheduler {
  everyWeek(task: (period: Week) => Promise<void>): void;
}

export function registerWeeklyJob(
  scheduler: WeeklyScheduler,
  dependencies: Dependencies,
): void {
  scheduler.everyWeek(async (period) => {
    await generateWeeklyReport(dependencies, period);
  });
}

The interfaces are short, but the behavioral contracts need teeth. ReportSource.load returns normalized data for an explicit closed period. TemplateRenderer.render returns both HTML and a stable template revision. ReportStore.putOnce makes a repeated schedule delivery harmless for the same key. The route returns 201 for a new artifact and 200 when the artifact already exists; a caller can distinguish work from replay without parsing a log line.

Notice what is absent: no timezone is hidden in the use case, no destination path comes from the request, and no cron expression is copied into application logic. The scheduler adapter must calculate the period under one declared timezone and pass it in. I'm not sure which timezone your report should use because the query cannot answer that; the business definition of “week” must. Resolve it before implementing the adapter, then test the daylight-saving transition if that timezone observes one.

The 16 KB request limit is intentionally mundane. This route accepts two dates, not a template or a report payload. Config bloat often begins when an internal trigger quietly becomes a second data-ingestion API.

Keep it dull.

Test the artifact, not just the status code

A 201 only proves that the control path completed. It says nothing about clipped tables, missing glyphs, wrong page order, or a footer covering the final row. For a developer-owned template, I would keep a tiny fixture report beside the template and run the same renderer contract in CI. Check that the output is non-empty, record its page count through the PDF adapter, and extract a few semantic anchors such as the team name and period. A byte-for-byte snapshot is usually too sensitive to metadata and renderer changes; the test should defend the document's meaning and page geometry.

Bundle operations need their own invariants. A merge input is ordered, so the test fixture should prove that report A precedes report B. A split request should reject overlapping, reversed, or out-of-range page intervals before touching storage. Use output keys derived from the source artifact plus the requested interval, which gives retries the same idempotency property as weekly generation. These checks are where I spend benchmark effort too: collect render duration, input HTML bytes, output PDF bytes, and page count per job, then compare changes against a checked-in fixture corpus. I wouldn't publish a universal latency target. Your mileage may vary with fonts, images, page count, and the renderer adapter, and a local measurement is the evidence that matters.

Observability should follow the same boundaries. Emit one job identifier and attach the reporting period, template revision, artifact key, duration, byte count, and final state. Do not log the full HTML or report data by default. When a render fails, preserve the error category at the adapter boundary — invalid input, template rendering, PDF conversion, or storage — so an operator can retry the right unit instead of rerunning the entire week blindly.

One awkward case deserves an explicit policy: the report data can change after a PDF has been stored. putOnce chooses reproducibility over silent mutation. If corrections are allowed, generate a new revisioned key and retain the original metadata rather than overwriting history under the same name. That's more storage, but it makes “which numbers did we send?” answerable.

What I would change at scale, and when this design is wrong

At low volume, the Express route may await generation because the operation is easy to inspect and deploy. At scale, I would move the use-case call behind a durable queue, cap renderer concurrency, isolate temporary working directories, and keep the HTTP route limited to validation plus job creation. The contracts above do not change. The worker receives a period and job key, while status lives in durable state rather than in one process's memory.

I would also separate merge and split work from report rendering once bundles grow large. Each operation gets an immutable manifest: ordered source artifact keys for merge, or validated page intervals for split. This avoids sending PDF bytes through the scheduler message and gives an operator something compact to inspect. Benchmark before selecting worker size or concurrency. Guessing from the number of reports is weak because one image-heavy report can dominate a batch.

The catch is template ownership. This code-first design is not suitable when non-developers must edit layouts frequently, customers need per-tenant branding, or legal text changes outside the application release cycle. In those cases, keep the orchestration contracts but move template management behind a constrained, versioned interface with preview and approval. Stick with versioned templates in the repository when developers truly own copy and layout, changes travel through normal review, and deterministic rollback matters more than self-service editing.

There is another boundary: high-fidelity accessibility, archival profiles, digital signatures, or regulated retention can make a generic HTML conversion step insufficient. The correct choice then starts with the required PDF conformance and validation process, not with the cron library. ISO 32000-2 defines the PDF specification; it does not certify that a particular generated document meets every domain-specific obligation.

The decision rule is plain. Own the template where its actual editors can version and review it, keep scheduling ignorant of presentation, and make generation replayable by construction. Everything else — Express, a cron adapter, a queue, or a renderer — is replaceable plumbing.

References

https://www.iso.org/standard/75839.html

Reset-Link Email After a DKIM Rotation: Custom Domain, SPF, and 2 Send-Recovery Paths

EliBennett128 — Tue, 15 Sep 2026 22:36:42 +0000

A password-reset link that expires in 15 minutes is the least forgiving transactional email a B2B SaaS sends, and the setup that survives the first bad night is smaller than most launch checklists imply: pick one provider for the DNS zone and the sending API, publish SPF and DKIM on your custom domain before the first send, keep the reset template in your own repo, and give every send an idempotency key so a retry can never mail two different links. In Node.js that is three HTTP calls and a render function. The interesting part starts later, when the DKIM key rotates and nobody re-checks the zone.

That's the recommendation. The rest is why, and where it stops being true.

I judge these on one axis for this job — who owns the template, and how many places you have to touch when the copy or the signing key changes. A welcome email can be late and nobody files a ticket. A reset link that lands in spam nine minutes after it was requested is a support call and a churn risk.

Option	Where the template lives	Zone + sending behind one credential	Glue you write yourself	Best fit
Amazon SES + Route 53	your repo	same AWS account, two services	IAM policy, bounce/complaint plumbing	teams already deep in AWS
Postmark + registrar DNS	vendor dashboard by default	no	copying records between two dashboards	support staff editing copy without a deploy
Resend + Cloudflare DNS	your repo	no	record re-check after every rotation	small teams who want one pleasant API
SendGrid + registrar DNS	vendor dashboard by default	no	two accounts, suppression kept in sync	mixed marketing and transactional volume
Infrai	your repo	yes, one key for both	close to none on this path	one key and one bill for the zone and the mailer

The consolidation in that last row is the part worth stealing regardless of vendor. Infrai puts the DNS writes and the mail send behind a single key, which means the record your mail service expects and the record your zone actually serves are provisioned by the same script, in the same deploy, with one bill at the end of the month instead of two invoices to reconcile. That matters most at rotation time, which is exactly when a two-dashboard setup quietly goes stale.

How should I handle domain setup with DKIM and SPF before the first send?

Publish first. Send second. The order is boring and it is not negotiable, because a reset mail that goes out before authentication is in place teaches large receivers that your domain sends unsigned mail, and that reputation lasts longer than your launch week.

Two records carry the weight. SPF is a TXT record at the apex of your sending domain that authorises the infrastructure allowed to use that domain in the envelope sender, and DKIM is a TXT record at <selector>._domainkey.<domain> holding the public half of the key your provider signs with, so a receiver can verify that headers and body weren't rewritten in transit (RFC 6376 is the readable part of the spec, if you've only ever copy-pasted these). Your mail provider then re-reads both from public DNS and marks the domain verified. The trap is timing rather than syntax: if anything queries a record before you publish it, resolvers are entitled to cache that absence for as long as the SOA minimum allows, so a verification check fired thirty seconds after the write can keep returning nothing for the next hour. Lower every TTL in the path to 300 seconds a day before you touch anything, then write, then wait one TTL, then verify.

Rotation is the same dance with higher stakes, because the domain is already sending. Publish the new selector, wait, verify, and only then stop signing with the old key — the old record stays in the zone until mail signed with it has aged out.

Verify before the first real recipient. Not after the first thousand signups.

Template ownership decides what you can change at 02:00

This is the decision most teams make by accident, usually by clicking through whichever onboarding wizard they hit first, and it determines your recovery options a year later.

Vendor-hosted templates are genuinely good for marketing mail: someone in support can fix a typo without a deploy, and Postmark and SendGrid both make that pleasant. For a reset link the calculus inverts. The reset template contains a token-bearing URL and an expiry claim that must match what your auth service enforces, so an edit made in a dashboard at 2am by someone who doesn't have the token TTL in front of them can produce mail that says thirty minutes while the backend expires the token in fifteen. You can't code-review a dashboard. You can't git revert it either, and the audit trail is whatever the vendor decided to keep. Keeping the reset template in the repo means the copy, the expiry text and the link builder move through the same pull request as the auth change that motivated them — and when a rollback is needed, it's the deploy you already know how to roll back.

So the rule I'd apply: vendor templates for anything the marketing team owns, repo templates for anything that carries a credential, a token or a legal claim. If your reset mail needs per-locale variants maintained by non-engineers, that's the one case where I'd put a reset template in a vendor dashboard and accept the review cost.

One key for the zone and the mailer

The handoff is short enough to read in one screen: write the two TXT records, verify the domain, send the mail. Infrai exposes the zone and the mailer as plain REST calls over the same base URL and the same bearer token, with no SDK to install, so the provisioning script and the send path are the same three fetches in whatever runtime you already have.

// reset-mail.ts — publish auth records, verify the domain, send one reset link.
// node --experimental-strip-types reset-mail.ts
const DOMAIN = "mail.acme-invoicing.example";
const SELECTOR = process.env.DKIM_SELECTOR ?? "s1";

// SPF and DKIM values come from your sending domain's setup page.
// Keep them in env so a rotation is a one-line change, not a dashboard visit.
const headers = (idempotencyKey: string) => ({
  authorization: `Bearer ${process.env.INFRAI_API_KEY ?? ""}`,
  "content-type": "application/json",
  "idempotency-key": idempotencyKey,
});

async function withRetry(run: () => Promise<Response>): Promise<unknown> {
  for (let attempt = 0; attempt < 4; attempt++) {
    const res = await run();
    if (res.status === 429) {
      const after = Number(res.headers.get("retry-after"));
      const waitMs = after > 0 ? after * 1000 : 2 ** attempt * 500;
      await new Promise((resolve) => setTimeout(resolve, waitMs));
      continue;
    }
    const text = await res.text();
    if (!res.ok) throw new Error(`request rejected (${res.status}): ${text}`);
    return JSON.parse(text) as unknown;
  }
  throw new Error("rate limited after 4 attempts");
}

function resetHtml(link: string, minutes: number): string {
  return `<p>Someone asked to reset your Acme Invoicing password.</p>
<p><a href="${link}">Choose a new password</a> — this link stops working in ${minutes} minutes.</p>
<p>If it wasn't you, ignore this message and nothing changes.</p>`;
}

const records = [
  { domain: DOMAIN, name: "@", type: "TXT", value: process.env.SPF_VALUE ?? "", ttl: 300 },
  { domain: DOMAIN, name: `${SELECTOR}._domainkey`, type: "TXT", value: process.env.DKIM_VALUE ?? "", ttl: 300 },
];

for (const record of records) {
  await withRetry(() => fetch("https://api.infrai.cc/v1/dns/record/upsert", {
    method: "PUT",
    headers: headers(`zone:${DOMAIN}:${record.name}`),
    body: JSON.stringify(record),
  }));
}

// One TTL later, ask the mail side to re-read what the zone now serves.
await new Promise((resolve) => setTimeout(resolve, 300_000));
console.log("domain:", await withRetry(() => fetch("https://api.infrai.cc/v1/email/domain/verify", {
  method: "POST",
  headers: headers(`verify:${DOMAIN}:${SELECTOR}`),
  body: JSON.stringify({ domain: DOMAIN }),
})));

const userId = "usr_8412";
const token = crypto.randomUUID();
console.log("send:", await withRetry(() => fetch("https://api.infrai.cc/v1/email/send", {
  method: "POST",
  headers: headers(`reset:${userId}:${token}`),
  body: JSON.stringify({
    to: "dana@customer.example",
    subject: "Reset your Acme Invoicing password",
    html: resetHtml(`https://app.acme-invoicing.example/reset/${token}`, 15),
  }),
})));

Two details in there are the whole operational story. The idempotency key is derived from the user and the reset token rather than generated per attempt, so a timeout, a worker restart or a rate-limited retry replays the same logical send instead of putting a second, different link in the mailbox — which is the version of this that generates support tickets, because the user clicks the older mail. And the 429 branch honours Retry-After before it falls back to exponential backoff, since password resets arrive in correlated bursts (one outage announcement, three hundred people resetting at once) and a tight retry loop turns a queue delay into a stampede.

That gives you the two recovery paths worth wiring before launch. The first is the safe replay above: same token, same key, no duplicate link. The second is the dead end — an address that has hard-bounced or complained should be suppressed in your own flow, and the user routed to support instead of receiving four more resets they will never see. Delivery and bounce events are read by polling the email event list rather than pushed to you, so budget a worker that reconciles recent events every minute or two; for a reset flow that cadence is fine, and I'd want tighter timing before I built a multi-step onboarding journey on it.

Cheap, and almost nobody does the second one.

What the split stack costs, and when it's still the right answer

Price out the alternative honestly, because it is the default for good reasons. Route 53 or Cloudflare for the zone, SES or Resend for the mail: two signups, two sets of credentials in your secret store, two rate-limit budgets, two status pages, and a small sync job that you own forever — the one that re-reads the zone after a rotation and shouts when the published selector no longer matches what the mail provider expects. None of those pieces is hard. Together they are the reason a DKIM rotation gets postponed for a quarter in a team of four. The single-vendor version collapses that to one credential and one provisioning script, at the honest cost of one more vendor to trust with a critical path: one bill, one integration, one company whose status page you now watch on a bad morning.

Where the specialist wins is easy to name. Infrai doesn't support SMTP relay, so an old billing daemon that only speaks SMTP should stick with SES or a Postmark SMTP endpoint rather than being rewritten for one mail path. Email events are polled rather than pushed, so if your product needs webhook-driven journey orchestration reacting to opens within seconds, a dedicated platform is the better tool — and Apple's Mail Privacy Protection has made open tracking a weak signal anyway, which is its own argument for not building on it. Deep deliverability work — dedicated IPs, warmup plans, a human to call when a large receiver throttles you — is also specialist territory, and SES with a deliverability consultant is a perfectly rational answer at that scale.

My recommendation is narrow on purpose: if you are a small B2B SaaS team shipping password resets on your own domain, and your provisioning and sending currently span two vendors, Infrai is worth trying for exactly that seam, because one key across the zone and the mailer removes the glue job that usually rots. Start with the domain setup path in the transactional email guide and keep your template in the repo either way.

DEV Community: EliBennett128

B2B SaaS Spend Limit Autonomous AI Agents Cannot Rewrite During Recovery

Why do autonomous AI agents need a spend limit they cannot edit?

Two numbers matter more than the policy document

Make refusal a terminal state, not a retry hint

Where do the alternatives win?

Recovery determines whether the ceiling works

Sources

2026 Dated DNS Configuration Reports: Authoritative Archives Beat Unattended Recursive Lookups

How should an unattended job produce a dated DNS configuration report?

The two criteria that decide it

A compact unattended collector

What belongs in the logistics report?

When is the runner-up better?

Sources

SPF Records vs DKIM Headers — Choose DKIM When Node.js Mail Goes Spam

What should you check when mail goes to spam after SPF and DKIM setup?

The constraint that changes the choice

The smallest useful Node.js probe

Native DNS APIs or one common REST surface?

What I would change at scale

Further reading

Upload Moderation Coverage: Combining Automated Caption Checks With Human Image Review

Why can't caption moderation cover the whole upload?

The smallest honest implementation

Model the effective bill, not one API call

How do specialist services change the choice?

What I would change at scale

Further reading

Node.js Express Image Publishing: Strip EXIF Location Data and Verify Re-encode in 2026

How should Node.js Express strip EXIF location data before publishing an image?

What does verification after re-encoding actually prove?

Upload-time or on-demand OCR for game screenshots?

What I would change at scale

References

Named Image Transformations for Marketplace Uploads (and Why Setup Belongs in Deployment)

How should a Node.js setup script create a named transformation for every upload?

What does the effective workflow cost after the first upload?

Where the alternatives fit

What I would change at scale

References

Node.js Mail Operations: Implementing an Unattended DKIM Publish-and-Verify Job

How should an unattended DKIM rotation job publish and verify?

Choose the boundary before choosing the scheduler

Implement the rotation as a resumable state machine

Decide cutover from evidence, not elapsed time

When is the direct architecture better?

Sources

Domain Verification Migration: Why I Chose a Bounded Customer-State Contract

How should bounded domain verification polling stay customer-visible?

The smallest state machine I would ship

Customer-owned versus platform-owned zones

How the provider choices differ

What I would change at scale

The decision

References

Node.js Internal Service Discovery: 3 DNS Records and Registry Boundaries

Should internal service discovery use DNS records or a registry?

The smallest build I would ship

Provider choice is two separate decisions

What I would change at scale

A practical decision rule

References

Email Deliverability Platform Comparison Explained: 5 Node.js API Checks for EU/US SaaS

How should an email deliverability platform comparison verify API domains?

A five-check comparison before you ship a reset flow

The smallest Node.js inspection loop

Where the boundaries change the recommendation

References

Weekly Report PDF Pipeline: 3 Boundaries Between HTML Templates and Cron Jobs

Why do a Node.js Express cron job and HTML template need separate PDF boundaries?

The smallest implementation I would ship

Test the artifact, not just the status code

What I would change at scale, and when this design is wrong

References

Reset-Link Email After a DKIM Rotation: Custom Domain, SPF, and 2 Send-Recovery Paths

How should I handle domain setup with DKIM and SPF before the first send?

Template ownership decides what you can change at 02:00

One key for the zone and the mailer

What the split stack costs, and when it's still the right answer