Background:
One of my apps provides time-sensitive email notifications, for 60-90 days, to the subscribers(paid) - so it is critical to deliver emails. We have been using the same email provider and have been using AWS SES for a couple of years now. We have the SPF, and DKIM all verified. Yet, for the last 3 days, we are getting the below email
```
Sub: Delivery Status Notification (Failure)
Body: Our system has detected an unusual rate of<CRLF>421-4.7.28 unsolicited mail originating from your IP address. To protect our<CRLF>421-4.7.28 users from spam, mail sent from your IP address has been temporarily<CRLF>421-4.7.28 rate limited. Please visit<CRLF>421-4.7.28 https://support.google.com/mail/?p=UnsolicitedRateLimitError to<CRLF>421 4.7.28 review our Bulk Email Senders Guidelines.>
```
Troubleshooting till now: I have got the AWS tech support team confirming my email configuration has no issues. AWS team has informed "The current throttling is just that Gmail is seeing a lot of messages from the SES shared IP and is throttling the messages"
>>> Is anyone facing the same issue with AWS? or similar issues with other bulk email service providers?
>>> How do you deal with such issues in the future? Set up alternative email service providers.
>>> Is this the side effect of Gmail's dormant account deletion rolled out last week?
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.
Checking out the pricing page, a dedicated IP costs $24.95 per month, which would be more than the actual cost of emails for many small-medium apps (e.g. 100K emails per month would be about $10).
Ooc, do other email providers have the same shared-IP problem? E.g. Mailgun, Postmark, Sendgrid?
Yes, that is why they let people get a dedicated IP pools and FCrDNS using their corporation name for a price. It is not uncommon for the shared IP pools to get rate limits, temporary blocks, etc... and the corporation specific dedicated IP's are more likely to get through especially if they handle UCE complaints properly.
But everyone else doesn't really care much.
I had to help multiple customers who had access to SES shut off for valid use cases because they didn't handle events coming back from customers appropriately.
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.
I never had to use SES or really Email for that matter in my own architecture.
Since we get so immersed in best practices and recommendations of good architecture pushed by these very cloud providers (AWS, Azure, etc) -- this kind of candid information is usually not available unless we burn our fingers and learn through own experience.
I wish there was more efficient way of such practical knowledge to be shared among practitioners. Current discussion forums etc work to an extent but just hope there was much more effective way to spread awsreness.
...are deliberately designed to mix several actual best pracices and a lot of marketing so that it's difficult to discern what is what.
SES is the best among the provider.
They treat spam very seriously, compare to other. You would need to maintain a baseline, failure to do so will get the account into soft-susspend or permanent suspended quickly.
AWS, being an engineering focus product, provider tooling and automated around bouncing, spam reporting handling. Having sophisicated tooling help user deal with that.
They strongly againtst and not suggest end-user to buy dedicated IP. Where as other providers always want user to pay more for "dedicated ip" to "get better delivery".
AWS has procedure, best practice to encounrage slowly warmup when sending mass volume. They had their own rate limit (14 messages per second by default), move the account out of sandbox, a good domain/sender verification.
They are the best among providers when it comes to email.
Sometimes they appear to be worst than others, but that is a specific case. The way email works will always have false positive. If user decided the email is spam(even it isn't) and keep reporting it may appear in a certain spam list.
Email delivery is a commodity business at this point, hence why there's so many PE rollups in the space.
The fact of the matter is it only takes 1 bad send to end up on a blacklist, and SES is the cheapest so it will always be the most attractive target for spammers/fraudsters.
Am I correct that maybe you run a Saas built off SES and might have incentive to defend?
The cheapest service will always get the most attempts from spammers. You can try to detect them before they send, but the only way you know for sure that they're a spammer, is after they've already sent spam using your platform.
But I'd just go with whatever sender isn't the cheapest and has the founders still intimately involved in the product. Stopping spammers is ultimately still a human game. Postmark used to be my go-to, but they sold, and I'd bet my entire salary that within a few years that service will end up like all the others that have been bought-and-sold.
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...
> If an address is on the global suppression list, but not on your account level suppression list (which means you want to send to it), and you do send to it, Amazon SES will still attempt delivery, but if it bounces, the bounce will affect your own reputation
[1] https://docs.aws.amazon.com/ses/latest/dg/lists-and-subscrip...
If I had to rely on email for critical comms, I would use a product that lets me see the SMTP logs, and alert on failures. I would have some backup provider that I could then quickly shift to
But I'm still an on-prem email administrator, so my entire paradigm is pretty much obsolete. I may not be the best source of info in this space
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.
The managed IP is an option, although I’ve never used it.
When I was the VPoE at Dixa, we switched over to SES, and we had 3 dedicated IPs, and for our volume back then (a few thousand emails a day), this worked very well. I don’t know if they ever hit scaling issues after I left.
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.
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.
OK you are right, Gmail may use IP-based rating, but it only does that if there isn't sufficient proof (in form of DKIM signatures) that the email is sent on behalf of the domain. If the email is DKIM aligned, then domain rating is used. I just didn't want to go that far into detail in my post.
> There is a reason Mailchimp owns a rather large block of IP addresses.
The reason is mostly for supporting smaller/legacy/self-hosted email services that do rely on IP reputation. Since Mailchimp won't allow customers to bulk email unless they have DKIM set up correctly, they don't have to worry as much about IP spreading with the major email service providers.
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".
SES is an email sending infrastructure tool. That's not the same.
IMO equating SES with an email company is like saying home depot is a contractor because they sell hammers and lumber. It gives you the tools to be able to build stuff but it's not the same as a construction company.
My anecdotal evidence is that simple postfix setup with IP from a reputable hoster which is not blacklisted works perfectly. And it's actually pretty simple to configure postfix for sending mail (now configuring postfix + dovecot + auth + spam filtering is another story).
OP is doing just that, Amazon SES = Simple Email Service
If SES isn't delivering some stuff, Amazon will link to a page and say "here is why, good luck" and that's the end of the support ticket.
If you look at AWS pages for SES, nowhere on their pages do they market email deliverability. That's not the service they sell.
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.
IIRC, they haven't started to actually close the accounts just yet, so I doubt it's related.
In the recent past I’ve used Postmark, but they were acquired by a marketing company.
1)SPF,
2)DKIM,
3)DMARC [2] (DMARC is often forgotten or can be super noisy when set up. Postmarc offers a aggregation service for free that sends you a weekly summary),
4)Dedicated IP
5)Reverse IP look up [1] (locate a dns PTR record for that IP address) should match the sender.
Not everyone supports 5).
4 and 5 is what you end up paying for, but totally worth it. Sendgrid, SES, Mailgun etc.
[1] https://www.mailgun.com/blog/deliverability/reverse-dns-whit...
I run a couple other businesses and moved all of my transactional email sending over to Markix.
Would love to have a chat with anyone that might be starting a new project and is open to try out a new mail service (mail in bio).
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.
