Things like this are to be expected with shared IP addresses for mail services.

This sounds like something Amazon should figure out more than anything. There's probably something going on with a customer or theirs (misconfiguration, spammer, vulnerability exploited) that's triggering spam detection rules.

At least Google reports the issue back to you instead of silently dropping all of your email like many other mail servers do.

Email sending is a largely efficient market, and SES is the cheapest sender.

Thus, the SES IP pools have the worst IP reputations among all the SMTP-based senders. I would never use them (or an ESP that sends with them) in a million years.

The reason why cheap = bad in email is because Spammers have the lowest conversion rates of all senders (their emails are always untargeted), so price is their number 1 consideration.

You can cheap out elsewhere in your stack. But never cheap out on email — especially if you’re not sending high volume enough for a dedicated IP.

It sounds like you could benefit from having your own dedicated IP pool in SES.

https://docs.aws.amazon.com/ses/latest/dg/dedicated-ip.html

Amazon SES is not a good choice for sending critical email notifications. Their 'global suppression list' [1] has caused no end of headaches for me and my clients.

If you and I are both using SES to send to the same person, and my message results in a hard bounce, then your messages to that person will start to silently fail.

[1] https://docs.aws.amazon.com/ses/latest/dg/sending-email-glob...

Thanks you all for comments. I have made a decision to subscribed to dedicated IPs (credits: @slau).

The differentiating factor between our current AWS SES plan and the competitors (mentioned in the comments) is having a dedicated IP. With our current volume, none of the competitors are anyway near AWS SES costs. So, moving to a dedicated IPs thats cost 25$ extra not only solves our issue, but also no change in code/infrastructure.

Hey everyone, CEO of MailChannels here. I've been following this thread with interest, as we've also observed similar challenges in the email delivery space. Well, to be honest, the ground game is constantly changing in this space as everyone has scaled.

Email delivery is inherently complex due to the various factors that contribute to deliverability, including IP reputation, domain reputation, content filtering, and recipient engagement. Shared IP pools can indeed be challenging because of the "bad neighbor" effect, where one sender's bad behavior can affect the reputation of all senders using that IP.

However, shared pools can also prove advantageous because it's harder for a receiver to block your IP if tons of email comes from it from a wide variety of senders. Receivers are trying to reduce collateral damage while protecting their users from spam and phishing - this is literally the reward model feeding their machine learning models. If your email travels alongside millions of other emails that are mostly received well, that IP will not be blocked; whereas, if you send email from your own IP, it doesn't take much for a receiver to pull the trigger and block you since there is very little consequence other than blocking your traffic.

Not that anyone here asked, but if you want a "best practice", try multiple different services and approaches and find the one that works best for you. There is no perfect email sending service for all senders and as mentioned above, the ground game is changing all the time.

This is typically not a big deal, as explained in the message, it is a temporary countermeasure. It'll resolve itself as long as you really aren't spamming.

Though Gmail responds citing your IP, Gmail and all other large email services don't use IP filtering. Just about all email service providers use domain reputation, since IPs are ephemeral.

If you are sending transactional emails that your customers have agreed to, then your domain (!= ip) rating will improve over time and there will be less countermeasures, regardless of which IP you use to send.

> Is anyone facing the same issue with AWS? or similar issues with other bulk email service providers?

This is just Gmail doing it's thing (the right thing, in my opinion, contrary to most HN sentiment). It is independent of which sender you use.

> How do you deal with such issues in the future? Set up alternative email service providers.

Use DMARC reporting to verify that all your email is sent with DKIM alignment, to make sure that you aren't causing the problem. This is independent of email service provider.

But as explained, you are being rate limited, not blocked. Email will be delivered, it'll just take longer. You state that you have a 60-90 day margin for delivery, so I wouldn't worry about it too much.

> Is this the side effect of Gmail's dormant account deletion rolled out last week?

No.

I'm currently using PostmarkApp (from before the acquisition) but I've looked longingly at SES for years. My traffic is very bursty and so ~8 months out of the year I pay the monthly cost and send 1-2 emails if that and then the other 3 months I send close to my plan max. I'd love to switch to a pay-per-use provider but stories like this scare me. I've already dealt with deliverability issues (iCloud randomly deciding that unless you can receive emails, have the MX records in place, they will block you. This was for transactional/login/notification emails), since email is the login method for my sites it's rather important that it works. To PostmarkApp's credit they helped me to track down why the emails were bouncing to iCloud, I doubt I would have gotten the same support from AWS (I'm too small of a fish).

I'd love to hear what other people are using to send transactional emails (no marketing). Ideally I'd find a provider that could "scale down to $0".

If you are not in the business of selling email delivery, you should be buying email delivery from a company who is in that business. It's extremely hard to get emails delivered and it's even harder for a small company. For your use case you could probably use Postmark and get good delivery with that.

I think this is a spammy neighbour problem on that sending IP. Might be you, might be someone else who's using SES. But whoever sends from this IP is penalised.

Do you have a custom return-path configured? Using a custom return path might help, because it ties your reputation primarily to your domain.

ESPs check multiple factors. Both IP and domain reputation play a role. They will check your return path / envelope sender domain reputation and your IP. Your domain will start with it's own reputation, but can be boosted with a good IP reputation. But if your domain had bad sending behaviour in the past, that might be an issue.

Source: I'm running a transactional mail service that solely works with shared IPs: https://www.markix.com.

Amazon is very, very spammy. If you want your email to be delivered and you don't want to end up sharing Amazon's reputation, you'll need to use another company for email delivery.

>>> Is this the side effect of Gmail's dormant account deletion rolled out last week?

IIRC, they haven't started to actually close the accounts just yet, so I doubt it's related.

We are always trying to trim waste to stay lean, and the SES vs Sendgrid pricing looks nice on paper (we are on the Sendgrid Pro plan with the dedicated IP address, so it's $90/mo). However when I look at our Sendgrid stats (97% reputation; it's pretty much all transactional) I know it's worth well more than what we'd save.

Why does a 4xx even come to your attention? Admittedly I never looked into what SES is or how it works, but I assumed it stores and forwards messages on behalf of its users, in which case a 4xx temporary failure to send should not come back to you.

For those recommending against SES for critical deliveries, what are you using?

In the recent past I’ve used Postmark, but they were acquired by a marketing company.

Funny because Gmail is the biggest source of spam

[flagged]

I tried to use cloudflare email routing and had the same issue. I simply set it up so any email to @mydomain.com would forward to a gmail.

The worst is that cloudflare did not let me know this was happening until I saw I was missing some emails and went hunting. About 20% of my emails would just get rejected silently with "delivery failed" in the logs. I wouldnt blame cloudflare so much if they kept attempting to redeliver, but they did not. They simply give up.