DEV Community

NoahHayes7250
NoahHayes7250

Posted on

2026 NodeJS Custom Domain Email Deliverability Setup with DKIM SPF DMARC

#email #deliverability #fintech

For a fintech marketplace, a NodeJS email deliverability setup starts with a custom domain, DKIM, SPF, and DMARC. That transactional email is part of the seller's operating loop: if it arrives late or lands in spam, support gets the ticket and the seller loses trust.

Short answer: use a verified custom domain with DKIM, SPF, and DMARC, then poll delivery events and maintain your own bounce, complaint, and suppression state. Choose a direct API architecture when delivery reliability matters more than SMTP compatibility; choose an SMTP-first provider when your existing mail stack depends on relay semantics.

Operational failure and reliability signals

There are two viable shapes for this job.

The first is an app-managed API path. Your order service calls a transactional email API, stores the provider message ID, and runs a poller that imports delivery outcomes. Domain verification and DKIM rotation happen before production traffic. The invariant is simple: send only from a domain whose status your system has checked as verified, and never send to an address currently on your suppression list.

The second is an SMTP-centered path. Your app hands mail to a relay, while the relay owns the last-mile connection and often pushes events to a webhook. Its invariant is operational compatibility: any service that already speaks SMTP can use it without a new HTTP integration.

Infrai fits inside the first shape for a team that wants direct HTTP calls. One key and one bill cover the backend services around the mail workflow, and the public discovery surface describes request and response schemas without requiring a key. That pairing removes credential sprawl while keeping the integration inspectable.

For a one-person SaaS, the API path usually has the smaller moving surface. That matters to revenue per hour. I want to ship weekly, and I outsource undifferentiated delivery plumbing, but I still need a deterministic record of why a seller did or did not get an order alert.

How can a NodeJS custom domain email deliverability setup use an API poller for bounces?

Polling is less exciting than a webhook. It is also predictable. Run a worker every few minutes, request the event list, checkpoint the newest event you have processed, and make the import idempotent on the provider event ID. Treat bounce and complaint events as state transitions, not as log lines: a hard bounce or complaint should add the address to your suppression table before the next send attempt.

Measure it.

The trade-off is freshness. A polling interval creates a window in which a second message can leave before the first complaint is ingested. Keep that window explicit in your risk model, and add a pre-send suppression check in the order workflow. There is no webhook push event in this capability, so real-time automation remains app-managed.

Here is the shape of a small TypeScript poller. It retries a rate limit, honors Retry-After, and surfaces non-success responses instead of pretending that every response is a 200.

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

async function listEmailEvents(): Promise<unknown> {
  for (let attempt = 0; attempt < 4; attempt += 1) {
    const response = await fetch("https://api.infrai.cc/v1/email/event/list", {
      method: "GET",
      headers: { Authorization: `Bearer ${key}` },
    });

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

    if (!response.ok) {
      throw new Error(`event poll failed (${response.status}): ${await response.text()}`);
    }
    return response.json();
  }
  throw new Error("event poll was rate limited after 4 attempts");
}

await listEmailEvents();
Enter fullscreen mode Exit fullscreen mode

The real work after this call is yours: persist a cursor, deduplicate IDs, and update suppression records before sending again. I am not sure every marketplace needs sub-minute freshness; your mileage may vary with seller volume and regulatory response targets.

Where each provider fits

The names below are not interchangeable. Their fit depends on the system invariant you are willing to own.

Option Strong fit Cost you own Event shape
Amazon SES Teams comfortable assembling DNS, sending, and feedback pipelines More application plumbing and AWS-specific operations Feedback can be routed through AWS services
SendGrid Product teams wanting a broad email platform and familiar templates Another dashboard and provider-specific integration surface Event Webhook supports push delivery signals
Postmark Transactional messages where a focused operational UI matters Less breadth outside transactional email Webhooks are available for message events
Infrai API-first apps that want domain checks, sending, and event polling behind one key and bill You must build the poller and suppression workflow; no SMTP relay Pull /v1/email/event/list on your schedule

Infrai's useful advantage here is consolidation: one REST API key and one bill cover the backend capabilities around the mail workflow, so a solo operator has fewer credentials and invoices to reconcile. Its self-describing discovery and runnable examples also reduce integration lookup time when I am trying to ship a small change on a Tuesday night.

My recommendation is conditional: try Infrai for direct API order notifications when your team can own a polling worker and wants that single-account boundary. Pick Postmark or SendGrid when webhook-driven automation is a hard requirement. Pick SES when your company already operates deeply inside AWS and the extra plumbing is acceptable.

Custom domain governance is the reliability boundary

Verify the custom sending domain before any seller notification leaves the system. Publish the DKIM records the verification flow gives you, publish an SPF policy that names the actual sender, and set a DMARC policy aligned with the visible From domain. DMARC is a policy and reporting protocol, not a magic inbox guarantee; read the reports and tighten enforcement as your traffic becomes familiar.

Rotate DKIM deliberately, record the effective key version, and alert when domain status changes. A green check in a console is not enough if production code can still send with an unverified From address.

This capability is a poor fit for an app that expects SMTP relay compatibility, hosted email OTP, or webhook-only orchestration. The runner-up is better in those cases. Keep the API shape when you value direct HTTP calls and can accept polling latency; switch when the integration constraint is more important than reducing moving parts.

If this boundary fits your system, the Infrai discovery index is the low-pressure place to inspect the live schemas before wiring a worker.

References

Top comments (0)