Why do AWS SES emails get stuck in Send status and how can this be investigated?
Matthew Whittaker
Co-founder & CTO, Suped
Published 19 Jun 2025
Updated 27 May 2026
9 min read
Summarize with
An AWS SES email that only has a Send event is not proven delivered. It means SES accepted the send request and intended to attempt delivery. If a large share of a campaign stays in Send with no later Delivery, Bounce, Complaint, or DeliveryDelay event, investigate suppression first, then event capture, then queueing and recipient-domain deferrals.
I treat Send as a handoff state, not a final state. For a few isolated recipients it can be normal noise. For 20-30% of a sendout, it is a real signal. The most common explanations are suppressed recipients, missing or filtered event destinations, recipient-side temporary failures, or account-level sending controls.
Direct answer: a Send event means SES accepted the message. A message can remain Send-only in your reporting when delivery was suppressed, later events were not captured, the message is still retrying after a temporary failure, or the send never reached the recipient MX for another SES-controlled reason.
- First check: Compare Send-only recipients with account-level and global suppression behavior.
- Second check: Confirm every SES event type is being routed, stored, and counted.
- Third check: Group Send-only recipients by mailbox provider and domain to find deferrals.
What Send means in AWS SES
SES event names are easy to misread because Send sounds like a completed action. In practice, it means the request passed SES validation at that point. SES accepted the message into its sending process. It does not mean the recipient server accepted it, the inbox provider placed it in the inbox, or the recipient saw it.
The next event should normally tell you the outcome. Delivery means the recipient mail server accepted the message. Bounce means SES received a failure. Complaint means a spam complaint was reported. DeliveryDelay means SES saw a temporary delivery issue, such as recipient throttling, a full mailbox, or a transient DNS or network problem.
What Send confirms
- Acceptance: SES accepted the API or SMTP send request.
- Initial validation: The sender identity, region, and request format passed enough checks to enter SES.
- Counting: SES can count the request as a send even when delivery is later 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.
- Recipient eligibility: It does not prove the address escaped SES suppression handling.
AWS describes delivery troubleshooting separately from Send acceptance. The SES delivery docs are useful when your data shows SES accepted the message but recipients still report non-receipt.
Why messages stay Send-only
When I see a high Send-only rate, I separate the problem into two questions. First, did SES suppress or hold the message before a recipient MX conversation? Second, did a later event happen but disappear because of routing, filtering, retention, or reporting logic?
|
|
|
|---|---|---|
Suppression | SES accepted the request but did not deliver to that recipient. | Compare recipients |
Missing events | Later outcomes are not reaching your analytics store. | Audit destinations |
Temporary failure | A recipient domain deferred delivery or had transient failures. | Find delays |
Account controls | Sending is paused, reviewed, or constrained at account level. | Check quotas |
Provider filtering | The MX accepted mail but placed it outside the inbox. | Test inboxing |
Common reasons AWS SES messages remain Send-only in reporting.
Suppression is the first place to look because SES can count a message as sent even when it suppresses delivery. That behavior is easy to miss when your dashboard treats Send as the first step in a normal event sequence. If your historical sending created a lot of hard bounces or complaint-related failures, a large suppressed segment is believable.
Amazon SES console showing suppression list investigation.
The second common cause is simpler: the events exist, but your pipeline drops them. This happens when configuration sets differ by campaign, only some event types are selected, SNS subscriptions fail, Firehose delivery errors are ignored, or a warehouse query filters out events with different schemas.
How to investigate the exact messages
Start with one campaign and build a recipient-level timeline. Do not begin with aggregate percentages. A Send-only rate of 25% can come from one mailbox provider deferring mail, one stale segment full of suppressed recipients, or one broken event destination. The aggregate hides which of those is true.
Flowchart for investigating AWS SES Send-only events.
- Pick a sample: Take at least 500 Send-only recipients across the same campaign and region.
- Join by ID: Use SES message ID, campaign ID, recipient, configuration set, and timestamp.
- Check suppression: Compare recipients with your account suppression data and suppression settings.
- Audit routing: Verify all event types are enabled for the exact configuration set used.
- Group by domain: Sort Send-only recipients by Gmail, Microsoft, Yahoo, and long-tail domains.
- Send a test: Send a real message through the same SES identity and inspect headers, authentication, and placement.
Minimum SES event fields to preserveJSON
{ "eventType": "Send", "mail": { "messageId": "010001example", "timestamp": "2026-05-28T09:14:31Z", "source": "newsletter@example.com", "destination": ["user@example.net"] }, "configurationSet": "marketing-prod", "campaignId": "spring-sendout-042" }
AWS has a useful AWS investigation guide for cases where SES says the message was sent but the recipient never receives it. I use that style of investigation after I have already ruled out suppression and event routing gaps.
For live evidence, send a seed message through the same identity, domain, and configuration set, then inspect it with an email tester. This does not prove what happened to every past recipient, but it quickly shows whether SPF, DKIM, DMARC, headers, and obvious placement signals are healthy for the current path.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
Send-only domain grouping querySQL
SELECT recipient_domain, COUNT(*) AS send_only FROM ses_events WHERE campaign_id = 'spring-sendout-042' AND first_event = 'Send' AND terminal_event IS NULL GROUP BY recipient_domain ORDER BY send_only DESC;
How suppression changes the answer
Suppression lists exist because repeatedly sending to addresses that hard bounce or complain damages sender reputation. In SES, there is global suppression behavior and account-level suppression behavior. If recipients are suppressed, your application can see a Send event without a normal downstream delivery result in the way your campaign system expects.
That does not mean you should simply remove every address and retry. A suppressed address often ended up there because it was permanently undeliverable, complained, or was associated with poor sending history. Moving to account-level suppression gives you more control, but it also makes your bounce and complaint processing more important.
If 20-30% of a campaign maps to suppressed recipients, treat that as a list hygiene problem before treating it as an SES reporting bug.
- Hard bounces: Remove or quarantine addresses after a confirmed permanent failure.
- Complaints: Stop sending to complainants immediately and keep the evidence.
- Unsubscribes: Keep unsubscribe suppression separate from bounce suppression.
Global suppression
SES protects sending systems from addresses known to cause serious delivery problems across AWS sending. It reduces risk, but it gives you less recipient-level context.
- Best for: Teams without mature bounce handling.
- Risk: Your reporting can look incomplete if you expect terminal events.
Account-level suppression
Your account controls the list and the operational rules. It gives you clearer ownership, but bad bounce logic damages reputation faster.
- Best for: Teams with reliable bounce, complaint, and unsubscribe processing.
- Risk: Bad addresses re-enter campaigns if hygiene rules are weak.
If SES sending is paused or under review, use the AWS sending review FAQs to confirm what AWS expects from your bounce, complaint, and sending practices.
Authentication and reputation checks around SES
Authentication problems do not usually explain a pure Send-only event on their own. They explain what happens after the recipient system sees the message. Still, I check SPF, DKIM, DMARC, and reputation in the same investigation because they decide whether accepted mail lands in the inbox, spam, quarantine, or a provider-specific hold.
A quick domain health check is useful when you need one view of DMARC, SPF, and DKIM before digging into event-level data. If you are running AWS SES at scale, ongoing DMARC monitoring gives you source-level visibility into authenticated and unauthenticated streams. Add blocklist monitoring when you need to watch domain and IP reputation across major blocklists (blacklists).
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
This is where Suped fits into the workflow. Suped is our DMARC reporting and email authentication platform. It does not replace SES event logs, but it gives the surrounding authentication and reputation context that SES does not try to own: DMARC policy monitoring, SPF and DKIM visibility, hosted SPF, SPF flattening, hosted MTA-STS, real-time alerts, issue detection, blocklist (blacklist) monitoring, and a multi-tenant dashboard for MSPs.
For most teams, Suped is the best overall DMARC platform when SES is one of several senders, because the practical problem is not just one SES event field. The problem is proving which services are authorized, which ones pass alignment, which ones break after DNS changes, and which issues need action today.
What to change in your monitoring
The fix is rarely one setting. The durable fix is a better event model. Your reporting should distinguish accepted, delivered, bounced, complained, delayed, suppressed, rejected, and unknown. If Send-only is the only state left after your processing runs, it should be treated as an investigation queue, not a successful send.
- Store raw events: Keep unmodified SES events long enough to reprocess a campaign.
- Track terminal state: Separate first event, latest event, and final known outcome.
- Measure age: Flag messages that remain Send-only after your normal delivery window.
- Segment domains: Break Send-only counts out by recipient domain and mailbox provider.
- Add reason codes: Mark suppression, delay, routing gap, and unknown as separate states.
A useful campaign report does not collapse everything into sent, delivered, and failed. It shows Send-only as its own bucket with age, recipient domain, configuration set, and suppression comparison.
If recipients say messages are missing even when SES reports a successful delivery, the investigation moves into inbox placement and provider handling. The related cases not delivered through Amazon SES and ESP reports delivery need a different evidence set than Send-only troubleshooting.
Views from the trenches
Best practices
Correlate SES message IDs with every downstream event before treating Send as final.
Compare Send-only recipients against suppression data before changing SES account settings.
Keep bounce, complaint, and unsubscribe handling separate, but review them in one workflow.
Common pitfalls
Assuming Send equals delivery hides suppression, queueing, and event routing gaps in reports.
Switching off global suppression without strict bounce rules sends to bad addresses again.
Filtering out DeliveryDelay events makes recipient-side throttling look like missing data.
Expert tips
Sample raw events for one campaign and rebuild the recipient timeline before changing SES.
Track Send-only rates by recipient domain so Gmail, Microsoft, and Yahoo issues separate.
Use DMARC, SPF, DKIM, and blocklist signals to rule out reputation causes early.
Marketer from Email Geeks says Send should be treated as SES acceptance, while later delivery, bounce, delay, or timeout events prove the final outcome.
2025-05-28 - Email Geeks
Marketer from Email Geeks says DeliveryDelay events are worth checking because transient DNS, network, mailbox, or MX deferrals can leave messages unresolved for a period.
2025-05-28 - Email Geeks
The practical answer
AWS SES emails get stuck in Send status when your reporting has SES acceptance but no later outcome. The most important first check is suppression, especially when the Send-only share is large. After that, audit your SES event destinations and query logic, then look for domain-level delivery delays and recipient provider behavior.
A good investigation ends with a new state model, not just a one-time answer. Keep Send-only separate, age it, group it by domain, compare it with suppression data, and monitor authentication and reputation around SES. That gives you a repeatable way to tell whether the issue is SES handling, your event pipeline, your recipient list, or inbox provider behavior.
