Sending Practices & Feedback Handling
This page is intended for AWS SES reviewers evaluating a request to move a Serverless Inbox deployment out of the SES sandbox.
What Serverless Inbox is
Section titled “What Serverless Inbox is”Serverless Inbox is a self-hosted email platform that runs entirely on the customer’s own AWS account. It implements the JMAP protocol (RFC 8621) and uses Amazon SES as its exclusive outbound sending service.
Use case: Transactional and personal email for end users — composing and sending email from their own verified domains. This is not a bulk marketing platform. All outbound email originates from human-initiated actions: a user explicitly composing and sending a message through the platform’s webmail interface or a JMAP-compatible email client.
All infrastructure runs in the customer’s AWS account. Serverless Inbox is the software; the customer is the AWS account holder and SES sender.
How SES feedback is received and processed
Section titled “How SES feedback is received and processed”Serverless Inbox registers an SNS topic as the SES notification destination for bounces, complaints, and delivery events. Every feedback notification triggers a processing pipeline:
Amazon SES → SNS Topic → SQS Queue → Lambda (sqs-ses-event-processor)This pipeline handles six SES notification types:
| Notification | Action taken |
|---|---|
| Send | Recorded on the submission record |
| Delivery | Delivery status updated to confirmed |
| Bounce | Suppression logic applied immediately; sender notified |
| Complaint | Address permanently suppressed immediately |
| Reject | Submission marked failed; sender notified |
| DeliveryDelay | Status updated to delayed |
Processing is fully automated — no human action is required to suppress a bouncing or complaining address.
Bounce handling
Section titled “Bounce handling”SES classifies bounces as Permanent or Transient. Serverless Inbox applies the following logic on every bounce notification:
Permanent bounces
Section titled “Permanent bounces”A permanent bounce causes immediate hard suppression of the recipient address.
The suppression window depends on the SES bounce subtype:
| SES bounce subtype | Suppression window |
|---|---|
NoEmail, Suppressed, OnAccountSuppressionList | Indefinite — no automatic re-enable |
General, MailboxFull | 30 days, then automatically cleared |
| Any other subtype | Indefinite |
A delivery status notification is placed in the sending user’s inbox so they are aware the message was not delivered.
Transient (soft) bounces
Section titled “Transient (soft) bounces”Transient bounces are tracked using a rolling 24-hour window per recipient. If a recipient accumulates 5 or more transient bounces within any 24-hour window, the address is escalated to hard suppression with a 7-day re-enable window.
Individual transient bounces below this threshold are recorded as soft suppressions — they do not block future sends — and the window resets after 24 hours.
Complaint handling
Section titled “Complaint handling”Any complaint received from SES results in immediate, permanent suppression of the complaining address. There is no threshold or delay. The suppression applies per message class (transactional, mailing list, bulk). If the message class cannot be determined, the address is suppressed across all classes.
Complaint suppressions have no automatic re-enable window. Reverting a complaint suppression requires a manual administrative action.
Pre-send suppression check
Section titled “Pre-send suppression check”Suppression is enforced at the point of submission — before any send request is made to SES. The sending path queries the suppression list for every envelope recipient. If any recipient is suppressed, the send is blocked entirely and the attempt is logged to the audit trail.
This means suppressed addresses cannot receive mail from this platform under any circumstances, including if a user re-composes and resends to the same address.
Per-message SES tagging
Section titled “Per-message SES tagging”Every outbound message sent through SES carries a set of message tags that permanently associate the message with the internal record that produced it. These tags are set at send time and travel with the message through the SES feedback pipeline:
| Tag | Value |
|---|---|
tenant_id | The tenant the sending account belongs to |
submission_id | Internal ID of the email submission record |
account_id | The account that owns the sending identity |
user_id | The user who composed and submitted the message |
identity_id | The verified sending identity (email address) used |
domain | The sending domain |
message_class | Message class (e.g. transactional) |
When SES delivers a bounce or complaint notification, these tags are included in the SNS payload. The feedback processor uses them to correlate the event back to the originating submission, account, user, and sending identity.
This provides full traceability for every feedback event — including cases where the original submission record cannot be matched by SES message ID (for example, delayed feedback that arrives after standard record retention windows). In those cases, the processor falls back to the tags on the notification itself to apply suppression against the correct sending identity and message class.
Audit trail
Section titled “Audit trail”Every suppression event — whether a bounce escalation, a complaint, or a blocked send attempt — is written to an immutable audit log in DynamoDB with the following fields:
- Timestamp
- Recipient address
- Suppression level before and after the event
- Bounce type and diagnostic code (for bounces)
- Complaint feedback type (for complaints)
- Sending identity ID, account ID, and user ID (from the submission record or message tags)
- Whether the event was triggered with or without a matching submission record
The audit log is queryable by administrators and forms the basis for any investigation of delivery issues.
Summary of protections
Section titled “Summary of protections”| Risk | Mitigation |
|---|---|
| Sending to invalid addresses | Permanent bounce → immediate indefinite suppression |
| Sending to intermittently failing addresses | Soft bounce threshold → hard suppression after 5 in 24h |
| Sending to recipients who marked mail as spam | Complaint → immediate permanent suppression, manual-only recovery |
| Bypassing suppression at send time | Pre-send check blocks send before SES API is called |
| Feedback events not traceable to a sender | SES message tags on every outbound message link all feedback to the originating user, account, and sending identity |
| Lack of visibility | Full audit log of all suppression events and blocked send attempts |
Related documentation
Section titled “Related documentation”- Bounce & Complaint Handling — technical detail of the feedback pipeline and suppression data model
- Email Sending Pipeline — how outbound email flows from user submission to SES delivery
- Lambda Functions Reference — descriptions of the individual processing components