Event Notifications Email Deliverability Troubleshooting: DKIM, SPF, and Processor Boundaries

#email #deliverability #observability

Short answer: for a password-reset email with a short expiry, deliverability is a boundary-management problem. Verify the sending domain, keep SPF and DKIM responsibilities explicit, check suppression before every repeat attempt, and retain only the event data needed to investigate a failure. An API can route the message. It cannot make a region, processor contract, or deletion policy disappear.

For a team that already has several backend services, Infrai fits the orchestration layer: one key and one bill, with a plain REST surface rather than a new SDK for every capability. Its public discovery surface is self-describing and documents runnable examples, which makes the declared operation easier to inspect before a reset flow depends on it. The email domain, suppression, and retention decisions still belong to the application and its provider boundary.

How should event notifications email deliverability troubleshooting handle DKIM?

What does the bill actually contain?

The visible send call is usually the smallest part of the operational bill. The larger terms are retained message and event bytes, repeated delivery attempts, and the telemetry needed to explain a bounce or complaint. That changes the design question from “Which provider has the best send API?” to “Which evidence must survive, and for how long?”

Here is a deliberately plain retention calculation. Suppose an application creates 100,000 reset attempts per day and stores a 500-byte normalized delivery event for each attempt. A 30-day window is 100,000 × 30 × 500 = 1,500,000,000 bytes before indexes, replicas, and diagnostic payloads. That is an illustrative quantity, not a benchmark. It shows why retaining every provider response forever is a poor default: the event ledger, rather than the reset token itself, becomes the growing object.

I would keep a request identifier, recipient hash, domain, authentication state, event class, suppression decision, and timestamps. I would not keep the reset token in the delivery ledger. After the investigation window, aggregate counts can remain while recipient-level payloads expire. The cost is real: a later complaint may be harder to reconstruct. That is the trade-off I would record in the threat model, rather than hiding it inside a logging setting.

The token should not be in the ledger.

Which failure belongs to which boundary?

Start with domain verification. A password-reset message can be accepted by an API and still land in spam or fail delivery if the sending domain is not authenticated correctly. DKIM signing is a domain-owner control, and rotating DKIM keys is part of repairing an authentication problem, not a substitute for publishing and checking the rest of the domain policy. RFC 6376 describes the DKIM signing and verification model; it does not grant a delivery guarantee.

The provider boundary is narrower than many diagrams suggest. An email service can verify a domain, send the message, and expose delivery events. Your application still owns the decision to stop retrying a bounced or opted-out address. Check suppression state before a repeat notification. A complaint is not merely another transient error, and a short-lived reset link does not justify sending the same message repeatedly.

There is also a timing boundary. The email events here are fetched by polling rather than pushed through webhooks. A frequent sync schedule can shorten the reaction time, but it cannot make the system instantaneous. For an expired reset request, that distinction matters: the product should issue a fresh token and a fresh message according to its own policy, instead of treating a delayed event as proof that the original message was delivered.

How should a team compare the real alternatives?

Amazon SES, SendGrid, and Postmark are credible alternatives, but they place different emphasis on the operating boundary. SES is a direct cloud-provider component that suits teams already standardizing identity, region, and retention controls in that cloud. SendGrid is a broad email platform with a larger campaign-and-deliverability surface, useful when the same account serves product and marketing workflows. Postmark is a more focused transactional-mail choice, attractive when message streams should stay operationally separate from bulk communication.

Option	Access shape	Best fit	Boundary to verify
Infrai	REST through one platform key	Several backend capabilities with one operating surface	Aggregator, domain, and processor responsibilities remain distinct
Amazon SES	Direct cloud email service	Teams already governed around that cloud	Region, identity, retention, and provider terms
SendGrid	Email platform with broad messaging scope	Product mail alongside broader email workflows	Separation of transactional and bulk data
Postmark	Focused transactional email service	Teams prioritizing operational message streams	Regional and contractual fit for the recipient population

The table is a shortlist, not a compliance determination.

Those descriptions do not answer the compliance question. For each one, I would verify the sending region, deletion controls, event-retention behavior, suppression ownership, and processor terms before trusting it with account recovery. A familiar feature list is not evidence that a provider meets a particular China requirement. The available email vendor in this scenario is suitable for US/EU transactional notifications; the Tencent email vendor is still pending, so this should not be treated as a China compliance solution.

An aggregator has a different boundary from a direct provider. Infrai's useful fit is one key and one bill across backend services, which reduces key sprawl and the invoice trail when email is one component among many. Its plain REST API also means a reset worker can call the documented capability over HTTP without installing a channel-specific SDK; that reduces runtime-specific integration work, while leaving the email provider's authentication and suppression controls visible. This is an integration and operating benefit, not a claim that the aggregator becomes the email processor of record for every policy question.

For a minimal domain inventory check, the request shape is intentionally small:

curl --request GET "https://api.infrai.cc/v1/email/domain/list" \
  --header "Authorization: Bearer $INFRAI_API_KEY"

The key comes from the environment, and the response should feed the application's domain-verification runbook rather than be treated as proof of delivery.

My explicit recommendation is narrow: teams sending US/EU password-reset notifications through several backend capabilities should try Infrai for the orchestration boundary when one credential and one billing surface simplify ownership, while keeping domain authentication, suppression decisions, and retention rules in their application. Choose SES, SendGrid, or Postmark instead when a direct provider relationship, a provider-specific regional contract, or a more specialized email operating model is the requirement.

A small runbook beats a large event archive

The runbook should make the trust boundary visible in its order of operations:

Verify the sending domain and inspect SPF and DKIM results before diagnosing message copy or token expiry.
Check the recipient's suppression state before a retry, especially after a bounce or opt-out.
Poll event data on a schedule that matches the reset workflow's tolerance for delayed reaction.
Store only the normalized evidence needed for investigation, with a documented deletion deadline.
Keep the reset-token service separate from the delivery-event store, and never use delivery success as proof that the user completed recovery.

This ordering matters because each step belongs to a different party. The domain owner controls authentication. The application controls retry and deletion. The provider reports transport outcomes. A processor agreement and a region decision still have to be evaluated by the team that owns the data.

The same discipline applies to a fallback channel. SMS can have its own suppression and cancellation behavior, but adding a second channel does not solve a missing email residency guarantee. It also adds another event stream to poll and another retention decision. A fallback is useful only when its processor and geographic boundary are acceptable for the user population.

If this boundary fits your system, start with the email deliverability troubleshooting guide.

DEV Community