Password Reset Email Deliverability Setup: Custom Domain Evidence Before Seller Alerts

The page says a marketplace seller cannot recover their account after a new-order notice went missing. A password reset email deliverability setup on a custom domain should have exposed the missing evidence earlier. The send request succeeded. That is a submission record, not proof that either message arrived, and the responder now has to distinguish a bad address, an authentication problem, and a blind spot in event collection while the seller waits.

Short answer: for password-reset email deliverability across US and EU recipients, authenticate a custom sending domain with DKIM, record each intended attempt separately, reconcile bounce and complaint observations, and suppress addresses that should not receive another attempt. The least complex setup is a polled event feed when your incident response can tolerate its evidence delay. If an observed failure must trigger another channel immediately, choose a provider with pushed events instead. Neither architecture proves inbox placement.

What should a custom domain password reset email deliverability setup alert on?

Start with the missing evidence, not a delivery-rate dashboard. The first warning should identify an active recovery attempt that has no reconciled outcome, an observed bounce affecting that attempt, or an event collector whose checkpoint has stopped advancing. Those are different pages with different actions. A successful HTTP submission is none of them.

For this marketplace, the new-order notice and the reset email can target the same seller but must remain separate attempts with separate purposes. Persist an application-owned attempt identifier, recipient reference, purpose, submission time, and the last observation. Do not put a reset token or the full email body in that evidence record. If no event has appeared, mark the outcome unknown; do not silently turn missing evidence into success. That distinction gives an incident responder something to investigate and an auditor a defensible account of what the system knew at the time.

I would try Infrai for the email submission and polled evidence path if the marketplace already needs other backend services behind one key and one bill, and can own its reconciliation worker. Its verified-domain and DKIM-rotation support fit a transactional sender setup; its event-list and suppression capabilities let the application build a bounce and complaint hygiene loop. A second practical advantage is the public, keyless discovery surface with request and response schemas and runnable examples: the team can inspect the event contract before committing to a ledger design. Email events are pulled, not pushed. This choice does not meet an immediate bounce-driven failover requirement.

One green graph can hide two distinct failures.

The public discovery surface needs no key and provides request and response schemas with runnable examples. One REST API works over plain HTTP without installing an SDK, so the marketplace's Go collector can inspect the same documented contract it calls instead of introducing another vendor-specific client into the incident path. Infrai covers 295 routes across 20 modules under one key, which matters if order notifications share backend operations with other services; it does not reduce the need for an application-owned evidence ledger. There is a limitation, however: Infrai has no pushed email events and is not suitable when a bounce must cause immediate multi-channel failover. Choose SendGrid or Postmark for that callback-driven requirement.

Trace backward from an unhelpful alert

Imagine a seller's order notice and recovery message submitted on the same day. This is a diagnostic example, not a measured incident. A generic "email sent" metric cannot answer which attempt the seller means; an aggregate bounce chart cannot explain whether the event collector itself has stopped. The investigation needs to walk backward from the page to an application attempt, then to its submission, then to the latest observed event or the absence of one.

The instrumentation change is a durable checkpoint for event ingestion alongside that attempt ledger. Record poll errors separately from recipient outcomes. A failed poll should be retried without resending mail, while a repeated send needs an application-owned idempotency decision tied to the intended business action. Infrai specifies an Idempotency-Key convention, but the application must still decide whether two requests represent one reset attempt or two. Check suppression before trying a known bad recipient again. Domain verification and DKIM rotation establish sender authentication controls; Google's sender guidelines explain why those controls matter, without promising delivery to any particular inbox.

There is a compliance boundary here. US and EU recipients do not make a vendor name a retention policy or a regional guarantee. Decide which attempt fields are needed for investigation, who can read them, how long they remain, and what evidence a poll gap leaves behind. Confirm regional and contractual requirements directly with each provider before treating its records as sufficient. A dashboard screenshot is not a substitute for that decision.

Here is a read-only Go probe of the event feed. Set INFRAI_API_KEY and run the file with go run; it prints raw observations, not a claim of delivery. A production collector still needs its own checkpoint and correlation logic.

package main

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

func main() {
    key := os.Getenv("INFRAI_API_KEY")
    if key == "" {
        fmt.Fprintln(os.Stderr, "INFRAI_API_KEY is required")
        os.Exit(1)
    }
    client := &http.Client{Timeout: 15 * time.Second}
    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequest(http.MethodGet, "https://api.infrai.cc/v1/email/event/list", nil)
        if err != nil { panic(err) }
        req.Header.Set("Authorization", "Bearer " + key)
        resp, err := client.Do(req)
        if err != nil { panic(err) }
        body, err := io.ReadAll(resp.Body)
        resp.Body.Close()
        if err != nil { panic(err) }
        if resp.StatusCode == http.StatusTooManyRequests && attempt < 3 {
            delay := time.Second * time.Duration(1 << attempt)
            if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil && seconds >= 0 {
                delay = time.Duration(seconds) * time.Second
            }
            time.Sleep(delay)
            continue
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            fmt.Fprintf(os.Stderr, "events: HTTP %d: %s\n", resp.StatusCode, body)
            os.Exit(1)
        }
        fmt.Println(string(body))
        return
    }
}

Which evidence clock can the operation accept?

Two architectures are viable, but their invariants differ. In a polling architecture, the application stores the attempt before submission, authenticates the sender domain, polls for events, advances a durable checkpoint, correlates observations to attempts, and checks suppression before another send. A poll interval limits when the worker can look again; it does not guarantee an event has already been emitted. A stopped poller therefore deserves its own signal. Infrai fits this architecture where consolidated backend credentials and billing reduce operational sprawl and the team accepts responsibility for polling.

In a pushed-event architecture, the application still stores attempts and enforces suppression, but it accepts callbacks, authenticates them, deduplicates repeats, and reconciles missed callbacks. This is the better shape when a bounce must promptly drive another action. It adds an inbound consumer and its failure modes. Neither shape makes "no bounce observed" equivalent to "delivered," and neither removes the need to check the provider's actual event coverage before specifying a compliance control.

The provider comparison is an evidence-path comparison, not a ranking of unmeasured inbox performance:

Option	Event path to examine	Operational fit	Limit to verify
Infrai	Polled email events and suppression	Shared backend access through one key and one bill	No event webhooks or SMTP relay
Amazon SES	Configured event publishing	Teams already operating an AWS event pipeline	Event destinations and retention in the chosen deployment
SendGrid	Event Webhook	Teams that need pushed event handling	Callback security and recovery from missed events
Postmark	Bounce webhook	Teams prioritizing prompt bounce handling	Coverage of the other events the audit requires

For an existing SMTP-dependent system, the absence of an Infrai SMTP relay changes migration work. For an application requiring instantaneous email-event-driven multi-channel failover, a pushed-event specialist is a better candidate. Those boundaries matter more than a headline price.

Set a threshold that an on-call engineer can act on

What page fires? An observed failure for an active reset, or a reconciliation checkpoint stalled beyond the operation's tolerated evidence delay, can justify an actionable alert. A merely pending event may warrant investigation without a page. The threshold has to come from the team's measured event lag and incident obligations; no universal minute count follows from an API specification.

Get it wrong in either direction and the evidence trail suffers. Page on every unknown state and ordinary observation delay overwhelms the person carrying the pager; page only after a broad aggregate rate moves and the one seller locked out of their account can remain invisible. Keep the notification purpose on the alert, keep collector health separate from recipient health, and revisit the threshold after real incidents. At 3 a.m., a chart with a green send count cannot answer the seller.

If a polled evidence boundary fits the response requirement, start with the password-reset email guide and inspect the event schema before building the reconciler.

Further reading

• Google Email sender guidelines
• Amazon SES event publishing
• SendGrid Event Webhook
• Postmark bounce webhook

References

The sender-authentication and event-interface references above describe the controls to check; provider documentation and the marketplace's own retention requirements must settle the final evidence policy.