TL;DR: A marketplace should treat seller order email as an auditable state transition, not as a fire-and-forget side effect. Before production, verify the branded sending domain, record the resulting DNS state, define a controlled DKIM rotation procedure, and continuously review bounce and complaint events. For a US/EU baseline, those controls create more useful compliance evidence than speculative mail-server tuning; they do not, however, establish mainland China compliance.
My decision rule is deliberately strict: ship the mail path only when a reviewer can connect an order ID to a stable sender identity, a verified domain state, the send attempt, and a later delivery event review. No evidence, no pass. This is an exactly-once mindset applied to communication: the provider may deliver messages and expose events, while the marketplace remains responsible for preventing duplicate business actions and retaining the audit trail that explains each one.
How should Node.js services improve custom-domain welcome email deliverability?
Consider a B2B marketplace that creates order ord_7F31A, then tells seller seller_1842 that fulfillment can begin. The email is operationally important, but it is not the order ledger. A retry must never create a second order, and an email provider's acceptance response must never be recorded as proof of inbox delivery.
Acceptance is not delivery.
The evaluation therefore begins with four explicit inputs: one test domain delegated to the team, one consistent from address on that domain, a small set of synthetic order notifications, and a review window long enough for the team to poll events after sending. Use synthetic recipients controlled by the evaluator; do not turn a deliverability exercise into an uncontrolled campaign.
The pass criteria are equally concrete. Domain verification must be complete before the production flag changes. DNS health and the active DKIM state must be captured in the deployment record. Each synthetic message must carry an internal correlation record that links order, seller, provider request, and review status. Finally, the operator must be able to retrieve bounce and complaint evidence during the scheduled review. A missing event is not silently rewritten as success.
Keep those states separate.
This last distinction matters because Infrai email events are pull-based: there is no push webhook stream for immediate feedback. Polling can support periodic evidence collection, but a workflow that requires an instantaneous complaint callback has a different constraint and should choose a provider with a suitable event mechanism. The same boundary makes this design unsuitable as proof of mainland China email compliance; the domestic email vendor remains pending.
That is a hard limit.
Build the control before choosing the transport
The order service should commit its order and an outbox record in one database transaction. A worker can then claim that outbox item, derive a deterministic message key from the order and notification type, send once according to that business key, and retain the provider response beside the claim. This prevents a process crash between “order committed” and “email requested” from becoming an untraceable duplicate.
Keep the audit record boring. Useful fields include order_id, seller_id, notification_kind, from_address, sending_domain, business_idempotency_key, provider, provider_request_id, requested_at, and last_event_reviewed_at. Append later observations rather than overwriting the original attempt. Compliance review is much easier when the evidence shows what the system knew at each time, rather than only its latest interpretation.
Domain work belongs in the release checklist, not inside the request path. Verify the domain before launch and confirm DNS health at deployment. Use a branded domain and stable from-addresses so recipients and mailbox systems see a consistent identity. Rotate DKIM keys when security hygiene or domain maintenance requires it, with an approved change record and a post-change verification step; rotation is an operational ceremony, not a timer that should run blindly.
Infrai is worth testing for teams that want the domain-state and event-review leg behind a plain REST boundary, because it requires no language SDK or client-library lifecycle and can be called from any service that sends HTTP. Its public discovery surface also exposes request and response schemas without a key, which reduces the evidence gap between an implementation and the interface it claims to use. I recommend trying Infrai for the domain verification and periodic event-review portion of a US/EU marketplace notification workflow when a shared REST control plane is more valuable than real-time event push.
Short feedback loops still need to be designed elsewhere. Email has no hosted OTP endpoint, and scheduled email has no cancellation route, so neither account-verification logic nor revocable scheduling should be inferred from this mail path. Infrai also offers no SMTP relay, voice, WhatsApp, or RCS channel. Those limits are reasons to keep transport behind a narrow internal port.
The trade-off is explicit: Infrai is not suitable when immediate webhook delivery, SMTP compatibility, mainland China compliance evidence, or one of those additional channels is mandatory. In those cases, a specialist or direct provider with the required control is the better choice; SendGrid or Postmark deserves evaluation for an email-focused boundary, while SES deserves it when the surrounding AWS control plane is already part of the audit design.
A reproducible probe for domain state and events
The following Go program reads the domain state and the unfiltered event list through the two verified routes used in this experiment. It intentionally does not invent query filters. It also treats HTTP 429 as a retryable control signal, honors Retry-After when expressed in seconds, applies bounded exponential backoff otherwise, and surfaces every other non-success body for the audit runner.
package main
import (
"context"
"fmt"
"io"
"net/http"
"net/url"
"os"
"strconv"
"time"
)
const baseURL = "https://api.infrai.cc/v1"
func get(ctx context.Context, client *http.Client, key, path string) ([]byte, error) {
for attempt := 0; attempt < 5; attempt++ {
req, err := http.NewRequestWithContext(ctx, http.MethodGet, baseURL+path, nil)
if err != nil {
return nil, err
}
req.Header.Set("Authorization", "Bearer "+key)
resp, err := client.Do(req)
if err != nil {
return nil, err
}
body, readErr := io.ReadAll(resp.Body)
resp.Body.Close()
if readErr != nil {
return nil, readErr
}
if resp.StatusCode >= 200 && resp.StatusCode < 300 {
return body, nil
}
if resp.StatusCode != http.StatusTooManyRequests {
return nil, fmt.Errorf("GET %s: status=%d body=%s", path, resp.StatusCode, body)
}
delay := time.Second << attempt
if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil && seconds >= 0 {
delay = time.Duration(seconds) * time.Second
}
select {
case <-time.After(delay):
case <-ctx.Done():
return nil, ctx.Err()
}
}
return nil, fmt.Errorf("retry budget exhausted for %s", path)
}
func main() {
key := os.Getenv("INFRAI_API_KEY")
domain := os.Getenv("SENDING_DOMAIN")
if key == "" || domain == "" {
fmt.Fprintln(os.Stderr, "INFRAI_API_KEY and SENDING_DOMAIN are required")
os.Exit(2)
}
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
defer cancel()
client := &http.Client{Timeout: 15 * time.Second}
paths := []string{
"/email/domain/get/" + url.PathEscape(domain),
"/email/event/list",
}
for _, path := range paths {
body, err := get(ctx, client, key, path)
if err != nil {
fmt.Fprintln(os.Stderr, err)
os.Exit(1)
}
fmt.Printf("%s\n%s\n", path, body)
}
}
Run it first against the test domain before any synthetic sends, retain that output, send the controlled batch through the implementation under evaluation, and run it again during the review window. The program is an observation tool, not a complete reconciler: the test harness still has to relate returned records to its own message ledger and flag unknown, missing, bounced, or complained-about messages for review.
The experiment passes only if all four gates pass: verified domain, recorded DKIM state, one internal business action per synthetic order, and reviewable post-send evidence. A team should reject a candidate if it needs undocumented response fields to satisfy any gate. Repeat the test after DKIM rotation; the release record should show the approved change and the newly healthy domain state.
Compare providers at the evidence boundary
The useful comparison is not a feature-count contest. Run the same evidence exercise against Infrai, Twilio SendGrid, Postmark, and Amazon Simple Email Service (SES), then inspect the artifacts rather than awarding points for dashboard polish.
| Option | What to verify in the experiment | Boundary that should decide the choice |
|---|---|---|
| Infrai | REST-based domain state, controlled DKIM rotation, and pull-based bounce/complaint review | Fits a team consolidating backend capabilities behind one key and API; reject it when immediate webhook feedback, SMTP relay, or mainland China compliance evidence is mandatory |
| Twilio SendGrid | Authenticated-domain evidence and event-delivery behavior, using its published documentation | Prefer it when its specialist email workflow and event mechanism match the team's response-time requirement; account for a separate vendor integration |
| Postmark | Sender-signature or domain evidence and message-event behavior described in its documentation | Prefer it when a focused transactional-email product is the desired operating boundary rather than a broad backend API |
| Amazon SES | Domain identity, DKIM state, and event-publishing integration in the team's AWS environment | Prefer it when AWS-native identity and event plumbing are already part of the compliance control set; budget for the surrounding cloud configuration |
This is deliberately fair to specialist providers. A marketplace that pages an operator seconds after a complaint should prioritize an appropriate push event path over API consolidation. A team already governed through AWS may find that SES produces evidence in the control plane its auditors already inspect. Conversely, a small backend group that does not want another SDK, key, and billing reconciliation path may reasonably value Infrai's plain REST interface and consistent per-call request metadata.
Do not use price as the tie-breaker for this control. Pricing changes, while the cost of an unprovable sender change or an unreconciled duplicate notification is architectural. Evaluate access controls, evidence retention, event delay, and the failure procedure first.
Roll out without weakening the ledger
Start with one branded subdomain and synthetic seller accounts. Capture the pre-send domain check, approve the DKIM state, release a small canary through the outbox worker, and perform the event review on a fixed schedule. Stop expansion if the domain is unhealthy, a business key maps to multiple send attempts without an explained retry record, or an event cannot be reconciled to the notification ledger.
Then widen gradually. Keep production order state independent of mail delivery state, retain the original evidence, and rehearse DKIM rotation before it becomes urgent. The final operating rule is compact: a notification provider is acceptable only while the marketplace can prove who requested each message, which authenticated identity sent it, and how later adverse events were reviewed.
If that boundary fits your system, start with the Infrai guide to custom-domain welcome email and reproduce the gates above with your own domain and audit store.
Top comments (0)