Consistent ~30s delivery delay to Microsoft/Outlook recipients despite fast SES Send-to-Delivery time

The 30-40 second delay you're experiencing between SES delivery confirmation and inbox arrival at Microsoft/Outlook is occurring on the recipient's side, not within Amazon SES. Your SES metrics confirm this: the email was accepted by Outlook's mail server in just 3.4 seconds (as shown by the '250 2.6.0 Queued mail for delivery' SMTP response), which means SES completed its job successfully and quickly.

What you're observing is the recipient ISP's internal processing time. After Microsoft's mail server accepts the message from SES, it performs its own filtering, scanning, and routing before placing the email in the recipient's inbox. This additional processing by the receiving mail server is outside of Amazon SES's control and visibility.

Some ISPs, including Microsoft, may temporarily delay messages as part of their spam prevention measures—a practice called greylisting. They might also apply additional scrutiny to messages from certain sending patterns or IP addresses. The fact that this delay is consistent and specific to Microsoft recipients suggests their mail servers are applying extra processing to your messages.

To address this, focus on maintaining a positive sender reputation. Ensure you're sending high-quality content to recipients who expect and want your emails. Monitor your bounce and complaint rates, as excessive rates can negatively impact your reputation with receiving ISPs. You may also want to contact Microsoft directly or check with them about any delivery patterns they're observing from your sending domain.

If you have a paid AWS Support plan, you can open a technical support case and provide the relevant recipient addresses and message IDs from your SendEmail responses for further investigation.
Sources
Amazon SES Delivery problems - Amazon Simple Email Service
Amazon SES Delivery problems - Amazon Simple Email Service

I believed base on the result shows a fast handoff to Microsoft SMTP servers (≈3 s), but the extra 30–40 s lag is happening after Outlook accepts the message. That delay is pretty suspected to Microsoft side, not AWS.

https://docs.aws.amazon.com/pinpoint/latest/userguide/welcome.html

https://docs.aws.amazon.com/ses/latest/dg/best-practices.html

Honestly, I’d stop wasting time debugging around SES and move to another provider. Between the shared-IP reputation mess, spam-heavy ecosystem, and random delivery behavior, you can do everything right and still sit there wondering where the email went.

For OTPs especially, I’d rather pay another provider than watch SES deliver the code after it’s already expired