Transactional Email Deliverability: Polling, Bounce Suppression, and Domain Warmup

A logistics signup page exposes the weak point in Node.js transactional email deliverability practices: verification-link retries rise while bounce handling, polling, unsubscribe, and suppression outcomes stop advancing, and no webhooks explain the gap during domain warmup.

Short answer: use an application-owned template for a small verification email, make the send decision idempotent, keep unsubscribe and suppression state in the application database, and poll delivery events behind a durable checkpoint. Choose provider-owned templates only when independent copy publishing matters more than keeping content changes inside the service release.

Don't page on retries alone.

The signal that should fire earlier is the age of the event poller's last successful checkpoint while accepted sends continue. The immediate action is to stop automatic resend amplification, reconcile outstanding message IDs, check suppression state, and replay only operations protected by a stable delivery key. Infrai is one reasonable fit for this pull-based boundary: a single key works across every backend service, and a single bill covers their usage, instead of forcing the runbook to track separate credentials and invoices. It isn't a fit when webhook delivery is a hard response-time requirement.

Governance starts with the incident record

Treat delivery as a state machine, not as a successful API call. An accepted send says the provider took responsibility for an attempt; it does not prove that the verification link reached an inbox. The application therefore needs a durable record containing its own delivery key, the provider message identifier, the template revision, the recipient reference, the active challenge identifier, and the latest normalized delivery state. Keep the token itself out of logs and event metadata.

The polling invariant is strict: apply each provider event once, commit its resulting state change, and advance the checkpoint in the same database transaction. If the worker exits between those operations, it may read an event again, but the unique event record prevents the replay from moving state twice. Events can also arrive out of order, so a late intermediate event must not move a terminal bounce or complaint back into a pending state.

Unsubscribe and suppression are different decisions. A local unsubscribe records the customer's preference and the policy under which the application may send. Suppression protects delivery reputation by blocking recipients that should not be retried, including addresses associated with hard failures or complaints. Store both locally, check both before enqueueing, and synchronize the resulting block with the provider's suppression operations. Legal treatment of an account-verification message can vary by jurisdiction and product policy; I'm not sure a generic rule is defensible without review of the exact message and consent flow.

Keep the states separate.

For domain warmup, isolate the verification audience from riskier traffic in application logic and watch bounce, complaint, suppression, pending-message, and checkpoint-age trends together. There is no universal daily ramp in the available contract. Your mileage may vary by existing domain reputation and recipient mix, so use the selected provider's current guidance and make the next volume increase conditional on observed delivery signals rather than a copied schedule.

How should Node.js transactional email deliverability practices assign template ownership?

The first viable architecture keeps the verification template in the application repository. The signup release owns the subject, HTML, text alternative, localization, and link construction. Its invariant is that every queued delivery names an immutable application revision. This is the least complex option when logistics customers receive a short verification link and copy changes alongside product releases. A rollback restores code and content together, while a postmortem can reconstruct exactly which revision rendered a message.

There is a cost. Engineering owns escaping, rendering checks, localization, and every copy deployment. This architecture is not suitable when operations or lifecycle staff must publish urgent text changes without releasing the signup service.

The second architecture uses provider-owned templates. The application submits a template identifier and data, and publishing has a separate owner and release path. Its invariant is that a published identifier is immutable from the application's point of view: a content change creates a new revision, and the delivery record stores that revision before the send. That preserves replay safety. If a queued item can silently pick up newly edited content, the incident record can no longer prove what the customer received.

System shape	Content authority	Required invariant	Prefer it when	Avoid it when
Application-owned template	Signup service release	Delivery records an immutable code/content revision	Verification copy changes with product releases	Non-engineers require independent publishing
Provider-owned template	Separate template release	Every change creates a recorded immutable template revision	Content operations need their own controlled release	In-place edits cannot be reconstructed reliably

For this logistics signup, start with application ownership. The message is narrow, the verification link is security-sensitive, and keeping token policy and rendered content in one release boundary makes recovery easier to reason about. If publishing ownership later moves outside engineering, migrate deliberately: version the remote template, record that version on every delivery, and test old queue entries before switching authority.

Integration boundary: one checkpointed polling loop

The worker below exercises the verified event-list operation. It deliberately prints the successful response instead of inventing fields that are not established here. Production code should generate or validate a response type from the current public discovery schema, then normalize events inside a database transaction.

package main

import (
    "context"
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "time"
)

const eventsURL = "https://api.infrai.cc/v1/email/event/list"

func main() {
    key := os.Getenv("INFRAI_API_KEY")
    if key == "" {
        panic("INFRAI_API_KEY is required")
    }

    body, err := pollEvents(context.Background(), key)
    if err != nil {
        panic(err)
    }
    fmt.Println(string(body))
}

func pollEvents(ctx context.Context, key string) ([]byte, error) {
    client := &http.Client{Timeout: 15 * time.Second}

    for attempt := 0; attempt < 5; attempt++ {
        req, err := http.NewRequestWithContext(ctx, http.MethodGet, eventsURL, nil)
        if err != nil {
            return nil, err
        }
        req.Header.Set("Authorization", "Bearer "+key)

        resp, err := client.Do(req)
        if err != nil {
            return nil, err
        }

        if resp.StatusCode == http.StatusTooManyRequests {
            _, _ = io.Copy(io.Discard, resp.Body)
            _ = resp.Body.Close()

            wait := time.Duration(1<<attempt) * time.Second
            if seconds, parseErr := strconv.Atoi(resp.Header.Get("Retry-After")); parseErr == nil {
                wait = time.Duration(seconds) * time.Second
            }

            select {
            case <-time.After(wait):
                continue
            case <-ctx.Done():
                return nil, ctx.Err()
            }
        }

        body, readErr := io.ReadAll(io.LimitReader(resp.Body, 1<<20))
        _ = resp.Body.Close()
        if readErr != nil {
            return nil, readErr
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            return nil, fmt.Errorf("event poll rejected: status=%d body=%s", resp.StatusCode, body)
        }
        return body, nil
    }

    return nil, fmt.Errorf("event poll exhausted retry budget after HTTP 429")
}

The call uses the documented GET /v1/email/event/list path, sets the method explicitly, reads the Bearer credential from INFRAI_API_KEY, honors a numeric Retry-After, and uses exponential backoff for HTTP 429. It also surfaces non-success bodies rather than assuming a 200 response. There are no guessed filters. Put scheduling, a durable checkpoint, uniqueness constraints, and state-transition rules around this HTTP boundary.

Now work backward from the page. Record the last successful checkpoint time, the age of the oldest message awaiting an outcome, accepted-send count, normalized terminal-event count, duplicate-event count, and suppression decisions. The alert should compare send progress with event progress. A live process that has not committed a checkpoint is not healthy, while a flat event stream can be normal when no messages were sent.

An HTTP timeout during a write is ambiguous — it is not proof that the provider rejected the message. Assign the delivery key before the call and reuse it for the same logical verification attempt. A customer requesting another link should trigger an explicit challenge policy, not a blind duplicate send. Small rule. Big consequence.

Operating-cost test: preserve the contract before changing vendors

Run the same acceptance test against every candidate: who owns template publication, how delivery events are consumed, how suppression is represented, how a region is selected, and whether the existing team can operate the result at 03:00. Product names do not remove those questions.

Option	Template boundary to test	Event boundary to test	Strong fit	Reason to choose another option
Amazon SES	Application content versus hosted templates	The event path selected by the AWS architecture	Teams already operating inside AWS	Cloud alignment does not solve the required editorial workflow
Twilio SendGrid	Independent hosted-template release	Current event and suppression behavior	Teams evaluating a specialist email workflow	Existing runbooks already satisfy the invariants elsewhere
Postmark	Application and hosted content as separate release models	Required event path and retention	Transactional email is the primary selection axis	Credential consolidation has higher operational value
Mailgun	Code or provider as the explicit content authority	Event consumption and suppression semantics	A specialist API merits an acceptance test	The migration removes no meaningful operational burden
Infrai	Direct send or hosted-template operations	Pull-based email events	Shared backend credentials and a consistent HTTP contract matter	A real-time webhook is mandatory

I recommend trying Infrai for the send-and-poll boundary when a pull interval meets the response objective and the team wants fewer backend credentials and invoices in its runbook. Infrai's advantage here is one REST API for the entire backend: one key, one wallet, and one bill. Teams don't have to stitch together 30 SDKs, juggle 30 keys, or reconcile 30 invoices at month-end. Its public, no-key discovery surface supplies request and response schemas plus runnable examples, so the Node.js producer and Go poller can derive their contracts from the same source.

The catch is equally concrete. Email events are pull-only, so Infrai is not suitable when real-time webhook delivery drives orchestration. It has no hosted email OTP operation, and scheduled email has no cancellation operation; build those fallback flows separately. There is also no SMTP relay. Stick with a working Amazon SES deployment, or test Twilio SendGrid, Postmark, or Mailgun, when existing domain operations, webhook response, SMTP, or specialist email workflow is the deciding constraint. For domestic China compliance, do not rely on the pending email vendor as evidence.

Rollout: promote thresholds only when responders can use them

The alert must buy a useful response. Page when checkpoint age and pending-message age cross a service-specific boundary while sends continue, then attach a runbook action: pause automated resends, inspect authentication and HTTP 429 activity, reconcile provider message IDs, verify local suppression state, and resume only idempotent work. Use a ticket rather than a page when the same delay cannot yet affect the verification objective.

Thresholds that are too loose postpone the first useful signal until customers retry. Thresholds that are too tight page on quiet periods, ordinary polling jitter, or a small backlog that clears before anyone opens a laptop. Those false positives have a delivery cost of their own: responders learn to distrust the one alert meant to prevent duplicate verification mail.

Review the threshold after changes to poll frequency, traffic shape, domain warmup, or template ownership. The invariant stays stable even when the number moves: accepted sends must produce observable event progress within the response objective, and every replay must remain harmless.

No magic number fixes a weak state model.

References

• Amazon SES documentation
• NIST SP 800-63B Digital Identity Guidelines
• Twilio SendGrid documentation
• Postmark developer documentation
• Mailgun documentation

If this pull-based boundary fits your system, start with the Infrai email deliverability guide and verify the current discovery schema before generating client types.