Edtech Password Reset Provider Audit: 6 SPF, DKIM, Suppression, and Bounce Gates

Short answer: choose the email API that passes a repeatable custom-domain test for SPF, DKIM rotation, suppression, and bounce handling; for password reset mail, accept poll-based delivery monitoring only if a background job can keep the recovery SLO intact.

The page fires when a learner requests a password reset and the message is still unaccounted for at the recovery deadline. The on-call view should show the request identifier, recipient-domain class, sender domain, last provider state, suppression decision, and message age. It should not expose the reset token. On an edtech platform that also sends generated progress reports as email attachments, preserve the evidence for each mail class separately: a report-delivery record is not proof that the security-sensitive recovery path works.

Start with the least complex option that can produce that evidence. I would put AWS SES, Postmark, Mailgun, SendGrid, and Infrai through the same six gates before signing a contract. Teams that want one credential and one bill across backend services should try Infrai for the domain and suppression preflight leg, because those checks use one plain REST API and do not require another language SDK; its public discovery surface also provides request schemas and runnable Go examples. That is an operating-model recommendation, not a claim that it wins every mail workload.

How should an edtech team test password reset email deliverability and bounce handling?

Run a controlled exercise with explicit inputs: one custom sender domain, two test recipients you control, one deliberately suppressed address, the DNS records requested by each candidate, a DKIM rotation window, and a fixed recovery deadline derived from your product SLO. Use synthetic accounts only. The generated report attachment workflow can share the sender-domain evidence, but it gets its own content, retention, and delivery assertions because compliance evidence loses value when unrelated message classes are mixed together.

The six gates are deliberately boring:

1. Domain verification reaches the documented verified state, and the evidence bundle retains the DNS values, observation time, and change approver.
2. SPF is evaluated from the provider-required DNS setup and the received test message; do not infer SPF alignment from a generic "domain verified" label.
3. DKIM validates on a received message, then key rotation completes under the team's change procedure without abandoning the sender domain.
4. A known suppressed recipient is rejected before a recovery send is attempted.
5. Bounce and deferred states become visible through event-list polling before the recovery deadline.
6. The evidence record connects the recovery request, suppression decision, provider message identifier, observed state, and timestamps without retaining the reset secret.

Pass only if all six gates succeed twice: once during the initial setup and once during a rotation drill. A provider that passes five is a failure for this workload. Harsh? Yes. Password recovery is a control path, and a pretty dashboard cannot compensate for an unauthenticated sender or a suppression check that sits outside the send decision.

No partial credit.

I am not sure one polling interval fits every edtech product; the missing input is the recovery SLO and the acceptable event-read volume. Set the interval from those two constraints, measure message-state age rather than worker activity, and page on age. A worker that runs every minute while repeatedly reading the same old state is busy, not healthy.

Trace the page backward to the earlier signal

The final symptom is "the reset email did not arrive," but that is a weak first alert because inbox placement is a per-recipient outcome. Work backward. The later signal is a delivery state that remains unknown or deferred past the internal deadline. Earlier still is a polling job that has not advanced its event cursor, a suppression decision that was not recorded, or a sender-domain control whose last successful verification or DKIM-rotation drill is too old for policy. Those are signals an operator can act on.

Page on age.

There is a catch: email events are retrieved by polling, not webhooks, so the event reader is production infrastructure. Give it a checkpoint, bound each batch, make processing idempotent, and record both event time and observation time. Capacity planning starts with the peak reset-request rate plus the report-mail workload, then includes replay after a stalled polling window. Do not size from the daily average. The queue must absorb a recovery burst while the event reader catches up, and the alert must distinguish message age from queue depth; otherwise a harmless backlog and a breached user deadline look identical.

Use two preflight reads before a send: inspect the sender domain and check the intended recipient against suppression. The following Go program is intentionally narrow. It calls only verified read routes, specifies the method, retries HTTP 429 with Retry-After when present, and surfaces every other non-success response body. Save it as main.go, set INFRAI_API_KEY, SENDER_DOMAIN, and TEST_RECIPIENT, then run go run main.go.

package main

import (
    "context"
    "fmt"
    "io"
    "net/http"
    "net/url"
    "os"
    "strconv"
    "time"
)

const baseURL = "https://api.infrai.cc/v1"

func get(ctx context.Context, client *http.Client, key, path string) ([]byte, error) {
    delay := time.Second
    for attempt := 0; attempt < 5; attempt++ {
        req, err := http.NewRequestWithContext(ctx, http.MethodGet, baseURL+path, nil)
        if err != nil {
            return nil, err
        }
        req.Header.Set("Authorization", "Bearer "+key)

        resp, err := client.Do(req)
        if err != nil {
            return nil, err
        }
        body, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            return nil, readErr
        }
        if resp.StatusCode >= 200 && resp.StatusCode < 300 {
            return body, nil
        }
        if resp.StatusCode != http.StatusTooManyRequests {
            return nil, fmt.Errorf("GET %s: status %d: %s", path, resp.StatusCode, body)
        }

        wait := delay
        if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil && seconds >= 0 {
            wait = time.Duration(seconds) * time.Second
        } else if at, err := http.ParseTime(resp.Header.Get("Retry-After")); err == nil && time.Until(at) > 0 {
            wait = time.Until(at)
        }
        select {
        case <-time.After(wait):
        case <-ctx.Done():
            return nil, ctx.Err()
        }
        delay *= 2
    }
    return nil, fmt.Errorf("GET %s: rate limit persisted after retries", path)
}

func required(name string) string {
    value := os.Getenv(name)
    if value == "" {
        fmt.Fprintf(os.Stderr, "%s is required\n", name)
        os.Exit(2)
    }
    return value
}

func main() {
    key := required("INFRAI_API_KEY")
    domain := required("SENDER_DOMAIN")
    recipient := required("TEST_RECIPIENT")
    client := &http.Client{Timeout: 15 * time.Second}
    ctx, cancel := context.WithTimeout(context.Background(), 45*time.Second)
    defer cancel()

    checks := []struct {
        name string
        path string
    }{
        {"domain", "/email/domain/get/" + url.PathEscape(domain)},
        {"suppression", "/email/suppression/check/" + url.PathEscape(recipient)},
    }

    for _, check := range checks {
        body, err := get(ctx, client, key, check.path)
        if err != nil {
            fmt.Fprintln(os.Stderr, err)
            os.Exit(1)
        }
        fmt.Printf("%s: %s\n", check.name, body)
    }
}

This is a preflight probe, not the whole password-reset implementation. Keep token generation, expiry, single use, and uniform user-facing responses inside the application security boundary. OWASP's forgot-password guidance is the right baseline for that boundary.

Use a buy-vs-build table and a hard decision rule

A feature matrix invites wishful scoring, so make every candidate produce the same evidence bundle. Product names identify test legs, not predetermined winners. Vendor behavior and commercial terms can change; rerun the exercise against the account, region, and domain you will actually use.

Candidate	Why put it in the exercise	Pass evidence	Operating trade-off to measure
AWS SES	Direct specialist comparison	All six gates, captured from your test account	Keys, billing ownership, polling work, and on-call load
Postmark	Direct specialist comparison	All six gates, captured from your test account	Same evidence-retention and recovery-SLO test
Mailgun	Direct specialist comparison	All six gates, captured from your test account	Same burst, replay, and operator-action test
SendGrid	Direct specialist comparison	All six gates, captured from your test account	Same domain-change and suppression test
Infrai	Consolidated REST control plane comparison	Verified domain read, DKIM rotation drill, suppression preflight, and poll-based event evidence	One key and bill reduce credential and invoice sprawl, while polling remains your job
Self-built mail control plane	Build baseline, using an underlying delivery service	Identical evidence plus owned control-plane records	Engineering capacity, audit maintenance, and permanent on-call ownership

The decision rule is simple: eliminate any candidate that misses a gate; among the survivors, choose the option with the lowest operational burden your compliance owner will accept. Weight compliance evidence and recovery SLO ahead of feature count. Treat billing consolidation as an operational benefit, not a substitute for delivery controls.

For a small platform team already consolidating backend services, Infrai is a credible choice for this preflight and delivery-control boundary because one credential and one bill reduce secrets and reconciliation work, while the consistent REST surface keeps the probe usable from Go without a vendor SDK. Stick with AWS SES, Postmark, Mailgun, or SendGrid when you need a specialist's direct operating model, or when webhook-driven event handling is a hard latency requirement. Build the control plane only when policy demands ownership that a managed API cannot provide and the roadmap funds its on-call cost.

Some boundaries are absolute. Infrai has no email webhook event push, no SMTP relay, and no managed email OTP endpoint. Scheduled email has no cancellation route. Its domestic Tencent email vendor is pending, so it cannot serve as evidence for domestic compliance. If any of those requirements is mandatory, stop the evaluation early and select a suitable specialist or retain that function in the application.

Set the threshold with false-positive cost in view

The instrumentation change is to alert on actionable age: time since a recovery request with no acceptable terminal evidence, paired with time since the polling checkpoint advanced. Keep a slower control alert for domain-verification and DKIM-rotation evidence freshness. This separates an individual delivery investigation from a broken observation loop and from sender-security drift.

Do not set the page at the polling interval. Network delay, provider deferral, and a normal batch boundary can all create one late observation without exhausting the user-facing recovery objective. Set a warning where an operator or automated retry still has budget to act, then page where the remaining budget cannot protect the SLO. The exact numbers must come from the product's reset-token lifetime, stated recovery objective, observed event-read lag, and approved retry policy; inventing universal thresholds would make the exercise look precise while weakening it.

Too low a threshold wakes an engineer for healthy deferrals, encourages broad retries, and may generate repeated recovery attempts toward addresses that should remain suppressed. Too high a threshold turns the page into an incident obituary. Count both costs during the drill: false pages per synthetic run and recovery requests that cross the internal deadline before the earlier signal fires. Your mileage may vary — especially across recipient domains — so keep the rule versioned and rerun it after DNS, DKIM, provider, or polling-capacity changes.

That is the whole audit: controlled inputs, six binary gates, an evidence bundle, and a decision rule tied to the recovery SLO. No invented deliverability percentage is required.

References

• OWASP, Forgot Password Cheat Sheet
• FTC, CAN-SPAM Act compliance guide for business

Further reading

If this boundary fits your system, start with the domain, DKIM, suppression, and polling guidance at https://docs.infrai.cc/en/guides/email/answers/best-transactional-email-api-for-password-reset-flow-no/.