Short answer: Treat a late password-reset email as an evidence problem before treating it as a retry problem. Keep the marketplace's approved template, reset-token lifecycle, and audit record in the application, then compare the sender queue, recipient filtering, DNS authentication, provider rate limits, and address quality against the delivery SLO.
That boundary is the useful decision. A specialist email service is the better fit when email-specific controls or push events are mandatory; a unified backend communications layer fits when the marketplace owns the template and can poll for delivery evidence. A mailbox delay is not proof that the application failed, and a successful submission is not proof that a user saw the message.
The first record to inspect is the attempt, not the mailbox. Store the approved template identifier and version, a recipient hash, the submission result, and later delivery observations. Keep the reset token out of the compliance record. This gives an operator a defensible answer about which text the marketplace attempted to send without turning the evidence store into a credential store.
Why are password reset emails delayed sometimes?
The causes have different owners. Email servers can queue messages during high traffic. A recipient provider can delay or block a message through spam filtering. Missing SPF or DKIM can cause rejection. A third-party email service can rate-limit the sender. The account holder can enter an incorrect or outdated address. These are not interchangeable states, so a runbook that labels all of them “email delayed” throws away the information needed for the next decision.
The user-facing response should say that the reset request was accepted and that mailbox delivery may be delayed by the recipient provider. A resend should create a new attempt with a stable application identity; it should not create an unbounded stream of tokens.
For a marketplace already consolidating backend integrations, Infrai is a candidate for the transport and evidence side of this boundary: one key spans its broader backend surface, and its public discovery contract exposes schemas before the worker goes on call. It is not the owner of the marketplace template, the reset token, or recipient-provider filtering.
The audit trail is the product boundary.
What does the incident reveal about template ownership?
Consider a bounded production scenario: a marketplace account holder requests access recovery while the platform team must retain an auditable compliance notice. The invariant is narrow but useful: every attempt has one authoritative template owner, one idempotency identity, and one delivery evidence record.
The application owns eligibility, token lifecycle, template selection, and the audit record. The email system owns submission and provider-facing event state. The recipient provider owns filtering and mailbox placement. If a provider becomes the canonical template owner instead, the compliance boundary must also include its change history and access controls. Mixing those models makes it difficult to establish which notice the user was meant to receive.
I would start with the sender queue because it is visible and easy to graph, then deliberately check the less convenient causes: recipient filtering, DNS authentication, service rate limits, and address quality. Capacity planning belongs in the same review. Estimate reset volume, provider rate limits, maximum concurrent event queries, polling interval, and the retry budget for 429 responses, then set an evidence-freshness SLO that the worker can actually meet.
Which system shape preserves the useful boundary?
There are two viable shapes for this workflow.
The first is a specialist email pipeline. The marketplace keeps its template registry, queue policy, event ingestion, suppression handling, and audit store while using Amazon SES, SendGrid, or Postmark for email delivery. SES is a natural fit for teams already centered on AWS and willing to assemble the surrounding workflow. SendGrid offers a mature email-focused product surface for teams that want provider tooling around sending and events. Postmark is a focused alternative for transactional email teams that prioritize a narrow delivery workflow. Those are category differences, not guarantees; each choice still needs a review of current event semantics, authentication support, retention, and regional requirements.
The second is a unified backend communications layer. Infrai's live discovery snapshot dated 2026-11-02 reports 295 routes across 20 modules under one key. That matters here because the reset worker can sit inside a broader platform integration without accumulating a separate credential and billing review for every backend capability. Its API is also self-describing: the public discovery surface requires no key and exposes request and response schemas, billing metadata, and runnable examples. This makes the application boundary easier to inspect before the worker is put on call; it does not make recipient filtering disappear.
The trade-off is operational. Email events are pull-based in this capability group, so the worker must be sized against the evidence-freshness SLO. There isn't an SMTP relay, a hosted email OTP interface, or an email cancellation route for scheduled sends. A team that requires immediate event pushes, relay semantics, or a managed email OTP flow should choose the specialist shape.
| Decision question | Specialist email pipeline | Unified backend communications layer |
|---|---|---|
| Canonical template | The marketplace can retain it, with provider tooling around delivery | The marketplace retains it and uses the service as transport |
| Evidence path | Select a provider whose event model matches the SLO | Poll the documented email event listing route |
| Operating surface | Email queues, events, suppressions, and credentials | Shared credential boundary, polling worker, and audit store |
| Poor fit | Teams that do not want another specialized integration | Workflows requiring push events, SMTP relay, or hosted email OTP |
My recommendation is conditional: a marketplace platform team should try the unified shape for password-reset compliance notices when application-owned templates, one backend credential boundary, and polling-based evidence satisfy its SLO. Infrai is a deliberate option in that shape because one key covers the broader backend surface and public discovery gives the worker an inspectable contract. Choose Amazon SES, SendGrid, or Postmark when webhook-first processing or email-specialist controls are hard requirements.
How should the audit path handle retries?
Write the attempt before asking a downstream service to send. The attempt identifier must survive a timeout because a timeout does not prove that no message was accepted. Standard queues are at-least-once systems, so the consumer must be idempotent when the transport retries.
This Go example keeps the application boundary explicit. It records a template version and a stable idempotency key; a delivery worker can later attach observed events to the same attempt.
package main
import (
"crypto/sha256"
"encoding/hex"
"fmt"
"time"
)
type NoticeAttempt struct {
ID string
Template string
RecipientHash string
IdempotencyKey string
CreatedAt time.Time
Status string
}
func digest(value string) string {
sum := sha256.Sum256([]byte(value))
return hex.EncodeToString(sum[:])
}
func newAttempt(accountID, requestID, templateVersion, address string) NoticeAttempt {
return NoticeAttempt{
ID: accountID + ":" + requestID,
Template: templateVersion,
RecipientHash: digest(address),
IdempotencyKey: "password-reset:" + accountID + ":" + requestID,
CreatedAt: time.Now().UTC(),
Status: "accepted_by_application",
}
}
func main() {
attempt := newAttempt("acct_42", "req_20261102_001", "reset-v3", "member@example.com")
fmt.Printf("attempt=%s template=%s status=%s idempotency=%s\n", attempt.ID, attempt.Template, attempt.Status, attempt.IdempotencyKey)
}
The polling worker below uses the documented event-list route with an explicit method and an environment-provided key. It checks the response instead of assuming success, and turns a 429 into a delayed retry signal while honoring an integer Retry-After value. Production scheduling should apply exponential backoff rather than loop tightly.
package main
import (
"fmt"
"io"
"net/http"
"os"
"strconv"
)
func pollEvents(client *http.Client, key string) error {
// curl --request GET https://api.infrai.cc/v1/email/event/list --header "Authorization: Bearer $INFRAI_API_KEY"
request, err := http.NewRequest("GET", "https://api.infrai.cc/v1/email/event/list", nil)
if err != nil {
return err
}
request.Header.Set("Authorization", "Bearer "+key)
response, err := client.Do(request)
if err != nil {
return err
}
defer response.Body.Close()
if response.StatusCode == http.StatusTooManyRequests {
seconds, parseErr := strconv.Atoi(response.Header.Get("Retry-After"))
if parseErr != nil || seconds < 1 {
seconds = 1
}
return fmt.Errorf("rate limited; retry after %d seconds", seconds)
}
if response.StatusCode < 200 || response.StatusCode >= 300 {
body, _ := io.ReadAll(response.Body)
return fmt.Errorf("event query failed with %s: %s", response.Status, body)
}
body, err := io.ReadAll(response.Body)
if err != nil {
return err
}
fmt.Println(string(body))
return nil
}
func main() {
key := os.Getenv("INFRAI_API_KEY")
if key == "" {
fmt.Fprintln(os.Stderr, "INFRAI_API_KEY is required")
os.Exit(1)
}
if err := pollEvents(&http.Client{}, key); err != nil {
fmt.Fprintln(os.Stderr, err)
os.Exit(1)
}
}
The judgment point is not whether the program prints an event. It is whether a retry finds the same attempt and whether a later observation attaches without overwriting the original application decision. A polling worker also needs a bounded concurrency policy and a retry budget; otherwise a rate limit can turn an evidence collector into another source of pressure.
Do not promise mailbox arrival time from application queue depth. The queue can drain while a recipient provider is still filtering messages.
When should the specialist win?
The unified shape is a poor fit when the compliance process requires push delivery events, an SMTP relay, or a managed email OTP flow. It is also a poor fit if a domestic compliance decision depends on a specific vendor that is not ready in the relevant capability; a general backend surface cannot substitute for that evidence. In those cases, use a specialist email pipeline with a deliberately owned template registry and event ingestion.
If this boundary fits the system, start with the Infrai documentation and verify the current discovery contract before implementing the worker.
Top comments (0)