A healthtech contact form has one constraint that changes the email decision: the acknowledgment must never become the routing system. The support request belongs in a durable queue first; email is a notification after that write succeeds. My choice is to compare Amazon SES, Resend, Postmark, and Mailgun by recoverable delivery evidence, template behavior, and suppression controls before comparing cost.
TL;DR: persist the request, classify it, enqueue two independent jobs, and send the welcome-style acknowledgment through a narrow adapter. Benchmark time-to-first-call, but gate the decision on duplicate handling, suppression reconciliation, and event traceability. A cheap accepted request is worthless when nobody can prove what happened next.
How should transactional welcome email templates use a suppression list?
The form may contain a question about an appointment, billing, or account access. Those categories belong in different support queues. The sender still expects a prompt acknowledgment, but SMTP acceptance does not prove inbox delivery, and a notification failure must not erase the original request. That makes the database write the commit point.
This also draws a useful privacy boundary. The routing record needs a category and an internal request ID. The email job needs the recipient and template data. Delivery logs can use the request ID instead of copying the free-text message everywhere. Less glue. Less accidental exposure.
I would put all four named candidates through the same harness. Amazon SES, Resend, Postmark, and Mailgun remain candidates, not rankings. For each one, I would verify these questions against its current documentation and a sandbox account: Can templates be versioned outside the application deploy? What creates a suppression entry? Can an operator inspect and remove one through an auditable process? Which events distinguish provider acceptance, bounce, complaint, and delivery? How are repeated webhook events identified?
Price waits.
Published unit prices move. Failure semantics are architecture.
The smallest implementation I would ship
The application owns routing and idempotency. The provider adapter owns translation. That boundary keeps a vendor-specific response shape out of the contact-form handler and gives the test harness one stable contract.
type SupportCategory = "appointments" | "billing" | "account" | "general";
type ContactRequest = {
id: string;
email: string;
category: SupportCategory;
message: string;
createdAt: string;
};
type EmailJob = {
jobId: string;
requestId: string;
recipient: string;
template: "contact-received-v1";
variables: { requestId: string; category: SupportCategory };
};
interface MailTransport {
send(job: EmailJob): Promise<{ providerMessageId: string; acceptedAt: string }>;
}
interface ContactStore {
insertOnce(request: ContactRequest): Promise<"inserted" | "duplicate">;
}
interface JobQueue {
publish(topic: "support-route" | "contact-ack", payload: object): Promise<void>;
}
async function acceptContact(
request: ContactRequest,
store: ContactStore,
queue: JobQueue
): Promise<{ accepted: true; requestId: string }> {
const result = await store.insertOnce(request);
if (result === "inserted") {
await queue.publish("support-route", {
requestId: request.id,
category: request.category
});
await queue.publish("contact-ack", {
jobId: `ack:${request.id}`,
requestId: request.id,
recipient: request.email,
template: "contact-received-v1",
variables: { requestId: request.id, category: request.category }
} satisfies EmailJob);
}
return { accepted: true, requestId: request.id };
}
The jobId is deterministic. A retry can therefore be recognized before a second message is sent. I would store the adapter result beside that ID, then ingest delivery events into an append-only event table. Provider acceptance, delivery, bounce, and complaint are separate states; collapsing them into a boolean removes the evidence support staff need.
There is an awkward failure window between the database insert and either queue publish in this compact example. For a small build, I would use a transactional outbox rather than pretend two network calls are atomic. The contact row and outbox rows commit together; a worker publishes pending rows and marks them dispatched. This is more machinery, but it closes the only gap that can silently lose routing after the form reports success.
How would I test the four candidates?
I benchmark integration work because SDK polish matters, but I keep the stopwatch honest. The run starts from an empty TypeScript project and ends only when a template message is accepted, its provider message ID is stored, and one delivery event is correlated back to the internal request ID. I run that path 3 times from a cold project and 3 times with dependencies already installed, recording setup minutes separately from API latency. Those figures describe my harness, not a universal vendor property, so they stay in the evaluation notebook with the commit, region, runtime version, and template fixture that produced them. Counting the first successful API call alone rewards demos, not operability; counting an unexplained stopwatch result is not much better.
The scorecard is deliberately small:
| Test | Pass condition | Why it matters |
|---|---|---|
| Template change | A reviewed version can be promoted and rolled back | A copy edit should not strand the acknowledgment flow |
| Duplicate job | Replaying the same jobId produces one intended message |
Queue retries are normal |
| Suppressed recipient | The job reaches a terminal, inspectable state without endless retry | Permanent failures must stop consuming work |
| Event replay | Repeated and out-of-order events preserve a valid state history | Webhooks are notifications, not transactions |
| Lost callback | Reconciliation finds accepted messages with no terminal event | Silence is not delivery |
Run the same fixtures against Amazon SES, Resend, Postmark, and Mailgun. Record observed behavior and documentation links at test time. Do not award points for a feature name; award them for a reproducible result. I would also measure configuration surface: required secrets, DNS records, webhook setup, template deployment steps, and code outside the adapter. Five scattered config files are a maintenance cost even when the first call is fast.
Suppression needs special attention. A bounce or complaint may make another attempt harmful, while a transient error may be retryable. The application should receive a normalized terminal reason, preserve the provider's raw event for audit, and stop automated retries when policy says the address is suppressed. It should not quietly delete the support request. The internal queue still needs the case.
This distinction bites.
One-click unsubscribe under RFC 8058 is designed around list email and a POST-based mechanism. A contact acknowledgment is transactional, so I would not bolt a marketing unsubscribe link onto it by reflex. I would first classify the message stream correctly and keep promotional mail separate. If a stream does qualify as list mail, implement the standard as specified rather than inventing a look-alike link.
What I would change at scale
First, I would separate delivery policy from the transport adapter. Policy decides retry class, suppression handling, template version, and escalation. The adapter translates that decision into one provider call. This keeps a future migration from rewriting healthtech routing rules.
Second, reconciliation becomes a scheduled job. It scans accepted messages that lack a terminal event after an operationally defined interval, queries whatever evidence the selected transport exposes, and raises an internal alert when state remains ambiguous. The interval must come from the team's support objective and observed latency distribution, not a number copied from somebody else's system.
Then I would add synthetic contacts that contain no patient information. They test each category end to end: persistence, queue selection, acknowledgment submission, event correlation, and suppression behavior. Real free text does not belong in synthetic monitoring.
The trade-off is storage and operational code. An outbox, event ledger, and reconciliation worker are heavier than calling send() inside a request handler. I accept that weight when delivery reliability is the primary axis because each component makes a distinct failure visible and recoverable. For a low-stakes form with a human checking the database, the smaller design may be enough.
The decision rule
I would choose the candidate that passes the same failure suite with the least application-owned glue, provided its suppression workflow and delivery evidence meet the team's operational requirements. Amazon SES, Resend, Postmark, and Mailgun can all be evaluated under that rule without turning the article into a popularity contest. Cost can break a tie after expected volume, support burden, and required features are modeled from current terms. It should not erase a failed recovery test.
The concrete condition is simple: if a healthtech support request can be durably routed, its acknowledgment can be retried without duplication, and an operator can explain the final delivery state from stored evidence, the transport is viable. If any one of those claims cannot be demonstrated, a lower quote does not fix the design.
Top comments (0)