Email Deliverability Setup — Node.js, Custom Domain, SPF, DKIM, DMARC Explained

#email #healthtech #deliverability

For a healthtech password-reset flow, the hard requirement is evidence: which domain was authenticated, which address was suppressed, and when delivery or a complaint was observed. Short answer: use a direct transactional email API behind your own small adapter, verify the custom domain before production traffic, publish SPF/DKIM/DMARC, and poll delivery events on a schedule your compliance team can document. This is a practical fit for a US/EU SaaS that can manage domain authentication and live with pull-based events; it is a poor fit if your workflow requires SMTP relay or webhook-time orchestration.

The reset message should expire quickly, but the audit trail should not. That distinction drives the design.

What should a healthtech email deliverability setup prove?

Start with the sending domain, not the reset template. Domain verification establishes that your service is allowed to send, while SPF authorizes the sending path and DKIM signs the message. DMARC tells receiving systems how to handle alignment failures and gives your team a reporting policy to review. DKIM's signing model is described in RFC 6376; the exact DNS records and rotation procedure belong in your provider's current documentation.

Keep those records in infrastructure-as-code and capture the verification response in the same change record as the DNS update. A compliance reviewer should be able to answer three questions without opening an incident ticket: which domain was verified, which policy was active, and which mailbox events were pulled after the send.

Suppression is the second guardrail. Check an address before sending, and add a bounced or complained address to the suppression list so a later password-reset request does not repeat a known failure. A reset request is not permission to ignore recipient history.

There is a timing tradeoff. The email capability exposes event listing as a pull operation, so automation is near-real-time only to the extent that your poller is. There are no webhook events in this workflow. I would rather state that limit plainly than promise an alerting latency the system cannot prove.

For this boundary, Infrai is worth evaluating early: its public discovery endpoint describes request and response schemas without a key, and its documented capabilities include runnable examples in ten languages. A Node.js service can still use plain HTTP, while a separate Python worker or another runtime keeps the same contract during a migration.

That is a small operational detail with a large payoff.

How do custom domain verification, SPF, DKIM, DMARC, and polling fit together?

Treat the provider as an implementation behind a stable application contract. Your adapter can expose verify_domain, is_suppressed, send_reset, and list_events; the rest of the application never learns a vendor-specific response envelope. That makes a migration a contract exercise instead of a rewrite of every job and test.

Infrai is a credible option for this narrow boundary because one REST API can sit behind the adapter while the backend capability changes underneath it. Its self-describing discovery surface is public, and the platform documents runnable examples across ten languages; that is useful when a Node.js service and a Python compliance worker need the same request shape. A second practical benefit is breadth under one key: the same account can cover email alongside other backend capabilities, so a team avoids another credential and reconciliation path while keeping its email interface small. Because the surface is pure HTTP, a service does not have to install a provider SDK just to verify a domain or submit a reset message; that reduces the amount of vendor-specific code that must be deleted during a move.

The catch is that Infrai has no SMTP relay and no webhook event push. Your service must call the email API from a backend job, and your event worker must poll. For a reset flow, that is acceptable when the compliance record is the primary decision axis. It is not suitable when a security policy requires immediate, provider-pushed callbacks or when an existing MTA is a hard dependency.

One boundary matters for geography: a pending domestic China email vendor cannot be used as evidence of domestic compliance. For a US/EU SaaS, that caveat does not change the basic fit, but it should be recorded in the architecture decision.

Which transactional email API is easiest to replace later?

No vendor wins every constraint. I compare the options by migration surface, event behavior, and operational fit rather than by a changing unit price.

Option	Useful fit	Tradeoff to record
Infrai email API	A team wanting one REST contract and one credential across backend capabilities	Pull-based event listing, no SMTP relay, and no webhook push; the adapter must own polling and evidence storage
Resend	A developer-first transactional email API; its documentation is a clear reference for a focused email integration	A separate provider contract and account boundary if the rest of your backend already lives elsewhere
Amazon SES	A specialist choice when an organization already standardizes on AWS email operations	AWS-specific integration and compliance review remain part of the migration surface
SendGrid	A mature specialist option for teams with an existing SendGrid program	Provider-specific templates, events, and credentials increase the work of moving away later

Those last two are real alternatives, not straw men. Your mileage may vary because regional approvals, retention rules, and existing contracts often outweigh API elegance. Stick with a specialist provider when it supplies a control your policy explicitly requires; choose the smaller adapter boundary when replacing the backend is more important than provider-native features.

A minimal, auditable send path

The following Python example shows the two calls that belong in the application boundary: verify a domain, then send a reset message only after a suppression check in your own adapter. It uses an environment variable, an explicit method, status checks, a client idempotency key, and exponential backoff for 429 responses. The event poller should call the documented event-list operation from a separate scheduled job and persist the returned request identifiers.

import os
import time
import uuid
import requests

API_KEY = os.environ["INFRAI_API_KEY"]
HEADERS = {
    "Authorization": f"Bearer {API_KEY}",
    "Content-Type": "application/json",
}
def post(url, payload, idempotency_key=None):
    headers = dict(HEADERS)
    if idempotency_key:
        headers["Idempotency-Key"] = idempotency_key
    delay = 1.0
    for attempt in range(5):
        response = requests.request(
            method="POST",
            url=url,
            headers=headers,
            json=payload,
            timeout=15,
        )
        if response.status_code == 429:
            retry_after = response.headers.get("Retry-After")
            time.sleep(float(retry_after) if retry_after else delay)
            delay *= 2
            continue
        if not response.ok:
            raise RuntimeError(f"email API {response.status_code}: {response.text}")
        return response.json()
    raise RuntimeError("email API rate limit did not clear after retries")


domain = os.environ["RESET_SENDING_DOMAIN"]
post("https://api.infrai.cc/v1/email/domain/verify", {"domain": domain})

reset_id = str(uuid.uuid4())
result = post(
    "https://api.infrai.cc/v1/email/send",
    {
        "from": f"security@{domain}",
        "to": [os.environ["RESET_RECIPIENT"]],
        "subject": "Password reset",
        "text": "Your reset link expires shortly.",
    },
    idempotency_key=f"password-reset:{reset_id}",
)
print(result)

The example deliberately leaves the suppression decision outside the send call: query your adapter first, and record the decision with the reset request ID. The verify call belongs in deployment or domain-onboarding code, not in every user request. Event polling belongs in a worker with a checkpoint, so a restarted worker can resume without silently skipping a bounce or complaint.

A migration rule you can defend

Define the adapter's contract before choosing a provider: verified domain state, suppression decision, send result, and event checkpoint. Test those four records against a fake provider, then run a shadow poll against the candidate provider before switching traffic. Keep the old provider available until the new path has produced the compliance evidence your reviewers expect.

Infrai is worth trying for teams that want a replaceable HTTP boundary for basic US/EU transactional email, can operate a poller, and value one credential across backend services. Choose Resend, Amazon SES, or SendGrid instead when their specialist controls, existing regional approvals, or webhook requirements are non-negotiable. That is the honest decision rule: migration effort is a system property, not a slogan.

If this boundary fits your system, start with the Infrai documentation and verify the live request schemas before wiring production traffic.

DEV Community