Has anyone else seen Amazon SES emails going to Gmail Spam?

At this point, it is almost funny when even AWS’s own emails are landing in Gmail’s Spam folder. It clearly shows how bad the IP reputation problem has become. By allowing abusive senders to damage the same IP pools used by other customers, AWS is simply shooting itself in the foot.

I think it all has to do with auto-approvals and how certain individuals have learned to get them en masse.

Reading through the responses here, it sounds like the recommendation is to use a dedicated IP if you want more control over sender reputation. If that's the case, does that mean a new SES customer first has to get production access, then apply for a dedicated IP, and pay the additional cost just to have reasonable confidence that transactional emails (such as MFA codes or password resets) won't end up in spam?

That seems like a significant hurdle for organizations that are simply trying to send reliable transactional emails. I'd be interested to hear how others have handled this.

Is AWS officially acknowledging this as a known issue and actively working on improving shared IP reputation and deliverability, or is the current recommendation simply to move to dedicated IPs?

It would be helpful to know whether this is considered a temporary shared IP pool reputation issue or if customers should expect to address it by purchasing dedicated IPs. Moving to dedicated IPs also means additional costs—not only for the IPs themselves but also for the supporting infrastructure and ongoing management—so it would be useful to understand whether AWS expects this to be the long-term solution.

Yes, this is a known deliverability issue, and you're not alone in experiencing it.

The main problem with using Amazon SES on shared IP pools is precisely the issue that is described in those re:Post threads: if the other mail senders on the same shared IP range have bad sending practices or cause spam complaints, then the reputation of the whole pool is harmed. Since Gmail's filters place great importance on IP reputation, a deteriorated shared IP can cause even genuine and properly formatted emails to be sent to the Spam folder, no matter how good the content is.

A few things worth checking on your end:

If you're using SES for your own application:

• Move to a dedicated IP address to isolate your sending reputation from other SES users. AWS documentation on this: Amazon SES Dedicated IP Addresses
• Ensure DKIM, SPF, and DMARC are fully configured and passing. Gmail treats unauthenticated mail with increasing suspicion.
• Monitor your reputation through the SES Account Dashboard under Reputation Metrics.
• Keep bounce and complaint rates well below AWS recommended thresholds (bounces under 5%, complaints under 0.1%)

On the AWS account MFA emails specifically: That's worth reporting directly to AWS Support. If AWS's own transactional emails via SES are hitting Gmail Spam, that's a shared IP reputation problem AWS should be aware of and actively managing on their end.

The broader takeaway is that shared IPs on any ESP carry this risk. For production sending where deliverability matters, dedicated IPs combined with proper authentication are the most reliable long-term solution.

Email deliverability issues, including messages being filtered to spam folders, can occur for various reasons even when using Amazon SES. When emails don't arrive as expected or end up in spam folders, there are several factors to consider. Recipients' Internet Service Providers (ISPs), including email providers like Gmail, may filter messages based on their own spam detection algorithms and policies. It's worth verifying with the recipient or their email provider whether there have been any known delivery problems or filtering issues. Some ISPs also use techniques like greylisting to temporarily reject messages from unfamiliar sending mail servers as an anti-spam measure, though Amazon SES will retry delivery in these cases. Maintaining a positive sender reputation is crucial for ensuring email communications reach their intended audience. Even with best intentions, situations can arise that impact message deliverability. If you're experiencing persistent deliverability issues with your own SES usage and have a paid AWS Support Plan, you can open a technical support case and provide relevant details such as recipient addresses and message IDs from your SendEmail or SendRawEmail API responses. For general account-related email delivery concerns, you can add correspondence through the AWS Support Center.
Sources
Amazon SES Delivery problems - Amazon Simple Email Service
Amazon SES Delivery problems - Amazon Simple Email Service

i’ve had a similar concern with ses. if even aws-generated emails are ending up in gmail spam, it makes you wonder how much of this is related to shared ip reputation rather than the sender itself.

the dedicated ip option seems like the obvious workaround, but it’s a bit frustrating if a new customer has to get production access first and then pay extra just to have more control over deliverability.

i’d be interested to know if aws has any official guidance on this, esp. for transactional emails like mfa, password resets, etc. is improving shared ip reputation something they’re actively working on, or is the expectation that customers who need consistent delivery should use dedicated ips?