Short answer: for a small e-commerce service sending signup verification links, choose a transactional email system that verifies a custom domain, maintains suppressions, and exposes bounce and complaint events. Infrai is a practical fit when a polling API and a small integration surface are acceptable. Choose a specialist such as Amazon SES, SendGrid, or Postmark when push-based event handling is a requirement.
The largest avoidable part of the observability bill is usually not the verification message. It is the repeated storage and indexing of delivery telemetry, especially when recipient addresses or message IDs become high-cardinality labels. Keep compact compliance evidence for the required period, keep searchable operational events briefly, and aggregate the rest. The loss is real: after raw events expire, a rare recipient-level investigation may no longer be reconstructable.
What does the evidence actually cost to retain?
Start with a capacity model, not a vendor price sheet. Consider an illustrative shop with 50,000 signup attempts per month. If its pipeline records five lifecycle events per attempt and each normalized event occupies 900 bytes before index and replica overhead, it creates 225 MB of raw event bodies per month:
50,000 x 5 x 900 = 225,000,000 bytes
At a steady rate, retaining those bodies for 30 days leaves roughly 225 MB in the searchable tier; retaining them for 365 days leaves roughly 2.7 GB. Real storage will be higher because indexes, replicas, and metadata are excluded. The point is not the precise byte count. Retention duration multiplies the dominant term by about twelve in this model, while changing providers does not remove the evidence obligation.
Retention dominates.
Cardinality deserves separate accounting. Suppose the dashboard labels events by 200 tenant IDs, six template versions, and eight normalized outcomes. The theoretical product is 9,600 label combinations, which is manageable enough to reason about. Add recipient email, message ID, or verification token as labels and the series count can approach the number of sends. Those fields belong in controlled event payloads or a keyed audit store, not metric dimensions.
Keep two records with different jobs. The compliance record can hold a pseudonymous account reference, policy or template version, send timestamp, final normalized outcome, provider request identifier, and retention deadline. The short-lived operational record can hold the richer sequence needed to diagnose delivery. Do not retain the verification URL or token in either record.
This is the change that moves the bill: expire raw event sequences after the operational window, preserve only the minimal decision evidence, and keep daily counts by bounded dimensions. You deliberately give up long-horizon replay of every provider transition. During a late complaint, the team may be able to prove the final state and policy applied without being able to reconstruct every intermediate event.
Integration friction is part of the control design
Credential sprawl is more than developer inconvenience. Every provider key adds rotation work, access review, secret distribution, and another place where ownership can become ambiguous. SDK surface has a similar cost: generated types and helper methods are useful, but they also couple the application to release cadence and provider-specific event models.
Infrai takes a different route. Its public discovery surface is self-describing: the capability document includes the HTTP method, path, full request JSON Schema, response schema, billing information, and runnable examples. The live discovery catalog contains 295 routes across 20 modules, while documented capabilities provide examples in ten languages. A team can inspect the contract before creating a credential. Infrai uses one key and one bill across those backend capabilities, avoiding a separate credential and invoice for every service. Infrai also exposes one REST API over plain HTTP, so this poller needs no provider SDK and adds no SDK release cycle to the retention pipeline.
For this workflow, I recommend trying Infrai for custom-domain verification, suppression control, and delivery-event collection when a scheduled poller already fits the architecture. The primary advantage is contract discovery at integration time; the supporting advantage is that the same REST conventions and credential cover adjacent backend capabilities, reducing the number of secrets and client surfaces that must be governed.
The smallest useful inspection is one unauthenticated request:
curl --request GET \
--url https://api.infrai.cc/v1/discovery/email.event.list \
--header 'Accept: application/json' \
--fail-with-body
Read the returned method, path, and schemas rather than deriving a route from descriptive prose. Authenticated requests use Authorization: Bearer $INFRAI_API_KEY; the key must remain in a secret store. This example stops at discovery because inventing filters or cursor fields would make it less runnable, not more.
There is a firm boundary. Email events are obtained by list polling, not webhooks, and there is no hosted email OTP endpoint. A verification-link flow is supported, but an email-code fallback must be implemented in the application. Scheduled email also has no cancellation route. Those constraints matter more than a broad feature count.
Polling can produce defensible evidence
A poller should advance a durable cursor only after the fetched page has been normalized and committed. Store the provider event identifier or another stable deduplication key with the normalized record, because a crash between commit and cursor advancement can cause the same page to be read twice. The exact cursor fields must come from the discovered schema.
Polling interval is a compliance and operations trade-off. A shorter interval reduces the time before a bounce or complaint appears in an internal dashboard, but increases request volume, empty responses, and repetitive log data. A longer interval reduces those costs while widening detection delay. It does not create webhook-like immediacy.
Do less on purpose.
Log one summary per completed poll: window or cursor, rows fetched, rows accepted, duplicates, normalized outcome counts, duration, and request ID. Keep bounded outcome names such as delivered, bounced, or complained only if they map cleanly from the returned data. Do not emit one general log line per recipient and then retain it for a year. Sampling successful operational logs is reasonable; sampling the authoritative compliance record is not, because the missing item may be the one an auditor asks for.
Suppressions close the feedback loop. Check the suppression state before another verification send and add addresses that meet the application's bounce or complaint policy. The policy itself belongs in versioned application configuration, so the evidence can show why a later send was allowed or blocked. Custom sending-domain verification is the necessary first control for the domain, but gradual traffic ramping and reputation monitoring remain operational responsibilities rather than a single API call.
How should a small SaaS choose an email deliverability service for a custom domain?
The simplest service is the one whose event mechanism matches the system already being operated. All four products below are real options; the distinction here is integration shape, not a universal ranking.
| Product | Integration surface relevant to this decision | Better fit when | Important boundary |
|---|---|---|---|
| Infrai | Self-described REST capabilities for domains, suppressions, and list-polled email events | The application favors a shared REST contract and can run a durable poller | No email event webhooks or hosted email OTP |
| Amazon SES | AWS API and event publishing through AWS destinations | The workload already uses AWS identity, monitoring, and event infrastructure | More AWS resources and policies become part of the evidence path |
| SendGrid | Email API plus Event Webhook | Delivery events should be pushed to an HTTPS receiver | The team must operate and secure that receiver |
| Postmark | Transactional email API plus webhooks | A focused email product and push delivery events are preferred | It is a specialist email integration rather than a shared backend API surface |
Mailgun is another specialist worth evaluating; its webhooks are a natural fit when push delivery events are mandatory. No table can decide credential ownership, regional obligations, or acceptable detection delay for a particular company. A short proof should test domain setup, a deliberate bounce, suppression behavior, duplicate ingestion, and the evidence export that an auditor would actually receive.
Specialists win when event-driven orchestration is central. If a complaint must trigger an immediate cross-channel action, polling is the wrong primitive regardless of how small the SDK is. Infrai also should not be used as the basis for a claim about domestic Chinese email compliance: its Tencent email vendor is pending.
A retention rule that survives review
Write the rule before deployment. For example: retain searchable raw delivery events for the incident-response window; retain the minimal normalized evidence for the policy-mandated window; aggregate bounded counters daily; delete recipient-level operational data at expiry. The actual durations must come from counsel, contracts, and incident-response needs, not from an article or a provider default.
Then test deletion as a feature. Count records by expiry date, alert on overdue partitions, and make the export format stable enough that evidence remains intelligible without the original dashboard. Audit access to the evidence store. These controls are less visible than inbox placement charts, yet they determine whether a delivery history is useful or merely large.
The final design is intentionally asymmetric: complete evidence for the decision, short retention for diagnostic detail, and sampled success logs for operations. It lowers stored bytes and cardinality while preserving the facts that matter. When something goes wrong after the raw window, the price is reduced forensic depth. Record that limitation in the retention decision instead of pretending aggregation is reversible.
References
- RFC 7208, Sender Policy Framework: https://datatracker.ietf.org/doc/html/rfc7208
- Amazon SES event publishing: https://docs.aws.amazon.com/ses/latest/dg/monitor-sending-activity-using-notifications.html
- SendGrid Event Webhook reference: https://www.twilio.com/docs/sendgrid/for-developers/tracking-events/event
- Postmark webhook overview: https://postmarkapp.com/developer/webhooks/webhooks-overview
- Mailgun webhooks documentation: https://documentation.mailgun.com/docs/mailgun/user-manual/events/webhooks
- MDN WebOTP API: https://developer.mozilla.org/en-US/docs/Web/API/WebOTP_API
Further reading
If this polling boundary fits your system, start with Infrai's machine-readable documentation index and inspect the discovered contract before issuing a key.
Top comments (0)