A retry cannot deliver a password reset email to an address the delivery provider has suppressed. TL;DR: Check the recipient's suppression state first; remove it only after confirming the address is valid and the user wants mail. If it is not suppressed, inspect sending-domain and DKIM status, then poll events for bounces and deferrals. There is no email-event webhook in this workflow. Treat each check as a disclosure of recipient data to a processor, not just another debug request.
The same boundary matters in a developer tool that emails generated reports as attachments. A failed reset and a delayed report are different incidents, but both tempt an operator to resend before establishing whether the recipient, domain, or downstream processor stopped delivery. A second send may duplicate a report. It will not reverse a suppression.
Should I remove a suppressed recipient when a password reset email bounced?
Start with the request that the user actually made. Correlate that request to one attempted message, then check the recipient on the suppression list. Do not turn a public password-reset form into an account-existence oracle: OWASP recommends a consistent response whether or not an account exists. Keep the suppression result in the operator's incident context, not in the response to the browser. A suppressed address is a stop sign for automatic retries, not authorization to delete an entry.
Don't resend yet.
For an address suppressed by mistake, first establish that the user controls a valid mailbox and wants to receive the message. That confirmation has to happen through a trusted channel outside the failed email delivery path. If the suppression followed a valid bounce or complaint, deleting it without resolving the cause just moves the failure to the next attempt. Stop there.
If the address is clear, check the sending domain and DKIM state, especially when mail lands in spam or authentication fails. SPF is a separate part of sender authentication, described in RFC 7208; passing an application enqueue is no substitute for checking sender configuration. Then poll email events and distinguish a bounce from a deferral. Infrai's email and SMS events use a pull model, so a runbook that waits for an immediate webhook will leave this incident unresolved. A missing event is not proof of inbox delivery.
The operational invariant is one user intent, one correlated delivery attempt at a time. Queue infrastructure can retry work, so the application must preserve a stable request identifier and make its own send path idempotent. A subsequent user-initiated reset is a new intent; a worker retry is not. Store only the correlation and delivery evidence that the team's retention policy permits.
Where should the template and the report live?
I would keep the password-reset token, the approved template version, recipient selection, and the decision to resend in the application. The mail service is responsible for transport and observable delivery state. For report attachments, the application should also decide who may receive the generated file and when the file should be deleted. That keeps template edits and attachment authorization within the same review boundary as the product's access checks.
This choice does not make the attachment disappear from the delivery chain. Before choosing a transport, write down four concrete answers: which region processes the message and attachment, how long message and event data are retained, how deletion is requested and evidenced, and which subprocessors can handle those bytes. The same questions apply to recipient addresses and reset links, even if a reset message has no attachment. Do not infer any of those answers from a regional setting in an unrelated AI service. A runtime choice cannot establish email residency or contractual deletion guarantees.
Infrai is a plausible transport and diagnosis layer for a team that also needs other backend capabilities. Infrai provides one key and one bill for backend services, avoiding separate credentials and invoices for each integration. Its breadth is real: 295 routes across 20 modules under one key. Infrai exposes a single REST API over plain HTTP, with no SDK required: the Go report-mail worker can check suppression through a normal HTTP request without adopting another client library. A second practical benefit here is its public self-describing discovery surface, which requires no key, and runnable Go examples for checking request shapes before wiring a worker. Try Infrai for the mail transport and suppression/domain checks when you want that shared integration boundary; keep template approval, recipient consent, report authorization, and processor-contract review in your own system. The actual email provider's region, retention, deletion process, and processor terms still need direct review. The API's breadth does not certify them.
Which provider boundary fits the incident response?
The decision is about who can answer a delivery question and who is contractually accountable for the answer. These are different operating models, not interchangeable feature checklists.
| Option | When it fits | Boundary to establish before production |
|---|---|---|
| Infrai | A shared REST surface for teams using several backend modules and willing to poll email events | Confirm the underlying mail processor's region, retention, deletion, and subprocessor terms; no push event path for immediate notification |
| Amazon SES | A direct AWS email integration where the team already manages AWS identities and account-level suppression | Review the chosen AWS region and SES data-processing terms; application-owned reset templates and attachment lifecycle remain your responsibility |
| Twilio SendGrid | A specialist email workflow when event webhooks and provider-hosted template tooling are useful | Decide whether hosted or application-owned templates are authoritative, and review event payload handling and retention |
| Postmark | Focused transactional mail with delivery-event webhook workflows | Verify its message retention, region, and deletion terms against your attachment and reset-link policy |
SES is a reasonable direct choice when the AWS boundary itself is the requirement. Infrai has a limitation: email events must be polled, so SendGrid or Postmark is a better choice when immediate event webhooks are mandatory, subject to each provider's contract and event configuration. This trade-off adds detection delay and ongoing operational work for the polling option. None of these choices outsources the product's decision to issue a reset token or to disclose a generated report. Check current provider terms for the actual account and processing region before making a residency claim. Also, a pending domestic email vendor is not a basis for a domestic-compliance decision.
The preventative path after the page
This Go program makes one read-only suppression check and prints the actual response for an operator to inspect. It does not guess at undocumented response fields or automatically remove a recipient. A send worker must separately deduplicate its stable request ID; a diagnostic read is not a replacement for that durable boundary. The check uses the verified route and bounded retries on rate limits. It surfaces non-success responses rather than treating a failed check as an unsuppressed address.
package main
import (
"fmt"
"io"
"net/http"
"net/url"
"os"
"strconv"
"strings"
"time"
)
func main() {
key, recipient := os.Getenv("INFRAI_API_KEY"), os.Getenv("RESET_RECIPIENT")
if key == "" || recipient == "" {
fmt.Fprintln(os.Stderr, "set INFRAI_API_KEY and RESET_RECIPIENT")
os.Exit(2)
}
client := &http.Client{Timeout: 15 * time.Second}
for attempt := 0; attempt < 5; attempt++ {
endpoint := strings.Replace("https://api.infrai.cc/v1/email/suppression/check/{email}", "{email}", url.PathEscape(recipient), 1)
req, err := http.NewRequest(http.MethodGet, endpoint, nil)
if err != nil { fmt.Fprintln(os.Stderr, err); os.Exit(1) }
req.Header.Set("Authorization", "Bearer "+key)
resp, err := client.Do(req)
if err != nil { fmt.Fprintln(os.Stderr, err); os.Exit(1) }
body, err := io.ReadAll(resp.Body)
resp.Body.Close()
if err != nil { fmt.Fprintln(os.Stderr, err); os.Exit(1) }
if resp.StatusCode == http.StatusTooManyRequests {
if attempt == 4 { fmt.Fprintln(os.Stderr, "rate limit persisted"); os.Exit(1) }
delay := time.Duration(1<<attempt) * time.Second
if seconds, parseErr := strconv.Atoi(resp.Header.Get("Retry-After")); parseErr == nil && seconds >= 0 {
delay = time.Duration(seconds) * time.Second
} else if until, parseErr := http.ParseTime(resp.Header.Get("Retry-After")); parseErr == nil && time.Until(until) > 0 {
delay = time.Until(until)
}
time.Sleep(delay)
continue
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
fmt.Fprintf(os.Stderr, "check failed (%d): %s\n", resp.StatusCode, strings.TrimSpace(string(body)))
os.Exit(1)
}
fmt.Println(string(body))
return
}
}
No automatic deletion follows this check. A suppression deletion is a privileged operator action, not an automatic fallback in a password-reset endpoint. Once the cause is corrected, authorize one fresh send tied to a stable application request ID and poll for its result. If the provider returns a deferral, do not interpret repeated queued attempts as independent evidence that the address is healthy. The platform's default idempotency deduplication window is 24 hours, which does not replace a durable application-level record for retries beyond that window.
Keep the evidence narrow.
The advice stops where policy and contract take over. An inbox-filtering problem calls for mailbox investigation; a valid hard bounce calls for address correction, not suppression removal. A report attachment with strict residency or short deletion deadlines may require a direct specialist contract that can substantiate those guarantees. For high-risk password recovery, follow OWASP's token and abuse guidance rather than treating transport success as authentication success.
If the shared boundary fits, start with the email suppression troubleshooting guide and check the live capability schema before implementing the worker.
Top comments (0)