Why do AWS SES emails get stuck in Send status and how can this be investigated?
Published 19 Jun 2025
Updated 14 Oct 2026
15 min read
Summarize with
Updated on 14 Oct 2026: We clarified SES suppression outcomes and added a repeatable test for missing delivery events.
An AWS SES email that only has a Send event is not proven delivered. It means the send request succeeded and SES will attempt delivery, except when suppression prevents that attempt. If messages remain Send-only beyond your normal event-processing window, verify event capture and message matching first, then check active retries, suppression event subtypes, and account health.
Treat Send as a handoff state, not a final state. A brief reporting gap can come from retries or reporting lag. A sustained increase above your established baseline points to missing or filtered events, recipient-side temporary failures, an incorrect configuration set, or broken joins between event records.
A Send event means the SES request succeeded. A message remains Send-only in your reporting when a later event was not published, delivered, stored, or joined correctly, or when SES is still retrying and no final outcome exists yet. Suppressed requests produce a Bounce or Complaint event depending on the suppression reason. A missing suppression outcome therefore also points to an event-collection gap.
- First check: Confirm the exact AWS Region, configuration set, selected event types, and destination health.
- Second check: Match the SES message ID across raw events before trusting a campaign-level status.
- Third check: Inspect delays and suppression event subtypes, then group unresolved messages by recipient domain.
What Send means in AWS SES
SES event names are easy to misread because Send sounds like a completed action. AWS defines it as a successful send request after which SES will attempt delivery, unless suppression applies. It does not mean the recipient server accepted the message, the inbox provider placed it in the inbox, or the recipient saw it.
The next event should normally explain the outcome. Delivery means the recipient mail server accepted the message. Bounce records a delivery failure or suppression outcome. Complaint normally records a spam complaint, but a suppression complaint subtype means SES accepted the request without attempting delivery. Reject means SES stopped processing content it identified as containing a virus. Rendering Failure means a templated message could not be rendered. DeliveryDelay records a temporary delivery issue and includes an expiration time for SES retries.
What Send confirms
- Acceptance: The SES API or SMTP send request succeeded.
- Message ID: SES assigned an identifier that can join the request to later events.
- Counting: SES can count the request as a send even when delivery is suppressed.
What Send does not confirm
- MX handoff: It does not prove the recipient mail server accepted the message.
- Inbox placement: It does not prove the message reached the inbox instead of spam or quarantine.
- Final outcome: It does not prove that a later delivery, bounce, rejection, or delay event was captured.
AWS documents delivery troubleshooting separately from Send acceptance. The SES delivery docs recommend confirming a successful SendEmail or SendRawEmail response, checking the Return-Path for bounce details, allowing for greylisting retries, and distinguishing recipient filtering from SES delivery.
Why messages stay Send-only
When a Send-only rate rises, separate telemetry gaps from messages that are still in progress. First ask whether every later event was selected on the configuration set and reached the destination. Then ask whether the event store joined those records to the same SES message ID and recipient.
|
|
|
|---|---|---|
Missing events | Later outcomes were not selected, published, or stored. | Audit destinations |
Broken joins | A later event exists but does not match the campaign record. | Join message IDs |
Active retry | SES is retrying a temporary delivery failure or internally deferring the message. | Inspect delays |
Suppression event missed | SES suppressed delivery, but the bounce or complaint outcome was not captured. | Check subtype |
Wrong scope | The query uses another Region, configuration set, or time window. | Verify scope |
Untracked terminal event | Reject or Rendering Failure was omitted from monitoring. | Enable all outcomes |
Common reasons AWS SES messages remain Send-only in reporting.
Suppression is worth checking, but it does not normally explain a missing outcome by itself. Global suppression produces a permanent Suppressed bounce. Account-level and tenant-level suppression use OnAccountSuppressionList and OnTenantSuppressionList in bounceSubType or complaintSubType, depending on the suppression reason. If SES email validation is enabled, also inspect EmailValidationSuppressed. A Send record without the matching outcome requires an event-routing and join audit. These fields are defined in the AWS event schema.
Amazon SES account suppression list for investigating Send-only delivery status.
Event collection often fails at a configuration boundary. Each SES event destination belongs to one configuration set, and the sending request must specify that set unless the verified identity has it as the default. A campaign can therefore publish Send events through one path while another path omits bounces, complaints, delays, rejections, or rendering failures. Destination delivery errors and warehouse filters can create the same symptom.
How to trace an SES message ID
Start with one campaign and build a recipient-level timeline. Do not begin with aggregate percentages. The same Send-only rate can come from one mailbox provider deferring mail, one omitted event type, or one broken destination. Recipient-level evidence shows which explanation fits.
AWS SES Send status investigation using message IDs, suppression checks, and delivery events.
- Confirm acceptance: Verify the SendEmail, SendRawEmail, or SMTP response succeeded and log the SES message ID.
- Pick a sample: Use a representative set of Send-only recipients from the same campaign, Region, and time window.
- Join by ID: Match the API response's MessageId to mail.messageId and the specific recipient; retain configuration set, campaign tag, and timestamps as context.
- Audit routing: Confirm the exact configuration set publishes Delivery, Bounce, Complaint, Reject, Rendering Failure, and DeliveryDelay events.
- Inspect outcomes: Read bounce or complaint subtype, diagnostic code, SMTP response, delay type, and expiration time.
- Check account state: Review account health, sending quotas, configuration-set pauses, and AWS Service Health for the Region.
- Group and test: Group unresolved messages by recipient domain, then send a seed through the same identity and configuration set.
Check the actual sending quota and sandbox status in the same Region. The SES sandbox permits verified recipients or simulator addresses, with limits of 200 messages per 24 hours and 1 message per second. Production quotas differ. Quota, sandbox, and paused-sending errors normally reject a new request; they do not prove that an already accepted message is queued.
Minimum SES event fields to preserveJSON
{ "eventType": "Send", "mail": { "messageId": "010001example", "timestamp": "2026-08-06T09:14:31Z", "source": "newsletter@example.com", "destination": ["user@example.net"], "tags": { "ses:configuration-set": ["marketing-prod"], "campaignId": ["winter-sendout-042"] } } }
Use mail.messageId rather than the original MIME Message-ID header. For multi-recipient requests, read delivery.recipients, bounce.bouncedRecipients, or deliveryDelay.delayedRecipients to determine which recipients an outcome covers. Also retain complaint.complainedRecipients; ordinary complaints can list candidate recipients when the provider redacts the complainant. When an SNS notification wraps the event, parse its Message payload first. Identity-level feedback uses notificationType instead of eventType, as described in the AWS event schema.
The AWS investigation guide covers templated rendering failures, suppression outcomes, reject events, and recipient-provider handling. Use those checks after confirming that the application received a successful SES response and that the relevant events were published. If no outcome appears after retry expiration and event ingestion has caught up, open an AWS Support case with the SES message IDs, UTC timestamps, affected recipients, Region, and raw event records.
For evidence about the current sending path, send a seed through the same identity, domain, and configuration set, then inspect it with Suped's email tester. Use the results to inspect SPF, DKIM, DMARC, and headers on that test message, then compare those findings with SES events for the affected recipients.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
The query below assumes one status row per SES message ID and recipient, with send_timestamp and terminal_event calculated from all matched events. Process repeated notifications without double-counting and retain every outcome regardless of arrival order. A late Send notification must not overwrite a Delivery or Bounce already stored.
Send-only domain grouping querySQL
SELECT recipient_domain, COUNT(*) AS send_only FROM ses_events WHERE campaign_id = 'winter-sendout-042' AND send_timestamp IS NOT NULL AND terminal_event IS NULL GROUP BY recipient_domain ORDER BY send_only DESC;
How to test SES event publishing
CloudWatch SES metrics show counts and rates; they do not provide the raw event record needed to trace one message. Keep an event-record destination such as Amazon SNS alongside metrics, as explained in the AWS CloudWatch documentation.
- In the SES console, open Configuration sets, select the set used by the application, and check Event destinations. Enable delivery, bounce, complaint, rejection, rendering failure, and delivery-delay events.
- Attach that set to the test request using ConfigurationSetName for the API or X-SES-CONFIGURATION-SET for SMTP. Reuse the affected Region, verified identity, and application sending path.
- For an SNS destination, verify the topic policy permits SES publishing and the endpoint subscription is confirmed. Check subscription filters and endpoint failures using the AWS SNS setup instructions.
- Send separate messages to the simulator addresses below. Match each returned SES message ID to the raw outcome, then confirm that the same outcome appears in the application report.
|
|
|---|---|
success@simulator.amazonses.com | Delivery |
bounce@simulator.amazonses.com | Permanent Bounce with SMTP 550 5.1.1 |
complaint@simulator.amazonses.com | Delivery followed by Complaint |
Controlled SES outcomes for testing event capture.
The AWS mailbox simulator works in the sandbox and does not consume daily sending quota or affect bounce and complaint reputation rates; the maximum sending rate still applies. If raw outcomes arrive but the dashboard stays Send-only, investigate ingestion and joins. If raw outcomes are absent, investigate publishing and destination delivery before testing real recipient providers.
How to locate an SES delivery delay
A message described as stuck can be delayed before SES, while SES is retrying, or after the recipient provider accepts it. Only the middle case can be a genuine unresolved Send state in SES. The timestamps and response fields identify the boundary.
|
|
|
|---|---|---|
Before SES | No successful response or SES message ID | Check the application queue, local MTA, SDK retries, and request logs. |
Inside the SES path | Send plus DeliveryDelay, with no terminal event yet | SES retries until delivery succeeds or the retry window expires. |
At the recipient MX | Delivery with smtpResponse and remoteMtaIp | The recipient server accepted the message, so SES delivery is complete. |
After MX acceptance | Delivery exists, but the recipient cannot find the message | Investigate spam placement, quarantine, mailbox rules, or provider processing. |
Evidence that locates an AWS SES email delay.
Inspect deliveryDelay.delayType and expirationTime. InternalFailure and SendingDeferral describe SES-side delays, so a delay is not always a recipient-server problem. For configuration sets with MaxDeliverySeconds specified, the AWS delivery options allow 5 minutes to 14 hours. Expiry of that custom window produces a CustomTimeoutExceeded bounce. Use the actual expiration time and allow for ingestion lag before declaring an outcome missing; resending during active retries risks duplicates.
A recipient SMTP 250 response inside a Delivery event proves the recipient mail server accepted the message. It does not prove inbox placement. At that point, the case is no longer Send-only troubleshooting.
How suppression changes the answer
Suppression lists prevent repeated sends to addresses associated with hard bounces or complaints. SES has a background global suppression list, Region-specific account-level lists, and tenant-level lists for multi-tenant sending. SES counts a suppressed request as Send, then publishes a bounce or complaint outcome according to the suppression reason when those events are configured and captured.
Do not remove every suppressed address and retry. Confirm the address is valid, identify the suppression reason, and correct the source of the hard bounce or complaint first. Check the effective account, tenant, and configuration-set settings: suppression applies when an enabled reason matches the stored reason. These controls require reliable bounce and complaint processing and list hygiene.
If a large share of a campaign maps to suppression event subtypes, investigate the associated hard bounces or complaints. If the dashboard shows only Send for those recipients, fix event capture before changing suppression settings.
- Hard bounces: Remove or quarantine an address after a confirmed permanent failure.
- Complaints: Stop sending to complainants and retain the event used to enforce that decision.
- Unsubscribes: Keep consent suppression separate from bounce suppression in your data model.
Global suppression
SES manages this list in the background. It cannot be queried or disabled, and entries can remain for up to 14 days after repeated hard bounces.
- Event: Permanent bounce with the Suppressed subtype.
- Impact: The send counts toward the daily quota and the account bounce rate.
Account-level suppression
Your account controls a separate list in each AWS Region. Addresses normally stay until removed; SES clears the list after 90 days with account sending paused. Configuration sets can override the account suppression reasons.
- Event: Bounce or Complaint with the OnAccountSuppressionList subtype, depending on the reason.
- Impact: The send uses daily quota but does not increase the SES reputation bounce or complaint rate.
The global list itself cannot be queried or disabled. With account-level suppression enabled, SES still attempts delivery to a globally listed address that is absent from your account list. Any resulting bounce counts toward your account bounce rate. Check the AWS account suppression rules before treating a global entry as a guaranteed block.
If SES sending is paused or under review, use the AWS sending review FAQs to check the account status and document the changes made to bounce handling, complaint processing, access controls, and sending practices.
Authentication and reputation checks around SES
A Send-only record does not identify an authentication problem. Recipient-side SPF, DKIM, or DMARC failures can cause delivery delays, bounces, or filtering after acceptance. Check authentication and reputation after the SES event path is complete, or sooner when diagnostic codes or a mailbox-provider pattern indicate throttling or filtering.
Suped's domain health check gives one view of DMARC, SPF, and DKIM before event-level analysis. For ongoing sending, DMARC monitoring shows which sources authenticate and where alignment fails. Add blocklist monitoring when domain or IP reputation on blocklists (blacklists) is part of the recipient-domain pattern.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
Suped is our DMARC reporting and email authentication platform. It complements SES event logs by showing DMARC source data, SPF and DKIM results, authentication alignment, and blocklist (blacklist) changes. It does not replace the SES message ID, bounce subtype, diagnostic code, or recipient SMTP response needed for a Send-only investigation.
Use Suped after grouping SES outcomes by sending identity and domain. Compare the affected time window with authentication failures or reputation alerts, then return to SES for the message-level delivery result. Use DMARC aggregate reports as grouped authentication evidence and SES events for individual delivery outcomes.
How to monitor SES delivery status
The durable fix is a more complete event model. Reporting should distinguish accepted, delivered, bounced, complained, delayed, rejected, rendering failed, suppressed, and unknown. If Send-only is the state left after processing, treat it as an investigation queue rather than a successful outcome.
- Store raw events: Keep unmodified SES records long enough to replay campaign processing.
- Track event age: Flag messages that remain Send-only beyond the normal retry or ingestion window.
- Preserve evidence: Store bounce and complaint subtypes, diagnostic codes, SMTP responses, remote MTA IP, and delay expiration.
- Segment domains: Break unresolved counts out by recipient domain and mailbox provider.
- Monitor destinations: Alert on delivery failures, disabled destinations, subscription problems, and ingestion lag.
- Record configuration: Keep the AWS Region, configuration set, identity, and campaign tags with every message.
A useful campaign report keeps Send-only as its own bucket with age, recipient domain, AWS Region, configuration set, event-destination status, and the latest matched event.
If recipients say messages are missing even when SES records Delivery, the investigation moves to inbox placement and recipient-provider handling. Check recipient SMTP evidence and placement when messages are not delivered through Amazon SES.
Views from the trenches
Best practices
Correlate each SES message ID with every later event before treating Send as a result.
Verify Region, configuration set, and event destination before checking suppression data.
Keep bounce, complaint, and unsubscribe controls separate in the recipient data model.
Common pitfalls
Assuming Send equals delivery hides active retries and event-publishing gaps in reports.
Treating suppression as Send-only misses bounce or complaint outcomes in SES event records.
Filtering DeliveryDelay events makes recipient throttling look like unexplained event loss.
Expert tips
Rebuild one campaign timeline from raw events before changing any SES sending settings.
Track unresolved messages by recipient domain to expose provider-specific deferrals.
Preserve SMTP responses and delay expiration times so each handoff remains auditable.
Marketer view
Marketer from Email Geeks says Send should be treated as SES acceptance, while delivery, bounce, and delay events describe subsequent processing.
2025-05-28 - Email Geeks
Marketer view
Marketer from Email Geeks says DeliveryDelay events matter because DNS, network, mailbox, or MX deferrals can leave messages unresolved for a period.
2025-05-28 - Email Geeks
