Amazon SES

Amazon Simple Email Service comes with the bundle of Amazon Web Services (AWS) and it also offers a limited number of emails per month for free. One who has a technical background and wants to send custom emails with custom domains in a professional way can go with Amazon Simple Email Service. If you have no technical background or tech team, it might not be useful for you.

It is difficult to set a Sandbox environment. In the SNS environment, we need to verify all emails we need to send emails and all emails we want to receive an email so it becomes difficult when we integrate it to a website where tons of emails are going to receive in it.

Amazon SES is well-suited for a "do-it-yourself" mass-mailing solution, where fine control over mail delivery is required. Since mail server reputation affects deliverability greatly, and SES has a good reputation, it's a great fit for SMBs: mail server reputation cannot be built overnight. Amazon SES is not a turnkey solution, so significant internal expertise is required, and it cannot be compared to packaged services like Mailchimp.

We use Amazon Simple Email Service to auto-respond to users that submit messages through a contact form. We are using Amazon Simple Email Service with our self hosted python application to send our marketing emails, get feedback for our services, and Hackathons.

AWS support is always available and less waiting time for technical support.

Amazon Simple Email Service is an excellent choice for integrating high-volume or important email delivery into an existing application, service, or custom established workflow in your organization. If you have a true development group looking for a seamless way of handling email delivery, this is the right product for you. It's easiest to set up if you're already using other AWS services such as Route53 for DNS but can function as a standalone service. However, if you're expecting a product that was designed to do all of its intended functions from a user interface, that's not what Amazon Simple Email Service was intended to be.

When service limits or troubleshooting issues have come up in the past, AWS support has always been very responsive and quick to make needed changes.

It's not for spam. They have a limit for bounced emails, so you must have your email lists clean and updated.

It would be better to have chat support.

If you're working with an AWS infrastructure this is the best move, as you will get great benefits from using it and your development team will feel that they know what they're doing. If you're not using AWS, this probably can be a problem, as you will not get the 62,000 emails for free, or developers will feel a little strange working with different technologies.

We did not have the need of contacting Amazon for support. The documentation they provide is of great quality. Examples are easy to follow. One thing to have into consideration is we didn't have the premium support for AWS, so I can't provide details on how good or bad this service is, but in general, the basic support I had was great.

SES is great when you have an online form that needs to send email. It's bullet proof and can handle large loads.
I probably wouldn't use SES for a smaller temporary use case. There is configuration needed with SES and potential (tiny) costs.

Generally, I have one configuration that I use for most forms unless I expect high traffic. In that case I keep it separate.

I'm giving this a 5 because I've never had to use support for SES.

Perfect for website forms. Never used it elsewhere, but for form delivery it can't beat it. Even WordPress has plugins that make hook-up very simple and straightforward.

I've never needed it, due to the plethora of documentation online.

In our demos, we try sending the reports to the email ids from which the user is logged in. Our demos are hosted on AWS ECS and the whole demo works on the AWS ecosystem. So to send the reports we use AWS SES as it is in the same ecosystem, no extra SMTP configuration needed and it is very easy. So in this way, we use SES for many demos and other use as well.

The support from AWS has always been good. There is no complaint from my organization. Also, the documentation is very good so I don't find any difficulties in this. So overall it is a very easy and smooth process to adapt.

When you have set up your ecosystem with AWS, SES is the best option to send a message. If you have EC2 for any of the applications, you can do 62K free emails per month. The way it interacts with SNS, S3, AWS KMS (to encrypt the email before storing to the S3) and Amazon cloud watch makes it more comprehensive.
If you are not an Amazon shop and just looking for SMTP solutions, SES is not for you.

SES has proper SDK for most of the languages and it has good documentation for the same. If you are an intermediate level user or developer of AWS, you don't find SES as too difficult to implement. In case of some corner needs, you will find quick support on their forums and if you have set SLA, they respect it really well.

It is best suited for sending customized emails to users in reaction to events from other AWS services.
It is less appropriate for just sending out notification emails in which case SNS should be used.

When companies need to send bulk transactional emails to their customers, like in Mexico for accountant purposes.

SES is well suited if you need to send a ton of emails cheaply and 100% deliverablity isn't needed.

If you are looking for a no fuss, functional email delivery engine at a very low cost, Amazon SES is great. But, there is a learning curve, the documentation is often dense and many times, you yearn for a simple GUI, while setting up your interface. SES has barebones analytics - virtually none. It also does not do list management. Mapping bounces to SNS is not very intuitive either. If you are sending embedded images, you need to load them from external servers.

Amazon Simple Email Service could be used to target user engagement just like SNS notifications. This could be an alternative where the user might need to have some registration information, password reset emails, marketing emails etc. It is less appropriate if you want to map a domain name on top of amazon.com domain name as its clearly visible on which service is being used to send out emails.

Amazon SES is great for sending bulk mail, particularly notifications. It is not intended for holding a conversation as there is no way to view the mail that has been sent, so unless you are using a third party system that tracks what mail is being sent, such as a ticketing system like Kayako, you would not want to use it for regular communication.

Amazon Simple Email Service (SES) shines if you just want to send bulk mail and you do not want to pay any monthly fees for the software that you won't use. You pay exactly for what you use -- to send emails. Amazon SES is extremely reliable, I haven't seen any bounces that were on their end.

Speaking about features that are lacking; if you do not have software to send and track all the subscriptions, you may want to look into services that have that implemented already. Personally, I'm using Amazon SES as my SMTP server and Sendy to track all the subscriptions, statistics, reports and all the other features. The price difference between putting several products together and using all-in-one product is huge. Therefore, hands down to Amazon SES for [being] such a great product.

SES is truly a "simple" email sender. It's focused on the actual technology behind sending emails, and sending emails that appear that they genuinely come from a specific domain. This is awesome if you've got some developers to implement the technology to make this kind of service valuable. However, if you don't know how to write code to conform to an API, or how DNS records work – steer clear. This is not for the faint of heart.

As I said before, SES is ideal for outsourcing any and all e-mail message origination. Marketing e-mails, new user signup e-mails, and e-mails that notify engineers of service problems are all excellent use cases for SES. For startups, the fact that you get 10,000 free e-mails, just for signing up, makes it a no-brainer when in the early development stages of writing a program. Once the credentials are loaded into the code, you can forget about e-mail origination forever (almost)!