Build email delivery around provider events, not just send-API responses. Capture bounce, complaint, delivery, delay, and rejection signals; update message and recipient records; and suppress addresses that should not be retried. A successful send request means the provider accepted the request—not that the message reached an inbox.
Why a successful send request is not proof of delivery
Email delivery is asynchronous. Amazon SES distinguishes a successful send request from later events such as delivery, bounce, complaint, rejection, or delay. Even a recorded send may not result in delivery if account-level or global suppression prevents it. A delivery event means delivery to the recipient mail system, not guaranteed inbox placement. AWS explains SES sending activity and its monitoring signals.
As an Amazon Associate I earn from qualifying purchases.
For a gaming product, persist the provider’s message identifier and correlate later events with your own message and recipient records. That lets support tools and operational dashboards show the actual state rather than treating “accepted by API” as “delivered.”
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Which events should your system handle?
Event names and available detail depend on the provider and the monitoring configuration. SES documents send, rendering failure, reject, delivery, bounce, complaint, delivery delay, subscription, open, and click events; its aggregate statistics and event-level publishing provide different levels of detail. Design around the signals your application needs, and verify that your selected event path is applied to the messages you send. SES monitoring options include dashboard and API statistics, CloudWatch metrics, feedback notifications, and event publishing.
#1 Best Overall
- Delivery: The receiving mail system accepted the message; this does not establish inbox placement.
- Bounce: Delivery failed. The reason and permanence determine whether a retry is appropriate.
- Complaint: A recipient marked a delivered message as spam. Treat this as a stop-sending signal.
- Reject or rendering failure: Investigate the sending or content-generation path rather than retrying blindly.
- Delay: Delivery is not yet final. A temporary problem may resolve, or the provider may later report failure.
How to process bounce and complaint events
Separate permanent bounces from temporary failures
SES defines a hard bounce as a permanent rejection. A soft bounce is a temporary failure, such as a busy receiving server or full mailbox. SES may retry a soft bounce for a period and notify you if delivery ultimately fails, so do not assume every temporary-failure notice is an immediate final result. AWS describes SES bounce, complaint, and delivery behavior.
Record the event and its reason, then apply a policy that distinguishes temporary from permanent failures. A permanent failure should normally prevent repeated sends to that address until the address is corrected or otherwise verified. For temporary failures, avoid an uncontrolled application retry loop: the provider may already be retrying, and repeated sends can create duplicate messages.
Suppress complaint-generating recipients
A complaint indicates the message reached the receiving mail system and the recipient marked it as spam. Stop sending to the affected recipient rather than repeatedly attempting delivery. Complaint data may not identify the complainant unambiguously: AWS notes that many ISPs do not expose the address, so an event can identify possible recipients based on the original message and ISP. When the event is ambiguous, avoid treating a guessed address as certain; preserve the event details and use the provider’s supported suppression behavior. AWS guidance on complaints.
Keep suppression scope explicit
Suppression is provider-specific. Mailgun organizes bounce, complaint, and unsubscribe suppressions by domain and says these records can be viewed in its control panel or accessed through relevant APIs. SES also has account-level and global suppression behavior. Do not assume a suppression entry applies across providers, accounts, identities, or domains; establish which sending path and scope your own suppression policy covers. Mailgun documents its suppression and allowlist model.
Choose an event capture path that covers your sends
SES supports bounce and complaint capture through notification email, SNS notifications, or event publishing. Identity notification settings apply to mail sent from that identity in the AWS Region where they were configured. If multiple methods are enabled, the same event may generate more than one notification. If neither notification configuration nor event publishing is set up, feedback may be forwarded to the message Return-Path or Source address. AWS explains SES notification setup and scope.
SES event publishing can send event data to CloudWatch, Firehose, or SNS. CloudWatch metric use in this context can incur additional charges, so check the current AWS terms for your configuration. A provider webhook is another model: Mailgun sends an HTTP or HTTPS POST with a JSON payload to the configured endpoint when an event occurs, and describes event delivery as near real-time. Its documented webhook use cases include storing events, updating delivery status, removing bounced, complaining, or unsubscribed addresses, and triggering a fallback channel for critical transactional mail. Mailgun webhook documentation.
| Approach | What it is suited to | Scope and operational consideration |
|---|---|---|
| SES dashboard and API statistics | Aggregate counts and sending trends. | Less granular than recipient- or message-level event records; consult SES monitoring documentation. |
| SES notification email or SNS | Receiving bounce, complaint, and related feedback notifications. | Identity and Region configuration matter; multiple enabled methods can produce duplicate notifications. See SES notification setup. |
| SES event publishing | Fine-grained event monitoring with destinations including CloudWatch, Firehose, or SNS. | Ensure the event configuration covers the messages being sent; CloudWatch metric use may add charges. See SES event monitoring. |
| Mailgun webhooks | Posting event JSON to an application endpoint for processing and reporting. | Webhook delivery is described as near real-time; Mailgun suppression records are organized per domain. See webhooks and suppressions. |
Build a resilient event handler
SES SNS notifications are JSON with a top-level notification type, a mail object, and a bounce, complaint, or delivery object. Notifications can cover several recipients or one recipient; AWS does not guarantee event ordering or batching behavior. Process recipients independently and design the handler to tolerate duplicate and out-of-order arrivals. Idempotency is an engineering safeguard implied by those delivery limits, not a provider guarantee. AWS documents SNS notification contents.
- Receive and validate. Accept the configured provider notification or webhook, validate it according to the provider’s security requirements, and retain the raw event for diagnosis.
- Correlate. Match the provider message identifier and recipient details to your outbound message record. Account for events that identify multiple recipients or do not conclusively identify a complainant.
- Apply each recipient outcome. Update message status and recipient eligibility separately. Do not infer that every recipient in a batch has the same outcome.
- Make processing idempotent. Store a stable event identifier when available, or otherwise define a deduplication strategy so a repeated notification does not trigger repeated side effects.
- Handle arrival order safely. Do not let a later-arriving stale event overwrite a more authoritative state without checking timestamps and event meaning. Preserve event history rather than relying on one mutable status alone.
- Reconcile and alert. Track events that cannot be correlated or processed, and compare application records with provider monitoring so broken endpoints or misconfigured event paths are visible.
Monitor delivery without confusing metrics
Use aggregate monitoring to spot changes in sending activity and event-level records to investigate individual messages or recipients. Keep counts of sends, deliveries, bounces, complaints, rejects, and delays distinct. A send count is not a delivery count, and a delivery event is not proof that the message appeared in the inbox. SES describes its monitoring mechanisms and event types.
Best Value
Break down trends at a scope that matches your configuration—for example, by sending identity and AWS Region for SES notifications, or by Mailgun domain for its suppression records. Alert on sudden changes in event patterns and on monitoring failures, but do not apply universal bounce-rate or complaint-rate thresholds without provider-, region-, and traffic-specific evidence.
Event history is not retroactive. AWS says SES event-monitoring mechanisms do not provide records for messages sent before the monitoring mechanism was implemented. Configure capture before production sending if you need an operational history from the start. AWS explains SES event logs and notifications.
Quick Recap
Implementation checklist for a gaming product
- Choose provider events and destinations that cover each production sending identity, domain, and—where applicable—AWS Region.
- Persist outbound message identifiers, recipient association, send time, and event history.
- Distinguish provider acceptance, delivery to the mail system, temporary delay, permanent bounce, complaint, rejection, and rendering failure.
- Suppress complaint recipients and prevent repeat attempts to permanently invalid addresses.
- Make notification processing safe for duplicates, multiple recipients, and out-of-order arrival.
- Monitor aggregate trends alongside recipient-level events, and alert when event capture itself stops working.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Recommended Free Tools
