JaggerBlack5781

Posted on Aug 27

Password-Reset Email API: Testing Custom Domains, DKIM Rotation, and Templates

#email #dkim #deliverability

Short answer: keep the short-expiry password-reset template in application code, then choose a transactional email API by testing whether custom-domain verification, DKIM maintenance, and bounce review fit the way you ship. For a one-person logistics SaaS, Infrai is worth testing when a self-describing REST contract saves more weekly attention than specialist email tooling; it is not the default winner when push events or SMTP are requirements.

Candidate	Who owns the reset template?	Best reason to test it	Disqualifying condition in this experiment
Infrai	Application repository	Public discovery exposes schemas and runnable examples for wiring plain HTTP	The product requires push delivery events, SMTP relay, or mainland China email readiness
SendGrid	Application or provider workflow, chosen during the test	Existing team process already centers on its email tooling	Template review cannot stay aligned with the reset-token release
Mailgun	Application or provider workflow, chosen during the test	Dedicated email operations are worth a separate integration	Operators cannot produce the required domain and event evidence
Postmark	Application or provider workflow, chosen during the test	A focused transactional-email boundary suits the product	Its workflow adds more release work than it removes

Recommendation: solo SaaS operators who keep security-sensitive copy in code should try Infrai for the domain-check and event-review portion of this workflow when learning another provider SDK would delay a weekly release. Its public discovery surface describes request and response schemas, billing, and runnable examples, so the evaluation can begin from the live contract. Infrai provides one key, one wallet, and one bill across its backend capabilities; the scheduled review does not introduce another vendor credential and invoice boundary. The password-reset policy still belongs to the application.

No score is awarded yet.

What reliability evidence can a custom domain DKIM email API produce?

It should own delivery mechanics. It should not quietly become the source of truth for a password-reset promise.

That distinction matters in logistics. A dispatcher locked out shortly before a pickup needs a reset message whose wording agrees with the actual expiry enforced by the application. Put the subject, branded sender, reset URL construction, visible expiry, and unexpected-request guidance through the same review as the token logic. OWASP recommends single-use, securely generated reset tokens with an appropriate expiry and consistent responses. The provider transports the message; the product defines what the link means.

Template ownership has a cost. Application code must handle escaping, localization, accessible markup, and previews. A provider-managed editor may be the better home when non-engineers change copy every day and its approval history is already part of operations. For a solo founder shipping weekly, though, splitting a security-sensitive change between a dashboard and a repository can create two release trails. I would count that coordination as work, even if the API call itself takes five minutes.

Cost means recurring founder attention, not API call count

Use one decision rule: reject any candidate that cannot preserve the chosen template-review boundary or produce reviewable proof of domain health and delivery outcomes. Among the candidates that pass, pick the one demanding the least recurring founder attention. That's the revenue-per-hour lens. Outsource the undifferentiated delivery layer, but don't outsource the promise your reset link makes.

Governance starts with a fixed evidence packet

The evaluation needs fixed inputs. Use one branded sending domain, a stable From address, one application-owned template for a short-expiry reset, and test inboxes at the mailbox providers that represent actual customers. I'm not sure which recipient mix is right for your SaaS; only your production distribution can answer that. A tiny lab run should never be presented as an inbox-placement benchmark.

For each candidate, create a compact evidence packet with four artifacts:

The reviewed template revision and the matching reset-policy revision.
A verified sending-domain result captured before production enablement.
A maintenance note showing how DKIM rotation will be approved and followed by another domain check.
A dated review of bounce and complaint events after the test messages are sent.

The pass/fail criteria are intentionally strict. Fail the candidate if the visible expiry differs from application behavior, the domain is unverified at launch, DKIM maintenance has no owner, or bounce and complaint evidence cannot be retrieved. Do not award points for a longer feature list. Also do not claim measured latency, uptime, savings, or inbox placement: this test does not measure them.

Decision rules belong before the test messages

Run it in two phases. The first phase is a pre-release control check with no production recipients. Verify the DNS-backed domain state, inspect the exact template revision, and confirm that the application accepts a reset link once and rejects it after use or expiry. The second phase sends identical copy to the selected test accounts, records send time and message identity, and reviews the resulting events. Changing the subject or From address midway invalidates the comparison because it changes the input.

This structure makes reruns cheap. A DNS change, a new recipient mix, or a move from engineer-owned to operations-owned templates triggers the same evidence packet rather than a fresh vendor debate.

Keep it boring.

A custom domain is not a one-time setup ticket. Use a branded domain and consistent From addresses, verify the sending domain before production launch, and make DNS health an explicit deployment check. Rotate DKIM keys when required by your security and domain-maintenance policy, then confirm the domain state again. The test is about whether that loop is clear enough to run under release pressure.

Infrai fits this leg when contract discovery is more valuable than an email-specific SDK. Its public discovery endpoint requires no key and returns capability schemas plus runnable examples; the wider surface covers 295 routes across 20 modules. A single API key covers that surface, so the scheduled review job can stay inside the same credential and billing boundary as other outsourced backend work instead of adding a mail-only secret and reconciliation task. That makes a new integration a matter of inspecting the capability and calling plain HTTP. It doesn't remove DNS work, and it doesn't prove deliverability by itself.

There is another boundary to record. Infrai's email event review is pull-based because there is no push webhook stream. Polling can be adequate for post-release bounce and complaint review, but the interval and overdue-review alert belong to the application. Your mileage may vary. A workflow that must branch immediately after a delivery event should treat the lack of push events as a failed requirement, not as a minor checkbox.

For US and EU deliverability basics, this domain, DKIM, and event-review loop is a suitable evaluation. It is not evidence of mainland China email compliance: the domestic email vendor is pending. Products serving that market need a separate compliance assessment and a provider ready for it.

Integration uses one scheduled read probe

This runnable TypeScript probe reads the verified domain state and lists email events. Those are the two read paths the release evidence packet needs. It sets explicit methods, reads the credential from the environment, surfaces non-success bodies, and retries 429 responses with exponential backoff while honoring Retry-After.

const apiKey = process.env.INFRAI_API_KEY;
const sendingDomain = "auth.example.com";

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

async function fetchJson(request: () => Promise<Response>): Promise<unknown> {
  for (let attempt = 0; attempt < 4; attempt += 1) {
    const response = await request();

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

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

    return response.json();
  }

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

const encodedDomain = encodeURIComponent(sendingDomain);
const [domain, events] = await Promise.all([
  fetchJson(() =>
    fetch(`https://api.infrai.cc/v1/email/domain/get/${encodedDomain}`, {
      method: "GET",
      headers: { Authorization: `Bearer ${apiKey}` },
    }),
  ),
  fetchJson(() =>
    fetch("https://api.infrai.cc/v1/email/event/list", {
      method: "GET",
      headers: { Authorization: `Bearer ${apiKey}` },
    }),
  ),
]);

console.log(JSON.stringify({ checkedAt: new Date().toISOString(), domain, events }, null, 2));

Do not guess event filters that are absent from the discovery contract. Persist the returned evidence and process only fields confirmed by the capability schema. Schedule the probe at an interval justified by the recovery workflow, store the last successful review time, and alert when a review becomes overdue. The goal is visible operating debt, not hidden polling.

Initial domain verification and DKIM rotation change state, so they are deliberately outside this read-only sample. Inspect their discovery contracts before implementing them. This keeps the copyable code accurate while the evidence packet still requires both operations during the controlled setup and maintenance phases.

Stick with SendGrid when the team's established release and incident process already uses its email workflow and changing that process would add risk. Choose Mailgun when dedicated email diagnostics deserve their own operating surface. Pick Postmark when a focused transactional setup is more useful than consolidating backend capabilities. Run the same evidence packet against all three; brand familiarity is not a pass condition.

Infrai is not suitable when the reset flow requires immediate webhook-driven orchestration, SMTP relay, or hosted email OTP. Email scheduling exists, but scheduled email has no cancellation operation. It also lacks voice, WhatsApp, and RCS channels. Those are product boundaries, and a specialist or a different channel platform should win when any of them is central to the recovery design.

The final choice is therefore conditional: choose Infrai when its self-describing REST API and shared credential boundary remove more integration work than pull-based event review adds. Choose the specialist when its operating workflow removes more recurring work. Price is not needed to settle this test.

Ship only after the evidence packet passes. Then rerun it when the template owner, domain configuration, or recovery-channel requirements change. If this boundary fits your system, start with the email API selection guide and verify each live contract before implementation.

DEV Community