Delivery

Delivery events

Track recipient outcomes and keep provider acceptance separate from actual delivery.

Understand the states

Understand the states
State	Meaning
`queued / processing`	Stored and waiting, or claimed by the worker.
`sent`	SES accepted the message.
`delivered`	The recipient mail server accepted the message.
`delayed`	Delivery is delayed; this is not a final bounce.
`soft_bounced`	A transient bounce; no automatic suppression.
`hard_bounced`	Permanent bounce; the address is suppressed.
`complained`	Spam complaint; the address is suppressed.
`rejected / failed`	Provider rejection or processing failure. Inspect the failure code.
`suppressed`	Blocked before sending.
`simulated`	Test-mode processing; no external delivery.

Recipient outcomes are tracked individually. A hard bounce or complaint survives later or out-of-order delivery events. Delivery cannot confirm inbox placement or that the email was read.

Open an email in the dashboard to inspect its chronological events and per-recipient outcomes. Duplicate SNS notifications are handled without duplicating the business event. Webhooks use a stable event ID, so receivers must also deduplicate and tolerate out-of-order events.

Configure SES notifications (operators)

Create a standard SNS topic in the same region as SES and set SignatureVersion to 2.
Restrict the topic policy to SES publication from your AWS account.
Set the exact topic ARN as SES_SNS_TOPIC_ARN in the backend API.
In the SES configuration set used by the worker, add an SNS destination for Send, Delivery, Bounce, Complaint, Reject and DeliveryDelay.
Subscribe the public API's HTTPS /v1/events/ses endpoint. Keep raw message delivery disabled.
Run the API and worker. Valid signed subscription confirmations for the configured topic are confirmed automatically.