Due to an unexpected service interruption, I've recently had to evaluate numerous options for SMTP services, to replace a one that was showing signs of performance degradation. The AWS SES is an obvious choice, but what if it is not available, or your organization requires diversifying to other providers? Below is a quick list of contenders that I have compiled, with my comments on each. 

The requirement for me is that the successful SMTP service has to integrate with a number of applications for email sending: drupal, wordpress, and ruby on rails. It should provide me with a username + password to be able to send emails via SMTP protocol. This bar for success is low: there are many services that provide this capability. Below is a short list.

Postal

A complicated self-hosted solution. To use it, you will need to configer DNS records, a dockerized app, and databases, to name a few presequisites. This solution allows you to own your own sending capability entirely.

Currently reviewing... Looks great! Despite complexity.

mailcow.email

A complicated self-hosted solution. To use it, you will need to configer DNS records, a dockerized app, and databases, to name a few presequisites. This solution allows you to own your own sending capability entirely.

smtp.com

At $25/mo for 50,000 emails/mo, they are a contender to AWS SES. This is not the cheapest service: the minimum they charge is $25/mo.

smtp2go.com

Free for <1000 monthly emails, and minimum $15/mo. 

mailtrap.io

$15/mo for 10000 emails, and you can have 1000/mo for free.

Unfortunately, I must remove this provider from the list of providers I can trust, or endorse. The reason being as follows. As you may have guessed, I maintain my own email infrastructure (and it, and all my other infrastructure, is increasingly more homegrown). So, at one point a sending domain got its credentials deleted and started responding with 550 mailbox unavailable. I noticed that and fixed that within one day. Mistakes and errors happen, that's part of development. However, not only did mailtrap permanently stop sending emails to those temporarily unavailable addresses, it completely locked me out of my account. The email address was the one I used for creating the mailtrap account - and they send you an email that you must read, in order to login. They stopped sending that email, and locked me out of my account. It took me several hours to pinpoint the problem and determine that it's mailtrap's fault. I shold charge them for the time i spent troubleshooting their system. At the time of this writing, they still haven't resolved the issue - I have to tell their support to cancel my contract with them, I am still locked out of their platform. Obviously, I cannot allow a provider with such poor reliability to participate in my critical infrastructure. And I understand that this may be a relatively rare case - but still, for the reasons precisely described above, I cannot trust mailtrap, and cannot risk something like this happening with them again. 

sendgrid.com

Cannot recommend them. Degraded service. I started to re-open an account (because they closed my old account for no reason, for inactivity) and they said they will not create a new account for my email address, at the same time as saying that they will not disclose the reason for refusing to do so. Obviously they cannot be used because they cannot be trusted. I don't care how low reputation of my sending domain is - email sending is critical for my business, and if a provider decides to block an account even while an account is being created, such a provider has no business with me.

Amazon SES

Well... I want to recommend them, but I can't. They kicked me out of their platform when my credentials were hacked, and I believe I cannot get back to sending emails via smtp from aws ses. Which is no big deal, but has been very painful and time-consuming to re-implement this capability in-house. 

The point is, I would rather abandon AWS sooner than later. You have to ask (and answer!) yourself the question: what would happen, if AWS drops you as a customer? What if they deplatform you? They don't need a reason to do so; a lot of people and companies, especially prominent conservative voices, get deplatformed for no reason. Would you be ready? Can you replace and re-implement AWS in your own technology stack? 

If you remember (and maybe the news articles on this topic has been scrubbed and cannot be found anymore), but Trush Social, the social network run by Donald Trump, was kicked off of Amazon for political reasons. Amazon is liberal, Trump is conservative, Amazon kicked Trump off of their platform and later claimed that Trump is "refusing to use Amazon services." The point I'm trying to make is that every cloud provider can fail, and no provider can be a single point of failure in the stack that you as a technologist maintain for your clients.

Since I have to ask and answer these questions to myself, I have come to the conclusion that I avoid AWS products as much as possible. That includes compute and storage. It sounds difficult - amazon is the biggest cloud on earth, very competitively priced and well-structured. Scrambling for other providers is a pain in the ass. But maybe it must be done - in order to increase the reliability of the services that I provide to my clients.