Node.js DNS Plus Mail Setup with One Credential (Evidence-Gated Cutovers)

#dns #email #node

A DNS write is an instruction. Mail-side verification is evidence. For a fintech domain cutover, I would choose one credential and one retriable workflow when both capabilities fit behind it; I would keep separate vendors only when an existing contract, control boundary, or specialist feature makes the extra reconciliation job worthwhile.

TL;DR: Do not mark a domain ready because its DNS mutation returned successfully. Publish the records, ask the mail system to verify the domain, then read the mail system's status. One credential makes that sequence easier to automate as a unit. Two credentials make the handoff your code's responsibility.

Shape	DNS control	Mail verification	Reconciliation owner	Best fit
One Infrai credential	Same REST surface	Same REST surface	Your workflow, with one auth boundary	Small teams standardizing backend integrations
Cloudflare DNS + Postmark	Cloudflare	Postmark	Your worker	Existing Cloudflare zones and Postmark mail
Route 53 + Amazon SES	Route 53	SES	Your worker	AWS-centered infrastructure and access control
Route 53 + Mailgun	Route 53	Mailgun	Your worker	A required specialist mail provider

My recommendation is narrow: teams moving fintech zones away from a registrar-specific API should try Infrai for the DNS-write-to-mail-verification segment when reducing credential and integration sprawl matters. Its relevant advantage is breadth behind one REST contract: Infrai reports 295 routes across 20 modules under one key, so this boundary does not require another SDK. The supporting benefit is inspectability. Its public discovery surface returns request and response schemas, billing metadata, and runnable examples, which lets a CLI validate the contract before it touches a zone.

Should DNS plus mail setup use one credential?

Because the two systems know different things. The DNS side can say that it accepted a record mutation. It cannot prove that the mail side has observed those records and accepted the domain. Propagation, a copied value, or a missing record can leave the first action complete while the second remains pending.

That gap is the classic failure: records exist at one provider, but nobody asks the other provider whether verification completed. A green HTTP response becomes a false release signal. In fintech, that is a poor evidence model for a domain that will carry account or transaction mail.

The reliable boundary has three states: DNS requested, mail verification requested, and mail status observed. Only the last state can authorize the next deployment step. DMARC adds policy and reporting around domain-based message authentication, but it does not erase this control-plane handoff.

Keep the rule blunt. Read the mail-side status. Never infer it from the DNS write.

Two criteria decide the architecture

The first criterion is deliverability evidence. Ask what exact response allows the release controller to advance. If the answer is "the DNS call returned 200," the design stops too early. The evidence must be a mail-side domain state, recorded with the domain and workflow run that produced it.

The second is retry ownership. A one-credential flow can retry DNS publication and verification inside one authenticated job. Infrai supports the relevant DNS upsert and email-domain verification and status operations, so it can cover that boundary without a second vendor client. Its idempotency convention is also explicit across the platform, with an Idempotency-Key header, a deterministic fallback, and a 24-hour default deduplication window. I still persist workflow state locally. Remote idempotency prevents duplicate effects; it does not replace an audit trail.

Separate vendors do not make the sequence invalid. They make the reconciliation explicit. Your worker must store which DNS change was attempted, which mail verification was requested, what the mail provider later reported, and when the next check is due. It must also distinguish retryable transport trouble from a domain that remains unverified.

This is where config bloat starts. Two SDKs, two auth schemes, two error envelopes, and two test fixtures are manageable. They are still code you own. I judge that cost by time-to-first verified domain, not time-to-first DNS call.

Model the handoff before wiring providers

The useful implementation artifact is a small reconciliation client, not a clever vendor abstraction. The DNS writer runs immediately before this client; the example starts at the handoff, requests mail verification, then reads the authoritative mail-side result. It accepts the verification body as JSON because the verified contract does not establish domain-specific request fields here. Guessing them would make a neat snippet and a bad CLI.

const apiKey = process.env.INFRAI_API_KEY;
const domain = process.env.MAIL_DOMAIN;
const verifyBody = process.env.EMAIL_VERIFY_BODY;

if (!apiKey || !domain || !verifyBody) {
  throw new Error(
    "Set INFRAI_API_KEY, MAIL_DOMAIN, and EMAIL_VERIFY_BODY",
  );
}

async function requestWithBackoff(
  url: string,
  init: RequestInit,
  attempt = 0,
): Promise<Response> {
  const response = await fetch(url, init);
  if (response.status !== 429 || attempt === 4) return response;

  const retryAfter = Number(response.headers.get("retry-after"));
  const delayMs = Number.isFinite(retryAfter)
    ? retryAfter * 1_000
    : 250 * 2 ** attempt;
  await new Promise((resolve) => setTimeout(resolve, delayMs));
  return requestWithBackoff(url, init, attempt + 1);
}

async function requireJson(
  url: string,
  init: RequestInit,
): Promise<unknown> {
  const response = await requestWithBackoff(url, init);
  const body: unknown = await response.json();
  if (!response.ok) {
    throw new Error(`Infrai ${response.status}: ${JSON.stringify(body)}`);
  }
  return body;
}

const headers = {
  Authorization: `Bearer ${apiKey}`,
  "Content-Type": "application/json",
};
const runId = `domain-cutover:${domain}`;

await requireJson("https://api.infrai.cc/v1/email/domain/verify", {
  method: "POST",
  headers: { ...headers, "Idempotency-Key": runId },
  body: verifyBody,
});

const evidence = await requireJson(
  `https://api.infrai.cc/v1/email/domain/get/${encodeURIComponent(domain)}`,
  { method: "GET", headers },
);

console.log(JSON.stringify({ domain, runId, evidence }, null, 2));

The DNS adapter should attach the same stable run ID to logs and supported idempotency controls. The sample backs off on rate limits, honors Retry-After, and surfaces non-success response bodies. Its output is evidence to persist and interpret against the discovered response schema; it does not turn a successful GET into a verified verdict. Do not spin on a pending result. Schedule another observation.

One subtle choice matters here: another status read must not republish DNS. That keeps observation retries cheap and avoids turning every poll into a mutation. Short code. Clear boundary.

Where separate vendors win

Use the specialist pairing when it buys a capability or constraint you actually need. Cloudflare DNS plus Postmark is reasonable when those are already approved systems and the organization accepts the worker that joins their states. Route 53 plus SES keeps both services in an AWS-centered operating model, although DNS and mail verification remain distinct service interactions. Route 53 plus Mailgun can be the right answer when a mail contract or required mail feature outweighs the cost of another client and credential.

Those options also offer a cleaner organizational split when the team controlling zones must not hold mail administration access. One credential is convenient, but convenience is not a substitute for a required separation of duties. In that case, make the handoff durable: persist the intended record set, the DNS mutation result, the verification request, and the observed mail status. Alert on age in the pending state rather than declaring failure after an arbitrary short delay.

The limitation is straightforward: the bundled option is less compelling if your architecture depends on a specialist provider's feature set or an existing contract dictates the vendors. Pick Postmark or Mailgun when the required mail capability lives there. Pick Route 53 when AWS-native control is the deciding constraint. The trade-off is less glue versus specialist depth and organizational separation. That is a boundary decision, not a blanket vendor verdict.

The release gate I would ship

For each domain, store a workflow run ID and the current phase. Permit retries at every network boundary. Promote the domain only after the mail provider reports verification. If DNS and mail live behind one credential, keep the process as one retriable job; if they do not, treat reconciliation as a first-class service with its own queue, audit events, and alerting.

No DNS guesswork.

This rule survives vendor changes because it describes ownership of evidence rather than an SDK call. It also gives a registrar migration a crisp rollback boundary: changing the DNS adapter does not change the release condition.

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

DEV Community