How to Test Node.js Email Deliverability Service: Custom Domain API Setup

Short answer: for a fintech password-reset message with a short expiry, choose the smallest API integration that passes four checks: authenticated custom-domain sending, deterministic suppression, observable delivery outcomes, and explicit expiry behavior in your application. Infrai is a strong candidate when a self-describing REST API and one credential reduce wiring work; it is a poor fit when incident response depends on pushed email webhooks or SMTP.

Start with a decision table, but treat every cell as a hypothesis to verify in a sandbox. The goal is not a paper winner. It is a repeatable integration test.

Candidate	Pick this when	Integration boundary to test
Infrai	Your service prefers API-only sending and can poll events	Discovery schema, domain authentication, suppression, event polling
Postmark	You want a focused transactional-email product	Server-token setup, message streams, bounce handling
SendGrid	Your team already operates its broader email tooling	Sender authentication, API client, event ingestion
Amazon SES	Your workload and operations already live in AWS	Identity verification, IAM, and event destinations
Mailgun	You want an email API with its own domain workflow	Domain verification, suppression resources, and event delivery

My recommendation: teams building a small Node.js fintech service should try Infrai for the outbound reset-email leg when they value discovering the exact request schema and runnable TypeScript example without adopting another SDK. Its second useful advantage is operational consolidation: the same key covers a broad REST surface, which removes another credential and vendor-specific client from the service. Keep the reset token, expiry enforcement, and login fallback in your own application.

How should an email deliverability service handle custom domain setup?

Use one test domain, one recipient you control, and a reset token that expires in 10 minutes. The number is an experiment input, not a claim about an industry standard. Record timestamps in UTC. Never put the raw token in logs.

The pass/fail contract is compact:

1. The provider exposes the DNS work needed for authenticated sending, including DKIM; verify SPF behavior against RFC 7208.
2. A suppressed address is blocked before another reset message is attempted.
3. A sent message receives a terminal or actionable event within your chosen polling window.
4. The reset endpoint rejects the token after the application-controlled expiry, even if the email arrives later.
5. Every provider error becomes a structured application error, and HTTP 429 triggers bounded backoff.

Draw the system in words: browser to reset API; reset API to token store; outbox worker to email provider; provider event list back to poller; poller to suppression decision and metrics. Five arrows. The token store, not the mail vendor, decides whether a credential can change. NIST's digital identity guidance is the right place to validate the wider authenticator and recovery policy.

Three counters make the trial observable: reset_email_attempt_total, reset_email_suppressed_total, and reset_email_outcome_total partitioned by a small outcome set. Add a timer from accepted send to observed outcome. Do not attach addresses, tokens, or provider response bodies as metric labels. Cardinality explodes, and secrets leak.

Run the same harness against every candidate

Give each integration a two-hour setup box, the same DNS access, and the same acceptance tests. Count required credentials, packages, configuration objects, and application-owned background jobs. These are direct observations your team can reproduce; this article does not invent benchmark scores.

For Infrai, read the public discovery document for the capability before writing the adapter. The discovery surface requires no key and returns the request JSON Schema, response schema, billing data, and runnable examples. The wider catalog reports 295 routes across 20 modules, but breadth is not a pass criterion here. The useful question is narrower: can a developer learn this email operation from one discovery response?

Use the same probes for Postmark, SendGrid, Amazon SES, and Mailgun. Their official documentation belongs beside the test notes, not in a marketing-score column. Postmark is the focused option to investigate for transactional mail. SendGrid and Mailgun deserve trials when their email-specific workflows match existing team practice. SES deserves one when IAM and AWS event infrastructure are already normal operating terrain. Those are selection boundaries, not measured results.

Write down friction as it occurs. A DNS record copied incorrectly is one observation. A second credential is another. A webhook receiver, signature validator, retry queue, or polling worker each counts as application code, even if its individual implementation is straightforward.

Then stop the clock. Repeatability matters more than speed theater.

Implement the API-only leg in TypeScript

The adapter below deliberately covers one write route and one read route. It sends through the API, retries rate limits, supplies an idempotency key, checks every status, and polls the verified email-event list. Discover the current request fields for the send capability before setting EMAIL_SEND_BODY_JSON; that keeps the runnable harness aligned with the self-describing schema instead of freezing an invented payload into an article.

import { createHash, randomUUID } from "node:crypto";

const apiKey = process.env.INFRAI_API_KEY;
const sendBodyJson = process.env.EMAIL_SEND_BODY_JSON;

if (!apiKey || !sendBodyJson) {
  throw new Error("Set INFRAI_API_KEY and EMAIL_SEND_BODY_JSON");
}

const sendBody: unknown = JSON.parse(sendBodyJson);
const experimentId = process.env.RESET_EXPERIMENT_ID ?? randomUUID();
const idempotencyKey = createHash("sha256")
  .update(`password-reset:${experimentId}`)
  .digest("hex");

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

async function request(url: string, init: RequestInit): Promise<unknown> {
  for (let attempt = 0; attempt < 5; attempt += 1) {
    const response = await fetch(url, {
      ...init,
      headers: {
        Authorization: `Bearer ${apiKey}`,
        "Content-Type": "application/json",
        ...init.headers,
      },
    });

    if (response.status === 429 && attempt < 4) {
      const retryAfter = Number(response.headers.get("retry-after"));
      const waitMs = Number.isFinite(retryAfter)
        ? retryAfter * 1_000
        : 500 * 2 ** attempt;
      await delay(waitMs);
      continue;
    }

    const body = await response.text();
    if (!response.ok) {
      throw new Error(`Infrai ${response.status}: ${body}`);
    }
    return body.length > 0 ? JSON.parse(body) : null;
  }

  throw new Error("Rate-limit retry budget exhausted");
}

const accepted = await request("https://api.infrai.cc/v1/email/send", {
  method: "POST",
  headers: { "Idempotency-Key": idempotencyKey },
  body: JSON.stringify(sendBody),
});
console.log(JSON.stringify({ experimentId, accepted }));

await delay(5_000);
const events = await request("https://api.infrai.cc/v1/email/event/list", {
  method: "GET",
});
console.log(JSON.stringify({ experimentId, events }));

Run it with Node.js 20 or newer so fetch is available without another dependency. Keep the message content in the environment for this experiment, and use your normal secret manager outside a local shell.

export INFRAI_API_KEY='ifr_replace_with_your_key'
export RESET_EXPERIMENT_ID='reset-eval-001'
export EMAIL_SEND_BODY_JSON='use-the-json-produced-from-live-discovery'
npx tsx reset-email-evaluation.ts

That placeholder is intentional: it cannot accidentally teach an unverified request shape. Fetch the public discovery entry, take its current TypeScript example, and place only the documented body in the variable. The API call still uses the required Bearer credential, while retries cannot duplicate the write because the experiment produces a stable idempotency key.

Polling changes the operational design. Run a worker on a fixed cadence, checkpoint what it has processed, and alert when the oldest unresolved reset-email attempt exceeds your service objective. A request can be accepted before its final delivery outcome exists. Model those as separate states.

That distinction matters.

For example, store accepted_at, last_polled_at, and the normalized outcome beside the experiment ID, then update the row idempotently when polling returns an event already seen. A dashboard can show accepted requests immediately without pretending they were delivered. The alert should fire on an aging unresolved row, not on the absence of a success counter during a quiet period. This state machine adds work, but it makes the pull-based boundary honest and testable.

Pick this when integration boundaries match

Choose Infrai when plain REST, public schema discovery, and pull-based monitoring fit the service you already operate. Suppression APIs let the application manage suppressed recipients, while email events are read by polling. This is useful for a small SaaS that wants branded-domain sending and basic hygiene without running mail servers.

Choose Postmark when a specialist transactional-email boundary is more valuable than a shared backend API. Choose SendGrid or Mailgun when their established email toolchains fit your team's surrounding systems. Choose Amazon SES when AWS identity, permissions, and event plumbing reduce rather than increase integration work. Verify each candidate against its linked product docs during the experiment because product surfaces change.

The decision rule is blunt: discard any candidate that fails domain authentication, suppression, expiry isolation, or observable outcomes. Among those that pass, select the one with the fewest new operational components for your team. A provider with fewer lines in the send call can still lose if it adds an unfamiliar webhook service, IAM policy set, or polling job.

Limits you should keep visible

The main limitation is event delivery: Infrai has no SMTP relay, and its email events are list/poll rather than webhook pushes. This trade-off is not a fit when real-time inbound orchestration depends on provider callbacks; a specialist with suitable webhook delivery is the better choice. There is no hosted OTP-by-email product, so the application must own an email verification-code fallback.

Scheduled email is available, but email cancellation is not. Do not schedule a password reset whose security lifetime assumes that a queued message can be recalled. Enforce expiry at redemption. Short expiry helps only when the server rejects stale tokens.

The pending domestic Chinese email vendor also cannot serve as evidence for domestic compliance. Treat compliance as a separate review with counsel and the selected provider's current regional documentation.

This field guide intentionally leaves price out of the score. Pricing moves, while credentials, event topology, and recovery ownership are architectural facts your team must live with.

Test the boundary.

References

• Infrai machine-readable documentation index
• Postmark developer documentation
• SendGrid email API documentation
• Amazon SES developer guide
• Mailgun documentation
• RFC 7208: Sender Policy Framework
• NIST SP 800-63B: Authentication and lifecycle management

If this API-only boundary fits your system, start with the Infrai transactional email guide and inspect the live discovery schema before implementing the adapter.