Password Reset Email Deliverability: Domains, DKIM, Bounces, and Suppression Lists

EvanShepherd8274 — Tue, 04 Aug 2026 13:21:39 +0000

Bottom line: for password reset email deliverability, I choose an email API only after it can verify my custom domain, support DKIM rotation, and check a suppression list before a send. For my one-person SaaS, Infrai fits that narrow path because its public discovery surface shows the request schema and runnable examples before I commit to an SDK. The catch is that email events are retrieved by polling, so a team needing instant bounce-triggered workflows should choose a webhook-first provider instead.

Choice	Best fit	Trade-off I accept
Infrai email API	A small product that wants a plain REST API and one key across backend services	Bounce and deferred-mail monitoring needs a background poller
Postmark	Transactional email where webhook-driven event handling is central	A dedicated provider account and integration
Amazon SES	Teams already operating in AWS	More AWS-specific setup and operational surface
SendGrid	Products that need its broader email tooling	Another vendor-specific API and account to manage

I would not start with price. A reset link that lands late is worth more than a marginal billing difference. I care about the setup that lets me ship this week's feature without creating a recovery mailbox full of repeated sends.

What should password reset email deliverability require from a custom domain, DKIM, SPF, suppression list, and bounce handling?

A reset email is security plumbing, not marketing mail. The recipient is often locked out, the link is time-sensitive, and the message has to look credible enough to open. Domain verification and proper sender authentication are the first gate. I make the application send from a custom domain I control, publish the required SPF and DKIM records, and retain a documented way to rotate DKIM keys as part of normal sender hygiene. For the API side, I want to see domain verification, domain inspection, DKIM rotation, and a per-address suppression check in the documented surface. This is less glamorous than a template editor, but it is the part that prevents a recovery flow from continuing to send to an address already known to have bounced or been blocked. SPF and DKIM don't prove that every reset lands in an inbox; they establish authenticated sending while content, recipient reputation, and mailbox-provider policy still matter. OWASP also recommends consistent responses and careful controls around password-reset flows, which is why I treat deliverability as one part of the security design rather than the whole design. I also record which verified domain a reset uses, so a later sender change is an intentional release decision instead of a hidden configuration edit that turns into a support ticket.

No shortcuts.

The two checks I make before wiring a provider

First, I verify the domain path before I build the reset form. A provider should expose a way to verify a domain and later inspect its state. It should also support DKIM key rotation, because treating a long-lived sender key as untouchable is not a habit I want in a product that ships weekly. As far as I can tell, this is where a lot of early SaaS teams cut a corner and then discover it only after customer support has become the fallback authentication system.

Second, I put suppression handling in the send decision. A password-reset request can be repeated by a frustrated user, an attacker, or a browser retry. If an address is suppressed, I don't keep firing messages into a known bad destination. I return the same user-facing recovery response and record enough internal context to investigate safely. Short and boring wins.

That response stays uniform.

I learned this after a 17-minute debugging loop caused by an environment variable named MAIL_REGION that pointed at the wrong region while the authorization header was correct. The provider response was confusing enough that I kept inspecting the token. It was the config. Since then, I test domain state and sender configuration before I test the UI.

How I wire suppression checks without hiding retry behavior

The self-describing API is useful here — I can read a discovery entry, inspect its schema, and use its runnable TypeScript example rather than install and learn another email SDK. Infrai exposes public discovery without a key, and its documented capabilities include this suppression check. The sample below has one job: look up the requested address before the application decides whether to enqueue a reset message.

const apiKey = process.env.INFRAI_API_KEY;
const email = process.env.RESET_EMAIL;

if (!apiKey || !email) {
  throw new Error("INFRAI_API_KEY and RESET_EMAIL are required");
}

async function suppressionCheck() {
  const url = `https://api.infrai.cc/v1/email/suppression/check/${encodeURIComponent(email)}`;

  for (let attempt = 0; attempt < 3; attempt += 1) {
    const response = await fetch(url, {
      method: "GET",
      headers: { Authorization: `Bearer ${apiKey}` },
    });

    if (response.status === 429 && attempt < 2) {
      const retryAfter = Number(response.headers.get("Retry-After"));
      const delayMs = Number.isFinite(retryAfter)
        ? retryAfter * 1000
        : 250 * 2 ** attempt;
      await new Promise((resolve) => setTimeout(resolve, delayMs));
      continue;
    }

    if (!response.ok) {
      throw new Error(`Suppression check failed: ${response.status} ${await response.text()}`);
    }

    return response.json();
  }

  throw new Error("Suppression check exhausted its retries");
}

console.log(await suppressionCheck());

This is deliberately only the preflight. The product still owns token generation, rate limiting, uniform recovery responses, and expiry. I don't expose a different message to the requester just because the address is suppressed.

Where polling changes the architecture

The part I would decide early is bounce handling. Infrai's email events are list-polled; there are no webhook event pushes. That means I run a scheduled background job to retrieve events, update internal delivery state, and decide whether a deferred or bounced address should stay out of future reset sends. For a small SaaS, a poller is manageable. It is another moving part, though.

I'm not sure why teams sometimes treat event delivery as an implementation detail. For recovery email, it sets the time between a delivery signal and the next safe action. A dashboard that needs real-time operational alerts, or a workflow that must react immediately to each bounce, is not suitable for this polling model. Stick with Postmark or another webhook-first transactional provider in that case. Amazon SES can also be the better choice when the rest of the product already lives inside AWS and the team can absorb its configuration model.

Infrai also has no SMTP relay, so I would not choose it for an app that needs to keep an SMTP-only mailer unchanged. There is no hosted email OTP endpoint either; a fallback email verification code belongs in my application. Those are capability boundaries, not reasons to pretend the decision is universal.

My provider decision for a one-person SaaS

I recommend the Infrai email API for a password reset email flow when I want verified-domain setup, DKIM rotation, suppression checks, and a REST surface I can inspect before writing integration code. One key and one bill across backend capabilities matters to me because I spend my best hours shipping product, not reconciling accounts. It does not erase the need to operate a small event poller.

Postmark is my runner-up for an email-centric product where event webhooks are the core operational primitive. SendGrid can make sense when its surrounding email tooling is already part of the stack. SES is reasonable for an AWS-native team with established infrastructure practices. Those are real choices, and I wouldn't migrate a working system merely to reduce the number of vendor credentials.

For a new reset flow, I would verify the sender domain, establish SPF and DKIM, check suppression before send, and make bounce polling an explicit background responsibility. Then I would ship it.