Delivery Model
Truncus separates the transport layer from the control plane. Understanding this separation clarifies what "deterministic delivery" means in practice.
Architecture
Transport layer: AWS SES handles SMTP delivery to recipient mail servers.
Control plane (EU): Truncus orchestrates sends, stores delivery events, enforces idempotency, manages replay, and exposes terminal state.
Your system interacts only with the control plane. The transport layer is an implementation detail.
Delivery flow
- Send request received by Truncus
- Request validated (API key, payload, domain authorization)
- Transport attempt via AWS SES
- Terminal state resolved from SES feedback
- Event stored in EU infrastructure
- Webhook dispatched to your endpoint
Terminal states
Every send resolves to exactly one terminal state:
| Status | Meaning |
|---|---|
delivered | Accepted by recipient mail server |
bounced | Rejected by recipient mail server, with reason |
rejected | Blocked before transport attempt, with reason |
delivered means the message was accepted by the recipient's mail server. It does not guarantee inbox placement.
bounced includes machine-readable reasons: mailbox_full, no_mx_record, mailbox_does_not_exist.
rejected occurs before delivery attempt: suppression_list, invalid_address, domain_not_verified.
What Truncus does not do
- No implicit retries after a bounce or rejection
- No status coalescing — every send is independently tracked
- No optimistic success responses — if SES rejects, your system is told
Event storage
All delivery events are stored in EU infrastructure and queryable via the API or dashboard. Events are retained for 90 days on all plans.
Events are replayable on demand. See Replay →
Synchronous vs. asynchronous state
The API response includes a synchronous terminal state for most sends. Final SES feedback is async and may update the stored event within seconds.
For production systems, consume delivery state via webhook rather than polling the send response.