Amazon SES event destinations route email sending events (SEND, DELIVERY, BOUNCE, COMPLAINT and more) from a configuration set to another AWS service. Pick Amazon SNS for push notifications and fan-out to Lambda or SQS, Amazon EventBridge for rule-based routing (including to event buses in other accounts), or Amazon Data Firehose (formerly Kinesis Data Firehose) for buffered delivery into S3, OpenSearch or Redshift for analytics. CloudWatch suits running totals and alarms. SQS is not a direct destination: reach it through an SNS subscription or an EventBridge rule.
How we analyzed this
We checked the current Amazon SES Developer Guide (event publishing and the per-destination setup pages), the SES API v2 reference, the Amazon Data Firehose API reference and the Amazon EventBridge user guide against the questions developers actually ask: permissions, buffering, routing, replay and failure handling. We do not quote latency numbers because AWS does not publish them for these destinations.
When to pick each destination
The decision hinges on what you need to do after the event leaves SES:
- Amazon SNS — Push each event to a topic as it happens. Good for bounce and complaint processors, suppression-list writers, or a Lambda that updates a CRM. Fan-out to several subscribers (including SQS queues) happens inside SNS. Use a Standard topic (SES does not support FIFO topics) and add a topic access policy that lets
ses.amazonaws.comcallsns:Publish; no IAM role is involved. - Amazon EventBridge — SES sends events to the EventBridge default event bus. From there, rules match on event type or payload fields and route to Lambda, Step Functions, SQS, API destinations, or event buses in the same or other AWS accounts. Best when routing logic is more complex than “send everything to one topic”.
- Amazon Data Firehose — Buffered delivery of full JSON event records. Firehose buffers by size and time (interval 0–900 seconds, default 300) before writing to S3, OpenSearch, Redshift and other Firehose destinations. Choose it for long-term analytics, Athena queries or a data lake. Requires an IAM role that SES can assume to call
firehose:PutRecordBatch. - Amazon CloudWatch — Aggregated metrics only. Use it when you need counts (bounces, complaints, deliveries) and CloudWatch alarms, not individual event payloads.
- Amazon Pinpoint — Still listed as an SES destination type, but AWS ended support for Amazon Pinpoint on October 30, 2026, and Pinpoint never supported the Delivery Delay or Subscription event types. Do not build new pipelines on it; AWS recommends Amazon Kinesis for event collection.
Comparison table
| Destination | Best for | Delivery style | Permissions | Retention / replay |
|---|---|---|---|---|
| SNS | Fan-out to Lambda, SQS, HTTPS | Push per event | Topic access policy for SES | None built in (use subscription DLQs) |
| EventBridge | Rule-based and cross-account routing | Push per event to the default bus | No extra permission step in the SES setup | Optional archive and replay |
| Data Firehose | Analytics in S3, Athena, OpenSearch, Redshift | Buffered (0–900 s, default 300 s) | IAM role SES can assume | Whatever the destination keeps |
| CloudWatch | Metrics and alarms | Aggregated metrics | None extra | CloudWatch metric history |
| Pinpoint | Legacy only | — | — | End of support Oct 30, 2026 |
Setup outline (configuration set required first)
Every event destination belongs to one, and only one, configuration set, so create the configuration set first, then add destinations. Each message must use that configuration set (pass it when you send) for events to be published. Example SES API v2 CLI call for an SNS destination (replace the ARN and event types):
aws sesv2 create-configuration-set-event-destination \
--configuration-set-name production-transactional \
--event-destination-name sns-bounces \
--event-destination '{
"Enabled": true,
"MatchingEventTypes": ["BOUNCE","COMPLAINT"],
"SnsDestination": {"TopicArn": "arn:aws:sns:us-east-1:ACCOUNT:ses-feedback"}
}'EventBridge and Firehose use the same call with an EventBridgeDestination or KinesisFirehoseDestination block. Enable only the event types you need (SEND, REJECT, BOUNCE, COMPLAINT, DELIVERY, OPEN, CLICK, RENDERING_FAILURE, DELIVERY_DELAY, SUBSCRIPTION) to keep volume and downstream cost under control.
Retries, deduplication, and cost notes
- Design consumers to be idempotent: key on the SES message ID so a repeated delivery does not double-process a bounce. See Prevent Duplicate Transactional Emails with Idempotency.
- Firehose buffering suits high-volume analytics; CloudWatch metrics are enough for simple thresholds such as a bounce-rate alarm.
- Use dead-letter queues on SNS subscriptions, or an EventBridge archive, so failed processing can be recovered and replayed.
- SNS charges for messages delivered to subscribed endpoints, so filter event types at the configuration set rather than downstream.
How this relates to ArawaMail
ArawaMail does not expose SES configuration sets or event destinations to customers. Its documented webhook is for incoming mail: outgoing webhooks POST each email that arrives in a mailbox to your HTTPS endpoint (see Transactional email webhooks in Laravel and Next.js). For mail you send through the ArawaMail transactional email API, the send call returns an email id, and the Retrieve Email endpoint returns the stored message with its last_event field. If you run your own SES account, the destinations above are how you get bounce and complaint data; pair them with Amazon SES Suppression Lists and Bounce vs Complaint vs Delay, and keep Amazon SES Sending Limits and Quotas in mind for high-volume event processing.
FAQ
Can I send SES events directly to SQS?
No. SQS is not an SES destination type. Subscribe an SQS queue to an SNS topic destination, or add an EventBridge rule that targets the queue.
Which destination should I use for bounce processing?
SNS plus Lambda (or SNS plus SQS) for acting on each bounce or complaint as it arrives; Firehose plus S3 when you only need the data for analysis and buffering delay is acceptable.
Do I need a configuration set?
Yes. Event destinations can only be set up inside a configuration set, and each destination belongs to exactly one set.
Can I use a FIFO SNS topic?
No. SES only supports Standard SNS topics as event destinations.
What about EventBridge archive and replay?
It is optional: create an archive on the bus, choose which events and how long to keep them, and replay them later to recover from processing errors.
Sources: Amazon SES Developer Guide (event publishing; SNS, EventBridge, Firehose and Pinpoint destination setup), Amazon SES API v2 reference (EventDestinationDefinition, SnsDestination), Amazon Data Firehose API reference (BufferingHints), Amazon EventBridge user guide (targets, archive and replay), and the Amazon Pinpoint end-of-support notice.