Your Reset Token Expires in Ten Minutes. Your Bounce Event Might Not Arrive by Then.

A dev.to post on fintech password-reset mail states the decision rule plainly: begin with a standards-based sending setup and a local suppression gate, and adopt a polling event API only when the delay between a bounce or complaint and the next send decision fits the SLO ^[1]. It matters because the two guarantees teams routinely merge, the user-facing security guarantee and the delivery-control guarantee, are separate systems ^[2], and a short token expiry does not compensate for sending to an address that should already be suppressed ^[3].

The protection on the send path is local. Before enqueueing a reset message, the application checks the local suppression table ^[4]. The event reader is a reconciliation worker, not the only protection ^[5]: after it observes a bounce or complaint, it writes the normalized decision with the source event ID and timestamp, and that write is idempotent, because retrying a page must not create a second state transition ^[6].

The author's timing model is worth reproducing. With a five-minute poll, a reset is sent at 10:00, a complaint is recorded upstream at 10:01, and a second eligible job runs at 10:02, but the reader will not see the event until 10:05 ^[7]. The second job therefore decides three minutes before the evidence is visible ^[8]. Note what that does to the stated operational target, which is that a complaint must be represented in the local decision store within five minutes ^[9]: the observation delay here is four minutes, inside target, and the bad decision still happens ^[10]. An SLO on observation delay bounds reporting, not exposure. According to the post, the dangerous part is the ordering hidden behind healthy-looking metrics, since the send request can return success, the token can be correctly limited to ten minutes, and the event reader can show no errors at all ^[11]. Hence the logging list: the eligibility check, the local suppression-table version, the provider operation ID, and the event age when a later event changes the address state ^[12].

The rest is unglamorous and correct. SPF is documented in RFC 7208, but an SPF record is one part of sender identity and policy and not a deliverability guarantee ^[13]; DKIM, a suitable DMARC policy, DNS ownership, alignment, and a monitored sending domain belong on the launch checklist, under change control, because a DNS typo is an integration failure rather than a warmup problem ^[14]. Warmup is a traffic policy wrapped around the send-and-reconcile loop, not a switch that repairs sender reputation ^[15], and the post declines to offer a universal volume curve, since reputation depends on recipient behavior and sending history outside the API boundary ^[16]. Transactional resets stay separated from experiments and bulk mail ^[17]. The message contract is a short-lived single-use token, no sensitive account data in the body, and a neutral response so the endpoint cannot be used to enumerate accounts ^[18], with the mail worker receiving a message ID and a recipient decision rather than deriving eligibility from an old dashboard export ^[19].

For the worker itself: a cursor, a batch limit, bounded retries, and a dead-letter or review path, with the cursor committed only after the batch and its derived decisions are durable ^[20]. Honor Retry-After, and treat a 429 as a scheduling signal rather than permission to skip the suppression check ^[21]. Capacity is poll frequency times workers times pages, plus the send workload and the expected retry rate ^[22].

What to watch on your own platform review: whether vendor language like "supports warmup" has been replaced by testable targets such as a suppression decision being visible before the next reset attempt for the same address ^[9][23]. Polling every few seconds shrinks observation delay at the cost of more requests, but it does not convert pull into push ^[24]; if the remaining gap breaks the SLO, the answer is a push-capable event path or a queue owned by the application ^[25].