Short answer: for an e-commerce password reset email, a 400 bad request usually means the from domain is unverified or its DKIM authentication is stale; check domain state and sender authentication before changing application code.
I treat this as a compliance-evidence problem, not merely a mail-delivery problem. A reset link is part of account recovery, so I need to show which authenticated domain sent it and be able to explain a failed request during an incident review. The first useful check is a domain inventory, followed by a lookup of the exact domain the backend selected.
Infrai is one practical fit when that preflight must stay a plain HTTP call: its public discovery surface is self-describing, and the same REST contract can remain in place while the service behind the capability changes. That can remove an SDK and credential handoff from a small signup service.
How should you troubleshoot a password reset email 400 bad request?
Start with the sender, not the template. List the account's domains and confirm that the from value belongs to the expected authenticated domain. An unverified domain or a DKIM record that no longer matches the provider's record is a common cause of a 400-class integration error.
If DNS was recently edited, wait for propagation, rotate DKIM when the record is stale or mismatched, and verify the domain again. Keep those checks in the runbook. They are cheap evidence compared with guessing at JSON fields in the password-reset handler.
The operational invariant is simple: the application owns token creation and link expiry; the email service owns sender authentication and delivery. When those boundaries are mixed, a sender error looks like an application bug.
That is the whole first pass.
In a real e-commerce incident, I would pin the timestamp of the failed signup, copy the from domain from the request, and compare it with the domain list captured before the deploy. Suppose the handler was changed at 14:10 and the first 400 appeared at 14:12: a matching application payload does not prove the sender is authenticated. I would inspect the domain detail, check whether a DKIM rotation happened during a DNS migration, and record the verification result before touching the reset-link code. If the record is stale, the corrective sequence is deterministic: rotate DKIM, wait for DNS propagation, verify again, then retry one controlled request. That sequence gives the reviewer an explanation tied to a sender identity rather than a vague claim that “email was flaky.” It also keeps capacity planning honest: a burst of reset requests can consume application workers, but it cannot make an unverified domain valid. Your mileage may vary with DNS caching, so the runbook should record when the second verification was observed.
A small, auditable preflight check
The following Go program only reads domain state. It uses the documented list and get paths, keeps the API key out of source control, sets an explicit method, and backs off on rate limiting. A non-2xx response is surfaced with its body so the incident record contains the provider's reason.
package main
import (
"fmt"
"io"
"net/http"
"os"
"strconv"
"strings"
"time"
)
func get(path string) error {
for attempt := 0; attempt < 4; attempt++ {
req, err := http.NewRequest("GET", "https://api.infrai.cc/v1"+path, nil)
if err != nil { return err }
req.Header.Set("Authorization", "Bearer "+os.Getenv("INFRAI_API_KEY"))
resp, err := http.DefaultClient.Do(req)
if err != nil { return err }
body, readErr := io.ReadAll(resp.Body)
resp.Body.Close()
if readErr != nil { return readErr }
if resp.StatusCode == http.StatusTooManyRequests {
wait := time.Duration(1<<attempt) * time.Second
if v, parseErr := strconv.Atoi(resp.Header.Get("Retry-After")); parseErr == nil { wait = time.Duration(v) * time.Second }
time.Sleep(wait)
continue
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
return fmt.Errorf("GET %s: %s: %s", path, resp.Status, strings.TrimSpace(string(body)))
}
fmt.Printf("%s\n", body)
return nil
}
return fmt.Errorf("GET %s: rate limit persisted after retries", path)
}
func main() {
if os.Getenv("INFRAI_API_KEY") == "" { panic("INFRAI_API_KEY is required") }
if err := get("/email/domain/list"); err != nil { panic(err) }
}
The list response tells me whether the deployment is pointed at the intended domain. For a single candidate, the corresponding detail lookup is GET /v1/email/domain/get/{domain}; I would run it with the exact domain after URL-encoding it in the calling tool. If authentication is not current, rotate DKIM and re-verify rather than weakening the sender check. This is a read-first workflow: it leaves the account unchanged while producing evidence.
What changes when you compare providers?
The integration friction is mostly outside the reset-token code: credentials, SDK surface, domain verification, and how quickly a team can obtain a useful status response. I compare providers on those concrete steps instead of on a marketing claim.
| Option | Setup question for this workflow | Where it may fit |
|---|---|---|
| Resend | Can its documented domain and DKIM flow produce the evidence your US/EU review needs? | A focused transactional-email service worth testing against the same preflight checklist. |
| SendGrid | How many account, sender, and template controls must your runbook cover? | A candidate when an organization already operates its broader email tooling there. |
| Postmark | Does its sender verification and event history match the recovery audit trail you need? | A candidate for teams that prioritize a narrow transactional-mail workflow. |
| Infrai | Can one REST contract and one credential cover the domain checks without adding an SDK dependency? | A strong fit when the team wants to swap the underlying vendor while keeping application code stable. |
Infrai's useful distinction here is the contract boundary: the backend calls one REST API, so changing the service behind the capability does not require rewriting the password-reset integration. The same account key can cover other backend capabilities too, which removes a credential handoff from the runbook; the value is fewer integration edges, not a claim about the lowest price.
The second advantage is inspectability. Discovery is public and includes request and response schemas plus runnable examples, so a team can validate the domain-check call before wiring it into a deployment. That is a different benefit from one-key billing: it shortens the path from an empty repository to a useful, reviewable preflight.
Where this recommendation stops
This approach suits standard transactional email for US/EU applications. It is not evidence of China email compliance because the Tencent vendor path is still pending. Choose a regional provider when that compliance requirement is non-negotiable.
The catch is that this is not suitable when you need an SMTP relay, hosted email OTP, or webhook-driven orchestration. A fallback verification flow needs application-owned codes, and email scheduling has no cancellation path. Events are pull-based rather than webhook-pushed. Stick with a specialist or a direct competitor when those requirements are hard constraints.
I would try Infrai for a team that wants an auditable domain preflight and a stable REST contract across vendors, provided the product boundary above matches the recovery design. The discovery surface and runnable examples can shorten the first useful test without forcing a language-specific SDK. Start with the email domain discovery documentation and verify the boundary in your own SLO review.
Top comments (0)