SES says sent. Outlook never got it.Separate acceptance from delivery before you buy a dedicated pool.

When the SES API or SMTP interface accepts a message, SES returns a MessageId. AWS documents that this success response identifies the request SES accepted, not the final mailbox placement. SES then assembles the message, scans it, and attempts SMTP delivery to the recipient's mail system.

Operators often read that MessageId as "delivered". Recipients read an empty Inbox and an empty Junk folder the same way: "it never arrived". Both can be describing different layers of the same send. The fix is to name the layer with evidence before you change IP strategy.

1. Confirm the MessageId for the exact recipient and send time.
2. Look up SES events for that MessageId: Send, RenderingFailure, Reject, Bounce, Complaint, Delivery.
3. If Bounce shows OnAccountSuppressionList, OnTenantSuppressionList or Suppressed, fix suppression before anything else.
4. If Delivery is present, SES handed the message to Microsoft's edge. Inbox placement is now a Microsoft-side question.
5. If the recipient is on a Microsoft 365 tenant, ask their admin for Message Trace on the Message-ID.
6. If the recipient is on consumer Outlook.com, Hotmail or Live, there is no sender-side Message Trace. Ask them to search Inbox, Junk, Deleted and Archive, then check SNDS for IPs you control.
7. Only after those steps consider a dedicated pool, and only when shared-IP reputation is the remaining hypothesis.

Yes. The AWS Messaging Blog's investigation guide splits missing mail into three zones: the application never reached SES, SES dropped the message after accepting it, or the recipient ISP accepted SMTP and still withheld inbox placement. Zone two is easy to miss because your code already received a MessageId. When the Bounce event shows suppression, start with Amazon SES Suppression List, Explained before you touch IP strategy.

Enable event publishing on a configuration set and attach it to the sends you care about. Without Send, Bounce, Complaint and Delivery events on the MessageId, you are guessing which zone failed.

No. In SES terms, Delivery means the recipient ISP's mail server accepted the message. Microsoft can still junk, quarantine, defer foldering, or drop mail under tenant policy after that SMTP accept. That is why operators see Delivery next to a recipient who still cannot find the message.

SendBunny lists transactional sends with delivery status and stores campaign per-recipient delivery status from SES. Hard bounces and complaints go on an account-wide suppression list that every send path enforces. That visibility stops where SES stops. It does not diagnose Microsoft placement, and it does not automate a fallback path when Outlook-family mail disappears after Delivery.

Authentication still matters. Microsoft's high-volume sender requirements for Outlook.com consumer addresses, enforced from 5 May 2025 for senders above about 5,000 messages a day to those domains, expect SPF, DKIM and a DMARC policy of at least p=none with alignment. Passing auth does not guarantee inbox placement. Failing auth can refuse or junk mail before you ever reach the "silent" case.

A dedicated IP removes noisy neighbors on a shared pool. It does not create Message Trace for consumer Outlook.com. It does not override a tenant quarantine. It does not repair a RenderingFailure. If SES already emitted Delivery and authentication passes, buying a dedicated pool is often a cost with no new diagnostic signal. Read Shared IP deliverability: why a stranger hurts you when the remaining hypothesis is neighbor reputation, not Microsoft placement.

• Dedicated pool is a reasonable next experiment when Delivery is missing or delayed only to Microsoft, shared-IP reputation is weak in SNDS, and Gmail or other ISPs are fine on the same content.
• Dedicated pool is the wrong next spend when Branch 2 events explain the miss, when tenant Message Trace shows quarantine or policy drops, or when only one consumer recipient is affected and everyone else on Outlook.com is fine.
• Warm-up still applies on SES dedicated IPs. An idle new IP can look as untrusted as the shared pool you left. Use Amazon SES Warm-Up: What Actually Needs Warming before you scale a new dedicated pool.

1. Save MessageId, recipient address, From domain, and send timestamp.
2. Confirm SPF, DKIM and DMARC alignment for the From domain on a message that did arrive somewhere, or via your DNS and SES identity setup.
3. Pull SES events for the MessageId. Write down the last event name.
4. Check account suppression and your application suppression for the recipient.
5. If Delivery exists, stop blaming the SES API success response.
6. Classify the recipient: Microsoft 365 tenant versus consumer Outlook.com family.
7. For tenants: request Message Trace. For consumers: folder search plus SNDS on IPs you own.
8. Only then decide among content or list hygiene, delist or reputation work, dedicated IP, or an external fallback you operate yourself.
9. Keep a parallel Monday check for Gmail with Gmail's 0.3% spam rate rule: what to check every Monday so one ISP's silence does not hide a broader reputation problem.

SendBunny is the product layer on your own Amazon SES: campaigns, lists, templates, a transactional API, a shared inbox, and an MCP server for AI agents, installed into your AWS account. It sends through your own SES at Amazon's price. $199 one time; optional updates are $99 a year. Campaigns and transactional sends expose SES-side delivery status. Suppression is account-wide across send paths. Webhooks can carry delivery, bounce, open and click events you configure in Settings. The broader product context sits on the Amazon SES email platform pillar.

It does not replace Microsoft Message Trace, SNDS or the delist portal. It does not infer why Outlook empty-foldered a message after Delivery. It is not for you if you need multi-provider failover built in, or if you will not run an AWS account.