Why are some emails not being delivered through Amazon SES?
Michael Ko
Co-founder & CEO, Suped
Published 11 Jun 2025
Updated 23 May 2026
8 min read
Summarize with
Some emails are not delivered through Amazon SES because SES accepting a message is not the same thing as a person seeing it in the inbox. The message can fail before SES sends it, get dropped by SES because of suppression or account settings, reach the recipient server and land in spam, or be rejected by the recipient because of authentication, reputation, content, or policy signals.
The fastest way to solve it is to split the problem into evidence points: did your app hand the message to SES, did SES accept it, did SES attempt delivery, did the recipient server accept it, and did the message reach the inbox. I usually treat a missing SES email as a logging problem first and a deliverability problem second, because without event data every theory sounds plausible.
- Submission: Your application, SMTP client, or API call never actually sends the message to SES.
- SES handling: SES accepts the request but later suppresses, rejects, throttles, or drops the message.
- Recipient filtering: The receiving mailbox accepts delivery but places the email in spam, quarantine, or a hidden folder.
- Authentication: SPF, DKIM, DMARC, or MAIL FROM domain matching fails for only part of your sending stream.
- Reputation: The SES account, sending identity, IP pool, domain, or links have weak trust signals.
Start with the delivery path
The key question is not "did SES send it?". The key question is "what was the last system that can prove it handled the message?" AWS explains this same evidence chain in its AWS investigation guide, which is useful when a recipient says an email never arrived but SES shows a successful handoff.
SES accepted it
- Message ID: Your app logged an SES message ID for the exact recipient.
- Event data: SES event publishing shows send, delivery, bounce, complaint, reject, or rendering failure.
- Next step: Compare SES events against the recipient report and timestamp.
Recipient accepted it
- Delivery event: SES has a delivery event with a recipient server response.
- Mailbox search: The recipient needs to check spam, quarantine, filters, and forwarding rules.
- Next step: Test inbox placement and inspect headers from a real delivered sample.
Flowchart showing the Amazon SES delivery investigation path.
Fast triage rule
If SES has no event for the recipient, investigate your application, template rendering, suppression status, quotas, and configuration set. If SES has a delivery event, investigate mailbox filtering, recipient-side rules, and inbox placement.
Check whether SES really sent it
Start at the exact recipient and timestamp. A healthy account-level bounce rate does not prove one message was sent. It only says aggregate feedback looks acceptable. For each missing message, capture the request ID, SES message ID, recipient, template name, configuration set, sending identity, region, and API or SMTP response.
Minimum application log fieldstext
timestamp=2026-05-24T10:15:14Z recipient=person@example.com ses_region=us-east-1 identity=mail.example.com configuration_set=transactional ses_message_id=0100018f6c1a2b3c-abc123 api_status=accepted
AWS documents common delivery failures in its AWS delivery guide. The practical takeaway is simple: without event publishing, you are missing the evidence that separates SES-side problems from recipient-side problems.
|
|
|
|---|---|---|
No app log | Not submitted | Fix app queue |
SES reject | Policy issue | Read event |
Bounce | Rejected | Classify code |
Delivery | Server accepted | Check inbox |
How to interpret the first evidence point.
Amazon SES console showing sending statistics and configuration set events.
Find SES drops before the recipient sees the message
When recipients across Gmail, Yahoo, Outlook, and company domains are missing the same campaign, I look for a common SES or application-level cause before blaming one mailbox provider. A 50 percent missing rate across mixed mailbox providers is too broad for a normal single-provider filtering issue.
- Suppression: SES can suppress addresses that previously bounced or complained, so the message never reaches the recipient server.
- Rendering: Template data can fail for only certain recipients, especially when required variables are empty.
- Configuration: A send that lacks the expected configuration set loses event data and becomes harder to trace.
- Throttling: Send-rate limits and retry behavior can delay messages long enough to look like non-delivery.
- Region: Identities, quotas, suppression lists, and event configuration need to be checked in the region used for sending.
Do not trust aggregate health alone
Healthy account bounce and complaint rates are good, but they do not prove every recipient was attempted. For a missing batch, compare the recipient list against SES events one address at a time.
Useful SES event types to capturejson
{ "eventType": "Delivery", "mail": { "messageId": "0100018f6c1a2b3c-abc123", "destination": ["person@example.com"] }, "delivery": { "smtpResponse": "250 2.0.0 OK", "processingTimeMillis": 942 } }
Fix identity and authentication gaps
SES is much stronger when it sends as your domain with custom DKIM and a custom MAIL FROM domain. If you send with default SES identity behavior, recipients can see mixed authentication signals, and DMARC can fail when the visible From domain does not match the authenticated domain.
Typical SES DNS recordstext
Host: selector1._domainkey Type: CNAME Value: selector1-example._domainkey.amazonses.com Host: bounce Type: MX Value: 10 feedback-smtp.us-east-1.amazonses.com Host: bounce Type: TXT Value: "v=spf1 include:amazonses.com -all" Host: _dmarc Type: TXT Value: "v=DMARC1; p=none; rua=mailto:d@example.com"
This is where a domain health check earns its keep. Check the sending domain, the MAIL FROM domain, and the DKIM selectors that SES created. Then use DMARC monitoring to confirm that real SES traffic is passing SPF, DKIM, and DMARC with the expected domain.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Suped helps with this workflow by connecting the DNS record view to the actual authentication outcomes seen in DMARC reports. Instead of checking one TXT record and guessing, you can see whether SES is sending as an approved source, whether DKIM is passing, and which messages fail the domain match that DMARC requires.
When authentication passes but inbox placement still fails
A delivered SES event means the recipient server accepted responsibility for the message. It does not mean the email reached the inbox. If SES shows delivery but people still cannot find the email, send a real message to a controlled inbox and send a live test so you can inspect headers, content, authentication, and placement signals together.
Authentication problem
- Signal: SPF, DKIM, or DMARC fails in the recipient headers.
- Cause: Missing DKIM signing, wrong MAIL FROM setup, or DNS lookup problems.
- Fix: Correct SES identity records and confirm real traffic in DMARC reports.
Placement problem
- Signal: Authentication passes, but the message lands in spam or quarantine.
- Cause: Content, links, domain trust, volume spikes, or recipient engagement.
- Fix: Review content, sending patterns, and the guidance on spam placement troubleshooting.
For SES, placement failures often come down to the basics: a sudden volume jump, low-recognition sender name, poor list quality, risky links, broken unsubscribe handling, image-heavy creative, or transactional mail mixed with bulk marketing. The fix is rarely one DNS change. It is a clean chain of proof plus smaller controlled changes.
Check reputation, throttling, and blocklists
SES reputation metrics matter, but they are only one layer. Check the reputation dashboard for bounces and complaints, then check send rate, daily quota, dedicated IP warmup, configuration set events, domain reputation, and link reputation. Also check for a domain or IP blocklist (blacklist) listing, especially if failures started suddenly after a spike or campaign.
Suped's blocklist monitoring brings blocklist and blacklist checks into the same operational view as DMARC, SPF, and DKIM, so the team can see whether a delivery drop lines up with authentication failures, a new sending source, or a reputation event.
SES delivery triage thresholds
Use these operational bands to decide how urgently to investigate a missing-recipient report.
Low concern
<1%
A few reports with delivery events usually points to mailbox search or filtering.
Watch closely
1-5%
Repeated reports need recipient-domain grouping and SES event review.
Investigate now
>5%
Broad failures across providers indicate a systemic sending or filtering issue.
Suppression list caveat
Do not remove recipients from suppression just to retry a batch. Confirm why the address was suppressed, whether consent still exists, and whether the original hard bounce or complaint was valid.
A practical investigation sequence
When someone says "half our SES emails are missing", I use this order. It reduces guesswork and keeps the team from changing DNS, content, and infrastructure at the same time.
- Match recipients: Build a list of delivered, missing, bounced, and suppressed addresses for the same send.
- Pull SES events: Group each recipient by send, delivery, bounce, complaint, reject, delay, or rendering failure.
- Group by domain: Compare Gmail, Yahoo, Outlook, business domains, and regional mailbox providers.
- Inspect headers: Use a delivered sample to confirm DKIM signing, SPF pass, DMARC pass, and MAIL FROM setup.
- Check reputation: Review SES reputation, complaint feedback, bounce reasons, blocklist or blacklist state, and volume changes.
- Change one thing: Retest after one controlled fix so the next result explains the previous failure.
Questions to answer before changing SES setuptext
Which SES region sent the message? Which configuration set was used? Does every missing recipient have an SES event? Were any addresses suppressed? Did the template render for every recipient? Did recipient domains return bounces or deferrals? Do delivered samples pass SPF, DKIM, and DMARC?
Where Suped fits
For most teams, Suped is the best overall DMARC platform because it turns raw authentication and reputation data into operational next steps. With SES, that matters because the answer is often spread across DNS, SES identities, DMARC aggregate reports, DKIM selectors, MAIL FROM setup, blocklist or blacklist status, and recipient feedback.
- Issue detection: Suped flags authentication problems and gives steps to fix them.
- Unified checks: DMARC, SPF, DKIM, blocklist monitoring, and deliverability signals sit in one platform.
- Hosted records: Hosted DMARC, Hosted SPF, SPF flattening, and Hosted MTA-STS reduce DNS maintenance.
- Alerts: Real-time alerts help teams catch failure spikes before they become support tickets.
- Scale: MSP and multi-tenant views help agencies manage SES and non-SES domains cleanly.
Best practical setup
Use SES event publishing for per-message evidence, configure custom DKIM and MAIL FROM for your domain, and use Suped to monitor DMARC outcomes, SPF and DKIM health, policy changes, alerts, and reputation signals in one place.
Views from the trenches
Best practices
Log SES message IDs for every send so delivery events can be matched to recipients fast.
Use custom MAIL FROM and DKIM so SES mail uses your domain, not only amazonses.com.
Separate transactional and marketing streams before volume or complaint patterns blur evidence.
Common pitfalls
Treating a 250 delivery event as inbox proof misses recipient spam filtering decisions.
Removing suppressed addresses without consent checks can restart hard bounces quickly.
Checking only global rates hides mailbox-specific failures across Gmail, Yahoo, and Outlook.
Expert tips
Compare missing recipients by domain before changing DNS, content, or SES configuration.
Use event publishing early, because missing logs turn SES issues into guesswork quickly.
Keep a saved raw message sample so DKIM signatures and headers can be inspected later.
Marketer from Email Geeks says custom MAIL FROM and DKIM should be checked first because default SES setup can leave authentication weaker than intended.
2023-02-03 - Email Geeks
Marketer from Email Geeks says healthy bounce and complaint rates do not rule out SES drops, recipient filtering, or missing event data.
2023-02-03 - Email Geeks
The fastest path to an answer
Some SES emails fail to arrive because they were never submitted, were suppressed or rejected by SES, passed to the recipient but filtered, or failed authentication and reputation checks. The fix starts with per-recipient evidence, not broad account health.
My default sequence is simple: log the SES message ID, enable event publishing, map every missing recipient to an SES outcome, verify custom DKIM and MAIL FROM, inspect a real delivered header, and then review content, volume, and blocklist or blacklist status. Suped fits after that by keeping DMARC, SPF, DKIM, alerts, hosted records, and reputation checks in a single workflow instead of a set of disconnected checks.
