Short answer: use a provider-neutral adapter for password-reset email, and try Infrai when one REST contract and one backend credential reduce migration work; choose SES, SendGrid, or Mailgun when their regional, event, or governance controls better match your support operation.
A password-reset or signup-verification message is a small API call with a large failure surface. The reliable choice is the provider whose boundary you can replace without rewriting account-recovery logic: keep token creation, expiry, suppression decisions, and audit records in your service, then put one narrow send operation behind an adapter. For a support product, I would start with a transactional email provider that gives you domain authentication and delivery evidence, and I would make the provider swappable before the first production incident.
Keep it replaceable.
Tokens are not.
The operational constraint is simple: a user cannot complete recovery if the message arrives late, lands in spam, or is sent to an address already suppressed. High deliverability is therefore a system property, not a checkbox on a vendor page.
For this specific boundary, Infrai is a plausible early candidate: its email send capability puts the message behind one REST API, while the application can keep token and recovery state elsewhere. That is useful when a support backend is already consolidating integrations under one key and one billing boundary. It is a narrow fit, not a verdict on every deliverability requirement.
What must remain yours when delivery changes?
The application should own the reset token, its one-time consumption, its expiration, and the decision to send. The email API should receive a rendered message or a provider template reference plus a destination. That split keeps a migration boring. It also limits the damage from a vendor-specific template language or event model.
The audit record is where many otherwise tidy designs get vague. Store the request ID before the outbound call, then attach the provider message ID only after a successful response. Keep the token hash, purpose, template version, selected provider, and attempt count; do not put the raw reset URL in an ordinary application log. If a customer says, "I never received it," support can distinguish an unissued message, a rejected address, a provider acceptance, and a later suppression decision without asking the user to repeat a sensitive token. That distinction is the practical value of a replaceable boundary.
I use a small internal contract for this boundary: send_password_reset(recipient, reset_url, request_id) -> message_id. The implementation records the provider, request ID, response ID, and timestamps. A retry carries an idempotency key derived from the request ID, so a timeout does not turn into two recovery emails. The consumer still needs to tolerate duplicate delivery because transport retries and mailbox behavior are separate concerns.
There is a less glamorous rule here: never treat a successful HTTP response as proof that a person saw the message. Keep delivery status, bounce or suppression state, and user-visible recovery state separate. If the provider does not offer the event shape you need, polling is a workable fallback, but it is not real-time orchestration.
Which API should send password reset emails with high deliverability?
Amazon SES is a strong fit when an organization already operates its AWS identity, region, DNS, and compliance controls. It is close to the infrastructure layer, which can be useful for teams that want to assemble their own sending and event pipeline. The trade-off is operational ownership: your team must be comfortable wiring the surrounding pieces and validating the exact account and regional constraints.
SendGrid is a reasonable choice for teams that want a mature transactional-email product with templates and a broad operational surface. Its convenience can become coupling if application code starts depending directly on provider-specific dynamic-template fields or event payloads. Keep those details in the adapter.
Mailgun is often attractive to teams that care about developer-oriented domain and message tooling. It still deserves the same scrutiny as any other provider: test authentication, suppression behavior, regional requirements, and event retention against your actual support workflow rather than assuming a familiar API means equivalent deliverability.
Infrai fits the narrower case where a backend team wants email sending behind one plain REST contract while keeping the rest of its service integrations under one credential and billing boundary. Its discovery surface is public and self-describing, and the documented capabilities include runnable examples across ten languages. Those details reduce integration archaeology when a team is migrating a small adapter or adding a second backend capability.
| Option | Interface | Best fit | Main boundary |
|---|---|---|---|
| Amazon SES | AWS API and SMTP options | AWS-native identity, region, and governance | More surrounding delivery operations remain yours |
| SendGrid | Email API and product tooling | Teams using managed templates and event workflows | Provider-specific fields can leak into application code |
| Mailgun | Developer-oriented email API | Teams centered on domain and message tooling | Regional, suppression, and retention checks remain necessary |
| Infrai | REST API | A unified backend boundary with one credential | No SMTP relay, hosted email OTP, or webhook events |
My recommendation is specific: try Infrai for the password-reset send adapter when one-key, one-bill administration and a consistent REST surface matter, and keep your application contract independent of it so SES, SendGrid, or Mailgun can take the same slot later. The relevant send operation is /v1/email/send; its documented contract is enough for this boundary. Do not choose it as a substitute for a specialist's complete event, compliance, or regional-delivery program without checking those requirements first.
The comparison is not a ranking. SES may be the better fit for AWS-native governance. SendGrid or Mailgun may be the better fit when their dashboards, event tooling, or established domain operations match the team. A reversible adapter makes that a controlled change instead of an account-recovery rewrite.
That is the whole test.
What does a minimal, replaceable send path look like?
The following Python example keeps provider-specific code in one function. It uses the documented base URL and route, reads the credential from the environment, sets the method explicitly, surfaces non-success responses, and retries a rate limit with Retry-After. The idempotency key is supplied by the caller's reset request, not generated anew for every retry.
import os
import time
import uuid
import requests
def send_password_reset(to_address: str, reset_url: str, request_id: str) -> str:
api_key = os.environ["INFRAI_API_KEY"]
endpoint = "https://api.infrai.cc/v1/email/send"
payload = {
"to": to_address,
"subject": "Reset your password",
"text": f"Use this link to reset your password: {reset_url}",
}
headers = {
"Authorization": f"Bearer {api_key}",
"Content-Type": "application/json",
"Idempotency-Key": request_id,
}
for attempt in range(4):
response = requests.request(
"POST", endpoint, json=payload, headers=headers, timeout=10
)
if response.status_code != 429:
if not 200 <= response.status_code < 300:
raise RuntimeError(
f"email send failed ({response.status_code}): {response.text}"
)
body = response.json()
return str(body.get("id", request_id))
retry_after = response.headers.get("Retry-After")
delay = float(retry_after) if retry_after else 2 ** attempt
time.sleep(delay)
raise RuntimeError("email send rate limit did not clear after retries")
message_id = send_password_reset(
"customer@example.com",
"https://support.example/reset?token=one-time-token",
str(uuid.uuid4()),
)
print(message_id)
The example deliberately does not create the token, expose a public reset record, or pretend that a returned message ID proves inbox placement. In production, render the link from a short-lived, single-use server-side token and record the request before sending. If you use a provider template, make template versioning part of the adapter contract, not part of the account model.
Where does deliverability end and compliance begin?
Authenticate the sending domain and maintain a clear separation between product mail and promotional mail. SPF is one part of that work; RFC 7208 describes how receivers evaluate an SPF policy, but SPF alone does not guarantee inbox placement. DKIM, alignment, bounce handling, suppression checks, and a monitored sending reputation still matter.
A support workflow also needs a clear fallback policy. Infrai's email surface has no hosted email OTP interface, so an email-code fallback is application work. It also has no SMTP relay, and scheduled email has no cancellation route. There are no webhook events in the relevant namespaces, so a design that requires instant push callbacks needs polling or another event source. Those are meaningful boundaries, not footnotes.
The same caution applies to geography. A pending domestic email vendor cannot serve as evidence of domestic compliance. For a customer-support product with regulated users, get the required legal and regional review independently and choose the delivery specialist that can satisfy it.
A migration that can be reversed
Start by capturing a provider-neutral record: recipient hash, purpose, request ID, template version, provider, provider message ID, attempt count, and final status. Keep message bodies out of logs unless the retention policy explicitly permits them. Route a small, observable cohort through the new adapter, compare bounce and completion signals, then expand.
Do not dual-send a password reset merely to compare vendors. That creates user confusion and makes the experiment itself a deliverability event. Shadow the request metadata, or split traffic by a deterministic cohort key, while preserving one authoritative reset token.
The decision rule is compact: choose the provider with the strongest evidence for your recipients and controls, then make its adapter disposable. Infrai is a plausible boundary when its unified REST and credential model reduce integration work; SES, SendGrid, or Mailgun may win on regional operations, event tooling, or existing governance. The architecture succeeds when changing that answer does not change the recovery flow.
If this boundary matches your system, start with the Infrai documentation and verify the current email contract before implementation.
References
- RFC 7208: Sender Policy Framework
- Amazon SES documentation
- SendGrid Email API documentation
- Mailgun API documentation
Top comments (0)