7 ms·

Tell HN: Gmail rate limiting emails from AWS SES

67 points by saradhi 3y ago

Unsure if this is the same for everyone but our notification emails from SES are being rate limited by Gmail. 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?

the_common_man 3y ago
Funny because Gmail is the biggest source of spam
- pixl97 3y ago
  Gmail is also one of the biggest email providers... it's almost like there is a correlation.
vladvasiliu 3y ago
>>> 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.
slau 3y ago
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 https://docs.aws.amazon.com/ses/latest/dg/dedicated-ip.html
jeroenhd 3y ago
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.
- baobabKoodaa 3y ago
  Google also silently drops mail in some cases.
  - jeffbee 3y ago
    Which cases?
    - betaby 3y ago
      Impossible to know. But in my cases from any IP with low volume. I.e. I have a bunch of personal servers for 10+ years, there are rarely outgoing emails from them and google happily just black-hole emails from such low volume IPs.
      - jeffbee 3y ago
        I'd be surprised if this was accurate. A low-volume IP might get a temporary failure code 4xx, but that's not silent. If they accept your message they intend to deliver it, or bounce it. Perhaps your return path is defective.
        alyandon 3y ago
        Google used to do this for low volume emails I was literally sending to myself by authenticating with my google smtp account credentials. I could find no rhyme or reason to it. It would claim to accept emails and they would never show up in my inbox or in spam. Sometimes they would get delivered to spam. Sometimes to my inbox like expected. It most often involved security log snippets which would include ip addresses and hostnames that were likely already on "is a known bad actor" list. Bug on their end? Intentional thing to disrupt spammers? I don't know.
topicseed 3y ago
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.
baobabKoodaa 3y ago
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.
- anamexis 3y ago
  Using SES is buying email delivery from a company who is in that business.
  - killerpixler 3y ago
    Disagree here. The sendgrid, mailchimp, postmark of the world are in the business of sending emails. They have their dedicated IPs and handle deliverability, anti spam, and whatnot with email providers like Gmail. 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.
    - anamexis 3y ago
      SES, like Mailchimp, Sendgrid, and Postmark, has dedicated IPs as a paid add-on.
      - baobabKoodaa 3y ago
        SES is not in the business of ensuring deliverability for your email. Dedicated ips is another hammer that they sell.
  - vbezhenar 3y ago
    If Amazon can't make it work, might just use good old postfix I guess. 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).
LeonM 3y ago
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.
- leetrout 3y ago
  Not entirely true. There is a reason Mailchimp owns a rather large block of IP addresses. https://ipinfo.io/AS14782 https://ipinfo.io/AS14782
  - LeonM 3y ago
    > Not entirely true 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.
kunwon1 3y ago
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-global-suppression-list.html https://docs.aws.amazon.com/ses/latest/dg/sending-email-glob...
- messutied 3y ago
  Would you happen to know of better alternatives for sending critical email notifications? We're just now working on moving away from Mailgun into SES. This thread is making me reconsider.
  - mprovost 3y ago
    "Critical" and "email" don't generally go together.
  - kunwon1 3y ago
    To echo the other reply, I don't rely on email for critical comms. 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
- johanneswu 3y ago
  You can now use a account-level suppression list to override the global suppression list though. > 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-subscriptions.html#3-suppression-overview https://docs.aws.amazon.com/ses/latest/dg/lists-and-subscrip...
johnklos 3y ago
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.
gog 3y ago
[flagged]
- 0ct4via 3y ago
  What an insightful and intelligent comment, that contributes incredible wealth to the current discourse, and doesn't minimize the seriousness of cancer at all - not. "Omit internet tropes" is pretty clear in the guidelines, and failing to make any kind of intelligent or reasoned argument adds nothing to the conversation here. Do better.
  - gog 3y ago
    I agree that my comment was not constructive, frustration got the better of me, I will work on that. You might want to look into your abrasive/patronizing tone used to deliver that message. Also, I don't agree that comparing Gmail to cancer is minimizing the seriousness of cancer, maybe you are just not seeing the damage to email as a decentralized platform Gmail is doing.
    - deleted 3y ago
      [deleted]
    - 0ct4via 3y ago
      Bold assumption of you, assuming a "patronizing tone" and what I am or aren't seeing -- by that logic, it would seem you "are just not seeing the damage cancer does" given your ridiculous comparison. Would you cry the same if Hotmail were the predominant platform? Regardless of that, it still wasn't constructive, and your "you might want to x" and "you're not seeing y" comments are much more patronizing than anything else - maybe consider not projecting so hard next time.
      - gog 3y ago
        Thank you for this, you made me laugh. I don't feel like giving in to my inner child so I will not engage any further in this shenanigans, I would just like to answer your question. I am not "crying", but I would be pissed of as well if Hotmail or anybody else was doing the same. This is not about being a predominant platform, but about hurting legitimate email senders to "combat spam" in a way where using their platform, or one of the big players, is the "safest" way to get your emails delivered in a timely manner and land in the recipients Inbox.
pembrook 3y ago
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.
- manishsharan 3y ago
  You are assuming that SES allows for spammers. In my experience, SES has pretty good controls , limits and policies to dissuade from spamming.
  - pembrook 3y ago
    Literally all ESPs and SMTP services have super strict anti-spam policies. The problem is it only takes 1 bad send to end up on a blacklist. 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.
    - jfengel 3y ago
      I'm a bit surprised that the spammers even bother with it, since it costs money and the conversion rates are near zero. I had the impression that most spammers would rather take over hacked accounts -- not quite zero cost, but pretty low.
- albert_e 3y ago
  Thanks 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.
ctas 3y ago
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 https://www.markix.com.
- cuu508 3y ago
  FYI: Your privacy policy is missing https://app.markix.com/privacy-policy https://app.markix.com/privacy-policy
jeffbee 3y ago
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.
bdcravens 3y ago
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.
hstaab 3y ago
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.
- erksa 3y ago
  For any critical email delivery make sure you can address this thing with the mailsender of choise: 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-white-labeling-hello-my-name-is/#chapter-1 https://www.mailgun.com/blog/deliverability/reverse-dns-whit... [2] https://dmarc.postmarkapp.com/ https://dmarc.postmarkapp.com/
  - joshstrange 3y ago
    And 1 surprising thing (to me) is some places (iCloud was what bit me) alway want you to be able to receive email (have MX records). Even though I have no need to support incoming emails iCloud was blocking my sending until I got that setup. The incoming emails just go to a black hole but that's enough.
- ctas 3y ago
  Shameless plug: I've recently started my own transactional email service (https://www.markix.com https://www.markix.com), primarily targeting small senders, after having been a very happy Postmark customer for a long time. Our service is still in closed beta but delivering live emails. 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).
ds 3y ago
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.
joshstrange 3y ago
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".
saradhi 3y ago
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.
- slau 3y ago
  Just make sure you have sufficient traffic to warrant a dedicated IP. An unknown IP suddenly sending a burst of emails is going to get soft-blocked very quickly. You need to build up your reputation, and you need to slowly increase how much you send. 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.
deleted 3y ago
[deleted]
ttul 3y ago
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.

67 points by saradhi 3y ago

the_common_man 3y ago

Funny because Gmail is the biggest source of spam

pixl97 3y ago
Gmail is also one of the biggest email providers... it's almost like there is a correlation.

vladvasiliu 3y ago

>>> 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.

slau 3y ago

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 https://docs.aws.amazon.com/ses/latest/dg/dedicated-ip.html

jeroenhd 3y ago

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.

baobabKoodaa 3y ago
Google also silently drops mail in some cases.
- jeffbee 3y ago
  Which cases?
  - betaby 3y ago
    Impossible to know. But in my cases from any IP with low volume. I.e. I have a bunch of personal servers for 10+ years, there are rarely outgoing emails from them and google happily just black-hole emails from such low volume IPs.
    - jeffbee 3y ago
      I'd be surprised if this was accurate. A low-volume IP might get a temporary failure code 4xx, but that's not silent. If they accept your message they intend to deliver it, or bounce it. Perhaps your return path is defective.
      - alyandon 3y ago
        Google used to do this for low volume emails I was literally sending to myself by authenticating with my google smtp account credentials. I could find no rhyme or reason to it. It would claim to accept emails and they would never show up in my inbox or in spam. Sometimes they would get delivered to spam. Sometimes to my inbox like expected. It most often involved security log snippets which would include ip addresses and hostnames that were likely already on "is a known bad actor" list. Bug on their end? Intentional thing to disrupt spammers? I don't know.

topicseed 3y ago

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.

baobabKoodaa 3y ago

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.

anamexis 3y ago
Using SES is buying email delivery from a company who is in that business.
- killerpixler 3y ago
  Disagree here. The sendgrid, mailchimp, postmark of the world are in the business of sending emails. They have their dedicated IPs and handle deliverability, anti spam, and whatnot with email providers like Gmail. 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.
  - anamexis 3y ago
    SES, like Mailchimp, Sendgrid, and Postmark, has dedicated IPs as a paid add-on.
    - baobabKoodaa 3y ago
      SES is not in the business of ensuring deliverability for your email. Dedicated ips is another hammer that they sell.
- vbezhenar 3y ago
  If Amazon can't make it work, might just use good old postfix I guess. 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).

LeonM 3y ago

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.

leetrout 3y ago
Not entirely true. There is a reason Mailchimp owns a rather large block of IP addresses. https://ipinfo.io/AS14782 https://ipinfo.io/AS14782
- LeonM 3y ago
  > Not entirely true 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.

kunwon1 3y ago

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-global-suppression-list.html https://docs.aws.amazon.com/ses/latest/dg/sending-email-glob...

messutied 3y ago
Would you happen to know of better alternatives for sending critical email notifications? We're just now working on moving away from Mailgun into SES. This thread is making me reconsider.
- mprovost 3y ago
  "Critical" and "email" don't generally go together.
- kunwon1 3y ago
  To echo the other reply, I don't rely on email for critical comms. 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
johanneswu 3y ago
You can now use a account-level suppression list to override the global suppression list though. > 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-subscriptions.html#3-suppression-overview https://docs.aws.amazon.com/ses/latest/dg/lists-and-subscrip...

johnklos 3y ago

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.

gog 3y ago

[flagged]

0ct4via 3y ago
What an insightful and intelligent comment, that contributes incredible wealth to the current discourse, and doesn't minimize the seriousness of cancer at all - not. "Omit internet tropes" is pretty clear in the guidelines, and failing to make any kind of intelligent or reasoned argument adds nothing to the conversation here. Do better.
- gog 3y ago
  I agree that my comment was not constructive, frustration got the better of me, I will work on that. You might want to look into your abrasive/patronizing tone used to deliver that message. Also, I don't agree that comparing Gmail to cancer is minimizing the seriousness of cancer, maybe you are just not seeing the damage to email as a decentralized platform Gmail is doing.
  - deleted 3y ago
    [deleted]
  - 0ct4via 3y ago
    Bold assumption of you, assuming a "patronizing tone" and what I am or aren't seeing -- by that logic, it would seem you "are just not seeing the damage cancer does" given your ridiculous comparison. Would you cry the same if Hotmail were the predominant platform? Regardless of that, it still wasn't constructive, and your "you might want to x" and "you're not seeing y" comments are much more patronizing than anything else - maybe consider not projecting so hard next time.
    - gog 3y ago
      Thank you for this, you made me laugh. I don't feel like giving in to my inner child so I will not engage any further in this shenanigans, I would just like to answer your question. I am not "crying", but I would be pissed of as well if Hotmail or anybody else was doing the same. This is not about being a predominant platform, but about hurting legitimate email senders to "combat spam" in a way where using their platform, or one of the big players, is the "safest" way to get your emails delivered in a timely manner and land in the recipients Inbox.

pembrook 3y ago

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.

manishsharan 3y ago
You are assuming that SES allows for spammers. In my experience, SES has pretty good controls , limits and policies to dissuade from spamming.
- pembrook 3y ago
  Literally all ESPs and SMTP services have super strict anti-spam policies. The problem is it only takes 1 bad send to end up on a blacklist. 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.
  - jfengel 3y ago
    I'm a bit surprised that the spammers even bother with it, since it costs money and the conversion rates are near zero. I had the impression that most spammers would rather take over hacked accounts -- not quite zero cost, but pretty low.
albert_e 3y ago
Thanks 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.

ctas 3y ago

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 https://www.markix.com.

cuu508 3y ago
FYI: Your privacy policy is missing https://app.markix.com/privacy-policy https://app.markix.com/privacy-policy

jeffbee 3y ago

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.

bdcravens 3y ago

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.

hstaab 3y ago

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.

erksa 3y ago
For any critical email delivery make sure you can address this thing with the mailsender of choise: 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-white-labeling-hello-my-name-is/#chapter-1 https://www.mailgun.com/blog/deliverability/reverse-dns-whit... [2] https://dmarc.postmarkapp.com/ https://dmarc.postmarkapp.com/
- joshstrange 3y ago
  And 1 surprising thing (to me) is some places (iCloud was what bit me) alway want you to be able to receive email (have MX records). Even though I have no need to support incoming emails iCloud was blocking my sending until I got that setup. The incoming emails just go to a black hole but that's enough.
ctas 3y ago
Shameless plug: I've recently started my own transactional email service (https://www.markix.com https://www.markix.com), primarily targeting small senders, after having been a very happy Postmark customer for a long time. Our service is still in closed beta but delivering live emails. 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).

ds 3y ago

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.

joshstrange 3y ago

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".

saradhi 3y ago

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.

slau 3y ago
Just make sure you have sufficient traffic to warrant a dedicated IP. An unknown IP suddenly sending a burst of emails is going to get soft-blocked very quickly. You need to build up your reputation, and you need to slowly increase how much you send. 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.

deleted 3y ago

[deleted]

ttul 3y ago

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.