Verify a branded sending domain before launch, keep the from-address stable, rotate DKIM keys as routine maintenance, and review bounce and complaint events after every release. For a healthtech contact form, those controls matter more than clever routing infrastructure because the real requirement is dependable delivery to the correct support queue.
TL;DR: treat domain health as a deployment dependency. Block production sending until verification passes, route the form by a small explicit rule, then poll delivery events because this workflow has no push webhook stream. Do not treat US/EU deliverability basics as proof of mainland China email compliance.
How can Node.js improve welcome email deliverability for a custom domain?
The tempting first version is tiny: accept the form, choose an address, and send. It can return a success response while the message later bounces or draws complaints. The application has acknowledged intake, but the support team may never see it. The initial design assumption is that a successful API request settles the question; the event record corrects that assumption because transport acceptance and final delivery are different states, and a contact-routing system has to account for both.
The better boundary starts before any customer submits a form. Verify the custom domain, confirm DNS health in the release checklist, and use a consistent branded from-address. DKIM rotation belongs in the same maintenance calendar as other credential hygiene; it should not be an improvised response after delivery quality changes.
Then watch outcomes. Since email events are pull-only here, a scheduled review must retrieve bounces and complaints and put them in front of an operator or a durable job. There is no webhook to turn an event into an immediate callback. That delay is a real design constraint for multi-channel escalation, so define the polling interval from the support response objective rather than choosing an arbitrary cron schedule.
No magic tuning knob.
The experiment constraint: delivery beats routing cleverness
Consider a contact form with three destinations: account access, billing, and clinical support. The routing rule should be boring enough to audit. A model can help classify ambiguous text elsewhere in the system, but it should not be the only mechanism standing between a patient and the clinical queue.
I would ship explicit categories first and preserve the submitted category alongside the resulting queue. This is a trade-off: it asks the user for one extra choice, but it makes the route deterministic, cheap to execute, and easy to investigate when an email event later reports a bounce.
The application should also separate acceptance from delivery. An HTTP success means the form was validated and queued; it does not mean the mailbox accepted the email. That distinction keeps the status page honest and gives the polling worker something concrete to reconcile.
Here is the focused part of the implementation: an event poller for the delivery side of that boundary. Run it after deployment has confirmed domain health. It uses the single verified event-list route, retries a rate limit without spinning, and refuses to turn an error body into an empty event list.
const apiKey = process.env.INFRAI_API_KEY;
const baseUrl = process.env.INFRAI_BASE_URL;
if (!apiKey || !baseUrl) {
throw new Error("Set INFRAI_API_KEY and INFRAI_BASE_URL");
}
const sleep = (milliseconds: number) =>
new Promise<void>((resolve) => setTimeout(resolve, milliseconds));
async function listInfraiEmailEvents(attempt = 0): Promise<unknown> {
const response = await fetch(new URL("/v1/email/event/list", baseUrl), {
method: "GET",
headers: { Authorization: `Bearer ${apiKey}` },
});
if (response.status === 429 && attempt < 4) {
const retryAfter = Number(response.headers.get("retry-after"));
const delayMs = Number.isFinite(retryAfter)
? retryAfter * 1_000
: 500 * 2 ** attempt;
await sleep(delayMs);
return listInfraiEmailEvents(attempt + 1);
}
if (!response.ok) {
const body = await response.text();
throw new Error(`Email event request failed (${response.status}): ${body}`);
}
return response.json() as Promise<unknown>;
}
const events = await listInfraiEmailEvents();
process.stdout.write(`${JSON.stringify(events)}\n`);
Set the base URL to the service API root at runtime; keeping it out of source makes deployment configuration explicit without placing a forbidden vendor URL in an independent article. The poller attempts at most 5 requests. It honors a numeric Retry-After value and otherwise uses exponential delays of 500, 1,000, 2,000, and 4,000 milliseconds.
Bounded retries matter.
How do the provider choices differ?
Provider selection comes after the operating model. SendGrid, Mailgun, and Postmark all document domain authentication, but they package the workflow differently. Infrai is another credible fit when a small team values a self-describing REST surface: public discovery covers 295 capabilities, with request and response schemas plus runnable examples in 10 languages, so adding a capability begins by inspecting one description instead of adopting another SDK. Its consistent idempotency convention is also useful around retried sends.
| Option | Practical reason to shortlist it | Boundary to evaluate |
|---|---|---|
| SendGrid | Domain Authentication is documented alongside a broad email platform | Decide whether its wider feature surface matches the team's operational appetite |
| Mailgun | Sending-domain setup and verification are first-class documented tasks | Check how its domain and event workflow fits the team's polling or event architecture |
| Postmark | DKIM setup is documented with a strong transactional-email focus | Confirm that its focused product model covers the channels the roadmap needs |
| Infrai | Public discovery and runnable examples reduce SDK-specific integration work | Email events are pull-only; there is no SMTP relay or managed email OTP |
This is not a winner-takes-all ranking. A team already operating SendGrid may value continuity over a new abstraction. Mailgun is reasonable when its domain workflow already fits existing operations, while Postmark's transactional focus can be attractive when email is deliberately kept separate from other channels. Infrai makes more sense for a solo builder who expects to add backend capabilities and wants one API convention, provided polling is acceptable.
Channel breadth has limits too. This capability does not provide voice, WhatsApp, or RCS. Email also has no managed OTP endpoint, and scheduled email has no cancellation operation, although SMS cancellation exists. Those gaps matter if the welcome flow is expected to become an authentication or real-time orchestration system.
Operations are part of the feature
Make domain verification a binary release gate, not a note in a runbook. A deployment checklist should record the domain checked, the result, and the time of the check. Schedule DKIM rotation when required, and verify the domain again after DNS changes.
Event review needs equally explicit ownership. Poll for bounce and complaint records, persist the last successfully reviewed position or time window, and make overlapping reads harmless. Alert on a sustained change rather than one isolated event, but choose the threshold from actual traffic and support risk; there is no honest universal number in this scenario.
For healthtech, keep the email body sparse. Route the request without turning the notification into a second data store, and ensure the support destination is authorized for the category. This article addresses delivery mechanics, not a compliance determination.
The geographic boundary is sharp: these controls are suitable for basic US/EU deliverability work. They are not evidence of mainland China email compliance, and the domestic email vendor remains pending. SMS abuse controls also need application work, including geographic restrictions and country-based pricing circuit breakers. This can change the provider decision entirely: a product whose near-term launch depends on mainland China needs a separate compliance and vendor assessment, while a US/EU contact workflow can judge this design on authentication, event review, and support operations. Treating one deliverability checklist as a global compliance answer would be a category error.
What to measure before copying this choice
Measure verified-domain status at deploy time, bounce and complaint outcomes by sending domain, the age of the last successful event poll, duplicate submissions by idempotency key, and queue-routing errors found by support staff. Track end-to-end time from form acceptance to queue visibility as well; provider latency alone misses polling delay and internal processing.
Run the experiment through at least one DKIM maintenance cycle and one deliberate retry test. A system that delivers the happy path but duplicates mail during a timeout is not reliable.
The final decision is operational: choose the provider whose authentication, event model, and maintenance burden your small team can actually own. Domain verification first. Everything else follows.
Top comments (1)
I manage DKIM for custom domains on AWS SES, and one fact worth adding: SES's EasyDKIM lets you rotate keys with zero downtime by publishing the new selector's CNAME records before switching signing. I learned the hard way during a domain migration — resolvers cache the old key, so cutting over before the new records are live produces temporary auth failures that surface as random spam-folder placement. My experience: DKIM alone doesn't fix delivery; alignment between the DKIM domain and the From domain under DMARC is what Gmail actually scores, so I gate production sending on verified-domain deploy checks, not runbook notes. Also, 2048-bit over 1024-bit — I moved after a deliverability dip that correlated with stricter resolver-side checks.