Amazon WorkMail Reviews

My usual use cases for Amazon WorkMail started from my interest in all the AWS services, which are numerous, like hundreds, and how I could set up an online document service, something like Google Drive or Microsoft One Cloud.

I came across the AWS equivalent, which was not very usable initially, but I used it for a while to set up end-user computing on document storage there, requiring some kind of initial setup of AWS Apps, which are end-user applications that you can use out-of-the-box immediately.

I logged on with various authentication methods to utilize all those services. This is how I initially discovered the document service called WorkDocs, which closed last year.

However, because of the common authentication methods to these end-user services, I found out they also offer the webmail service. I tested Amazon WorkMail in parallel with the document service and really liked it, ultimately using it for many of my email accounts.

I have email accounts on other external services, but the end-user AWS offering was so helpful that I set up something like 10 accounts on Amazon WorkMail. When using the service, I can set up one email account, and if I like it, I can have additional accounts in the cloud as needed.

For most of my cloud accounts, I set up a separate Amazon WorkMail account for all my incoming and outgoing emails, making it very easy to set up internal routing rules.

By logging on just once and authenticating to Amazon WorkMail, I can read all emails from the 10 accounts arranged in different folders. When replying to emails, it's seamless to impersonate the specific account to which I want to respond.

While it's likely that other webmail services, even open source ones, implement similar features, the AWS implementation has been very useful for me over these six or seven years.

Now, I'm not very happy because they are discontinuing the service, and I will have to find a new one to migrate everything, including all my filters and routing rules. I genuinely hope that when closing down a service, they would offer some migration routes or tools for a simple export process to another service, like an open-source one, but unfortunately, they don't.

To answer what features or capabilities of Amazon WorkMail I've found most valuable over the years, email services are well-established and share many common features. I have used them in a simple manner, which I appreciate.

When accessing the service, common authentication methods are in place, so when I provide my credentials, it logs me onto application servers where I can use many other services with single sign-on authentication.

The basic web interface contains the Amazon WorkMail dashboard with a tree structure for all the folders I created, similar to any other IMAP-related email service.

In the past, users connected to email services using the POP protocol, but now the IMAP protocol is standard, allowing connections to various mailboxes worldwide from different providers, including Amazon WorkMail.

This standardization makes it simple to create new folders for classifying incoming emails based on my organizational structure. I can route a large volume of incoming emails to different folders based on the mailboxes and accounts I've set up, matching how it works with Microsoft servers which use LDAP protocol for domain management.

Despite being an end-user service on AWS, the backend is complex enough to enable many useful features. I invested time in configuring it, and it worked flawlessly for six years.

Now, with the service going away, I need to export everything and figure out how to continue, including moving my domain name to another service.

As for valuable features, Amazon WorkMail offers excellent classification options and adheres to the IMAP email protocol standards. The service has a standard menu of exposed features like printing emails, viewing emails, managing an address book, and classifying those entries into the organizational structure I've set up.

It was easy to use with a point-and-click interface, though I haven't utilized it via the CLI or script automation, as I haven't needed them. However, based on the AWS WorkMail commands available, I believe scripting options exist for advanced users. While those advanced features are available, I found the service very useful without needing them.

While using Amazon WorkMail over time, I haven't encountered substantial disappointments, but there have been usual glitches with the web interface. For instance, while the service is generally 99.5% perfect, I experience issues like the folder structure I set up sometimes not remembering the state of expanded and collapsed nodes after refreshing the page.

This lack of persistence in which nodes are collapsed or opened can be frustrating. However, since it's a minor technical issue, I doubt the average user would notice it.

If Amazon WorkMail were not discontinuing, I wouldn't think there is much to improve or enhance about it. It is standard enough and easy to use, and any glitches are minor, not worth evolving or disrupting its current functionality.

As for whether the user interface is intuitive and if I'm satisfied with its flexibility and customizability, there are some minor features lacking, but I don't feel a need for changes since it works as designed. The most crucial aspect is that I can set up my address book with the complex organizational structure needed for the accounts connecting to AWS.

The lower-level functionalities suit me well enough. Other services often have customizable views of email representations with senders, subjects, and even snippets of content. While my external application on mobile can show customizable lines with my email list, Amazon WorkMail does not offer that feature. I don't really need it, but it would be a nice addition for power users.

When assessing the security features offered by Amazon WorkMail, such as encryption protocols, I check the security protocols on my phone using an external application that displays them immediately. All the emails I access have four essential security features.

While many incoming emails from different accounts may not be secure enough, Amazon WorkMail is great, showing all four features as checked. The best emails have all protocols intact: TLS is the secure one, DKIM is checked as well, SPF is functioning, and DMARC is also in place.

I can see all four security protocols are enabled, ensuring sufficient security for these emails, unlike many others from various senders, which only have two, three, or even broken protocols.

Regarding Amazon WorkMail's administrative controls, there is a settings menu where I can set up signatures and other aspects for the different emails. There are five sections in the settings: a general section, an email section, an email rules section, which I use often; there, I can set up many email rules so that specific emails from certain domains are routed to specific folders or sent to junk if they're not secure enough.

This is standard functionality I can do with any email server based on an IMAP account. I use it a lot, which is why I am not very happy that the service is going away without an automatic export migration tool. The fourth section includes automatic responses, where I can manage signatures.

The fifth section contains an integrated calendar, which is common in many email services, allowing scheduling and reminders. Overall, there doesn't seem to be anything missing; Amazon WorkMail functions as a typical webmail service without requiring infrastructure setup.

I primarily use the web version of Amazon WorkMail. Alternatively, I could utilize the CLI or SDK for scripting, but I haven't found a need for that yet. I hope to write scripts to export everything in the future since I have a year to figure this out, though I'm unsure what can be exported. Overall, I would rate this service a 9 out of 10.

We are an integrator, and we have a product in which we use Amazon WorkMail. We send emails on a daily basis in a batch mode to customers. We have about 50,000 emails across various customers.

The features of Amazon WorkMail that I have found the most valuable so far include sending emails and tracking whether the email is read or not.

I find the feature that checks how many emails have been successfully sent and how many of them have been opened very useful, because in our application, we know the usage of the emails.

The encryption of emails, both in transit and at rest, has benefited our security strategy as it is a layer of security that provides us better confidence for customers and also internally tracks the security aspects. The encryption meets my expectations.

We are satisfied with Amazon WorkMail, as it is able to send emails and provide receipts, including the read and other statuses. Since we are doing more API side integrations, there does not seem to be a need for improvement, except for the opt-out feature that could have enhanced configuration on the APIs.

I have been working with Amazon WorkMail for the past two years.

I did not participate in the initial setup and deployment of Amazon WorkMail, but my team handled that process.

I do not have any concerns regarding the scalability of Amazon WorkMail, as we are sending about 40,000 to 50,000 emails per day, doing both transactional and batch with a queuing mechanism internally. So far, we have not had any challenges in terms of scaling.

Specifically from an Amazon WorkMail perspective, I have not had to assess customer service and technical support, but for AWS support, we have sent some emails and they have responded promptly, so we are satisfied.

Positive

Before Amazon WorkMail, we were using SMTP emails from Gmail and then switched to this solution. We decided to switch from the previous solution due to some security issues in the SMTP and the scalability limitations.

I did not participate in the initial setup and deployment of Amazon WorkMail, but my team handled that process. For my team, it was manageable during setup, neither straightforward nor complex.

I did not participate in the initial setup and deployment of Amazon WorkMail, but my team handled that process. For my team, it was manageable during setup, neither straightforward nor complex.

Since it is a SaaS product, customers will not know the ROI, but we have experienced the ROI as the subscription cost keeps us at a low cost.

I do not deal with the exact pricing of Amazon WorkMail, but my IT person handles that, and I have heard that compared to other providers, it is considerably cheaper.

I did not evaluate other options other than Amazon WorkMail because we are an AWS workshop, so we chose it.

From the communication aspects, working with Amazon WorkMail has been seamless and cost-effective.

My customers do not make any use of Amazon WorkMail's compatibility with Microsoft Active Directory. I have not utilized Amazon WorkMail's integration capabilities with Outlook. I have not assessed Amazon WorkMail's mobile device support capabilities.

In terms of mailboxes, since we are only sending emails and not receiving them, I do not focus on mailbox sizes and everything, as we are more focused on outgoing emails.

On a scale of one to ten, I rate Amazon WorkMail an eight.

We use it to send emails, basically. Plus, whenever you send or receive an email, WorkMail gives you a trigger point. It's very much integrated with other AWS services. For example, one use case we had was with our UAT servers. They were costing us a lot because we had to pay for them every month, even when no one was using them for a few months.

So, we set it up so that whenever a client sends us an email saying "please turn on the UAT server," the UAT server automatically turns on using WorkMail. We get a trigger that the client wants the server on, so we turn it on. After four or five days, it automatically turns off, which saves us money. That's one use case we are using it for.

The integrations. WorkMail has great integrations with Lambda functions, relationships with SNS, and other AWS services. The integration capabilities are very simple, easy, and powerful.

With more integrations, you can create more workflows. If you have limitations, you cannot create those integrations.

WorkMail is not available in all AWS regions. It was not available in India, so I had to create a setup in Ireland. That was a limitation because I was trying to get a WorkMail account while being in India. I think it is supported now, but there might still be a few regions where it's not.

Integration can always be better. Plus, if more WorkMail agents are available for both India, that would be good. And if we have more WorkMail regions available, they can expect us to use more integrations.

I have been using it for three to four years. I use the latest version. 

It is very stable. I haven't faced any issues. We trigger about a thousand emails a day using Amazon SES, and we haven't faced any issues with availability.

Our entire production service, even the test servers, relies on AWS. So, around one to 1.2 million users.

The tech support is very much integrated. It's a single point of contact for support.

WorkMail is not available in all AWS services. I'm not sure if it's available everywhere now, but I'm from India, and WorkMail was not available in India. I had to create a setup in Ireland. That was a limitation because I was trying to get a WorkMail account while being in the India region. The support team was working with us at that time. I think it is supported now, but there might still be a few regions where it's not supported.

The deployment takes wo to three days at large. Again, there's documentation. You can read it.

It's cloud-based.

It can be done in-house. The standard AWS recommendations will also help with that.

The scalability and stability of SES and WorkMail are very great. If we use our own email servers or SMTP servers to send emails, we would always be worried about them going down. Sending an email is very important. If someone is sending notifications, it's crucial that people are aware of what is happening. So, having a perfect, scalable, and stable solution makes sense. And I see SES and WorkMail as one of the most scalable and stable solutions.

It has a very good free tier. I think about 20,000 to 30,000 users are free. It has a great free-tier model. If you consume your free trial, then it will be charged on a per-email model. That is also very minimal. Overall, the pricing model is great.

Overall, I would rate it an eight out of ten. If you are already on the AWS platform and deploying your services on AWS, using WorkMail for notifications through your application using SES makes a lot of sense because it is well-integrated with the entire system. If your emails get bounced, your application gets notified about it. Overall, if you are on the AWS cloud, you should use SES and WorkMail.

Within our organization, we handle procurement and keep customers updated through email. Most customers use our procurement application, which goes through different stages. When a customer submits a request on our website, we send them a message via Amazon WorkMail to confirm that their request has been received and is under review. We regularly update them on the status of their procurement through email.

For instance, if a customer is procuring items from China and shipping them to Africa, we inform them at each stage. From the initial procurement process in China to the transfer of goods to West Africa, such as Nigeria, we keep the customer informed at every step.

The most valuable feature of the Amazon WorkMail for me is the SMC server. It makes my work much easier, especially since I often work with Spring Boot. There are many built-in APIs in Spring Boot that help with messaging. What I appreciate about it is that it simplifies the process. I don't need to write much code; I define the credentials in my properties or environment variables. The Java Message API, an internal API from Spring Boot, does most of the work. I set up the properties and connected them to the SMC server, and I can send emails. 

The solution is quite low-level and lacks some advanced features. For example, it doesn't provide tracking capabilities, such as knowing how many users opened an email, which is crucial for email marketing. You would need to integrate these analytics with other tools to get them.  I need to know if there has been a bounce and how customers interacted with the email. 

I would only suggest that Amazon WorkMail relax the rules for using Amazon SES in production. When you create an account, it starts in Sandbox mode, which means you can't use it in production right away. You must go through a process, message Amazon, and request to move it to production. Since Amazon is a big company, I feel customers shouldn't need this permission to use the service in production.

I have been using the product for three years. 

I rate the tool's stability a ten out of ten. 

I rate Amazon WorkMail's scalability a nine out of ten. 

I haven't had issues contacting Amazon support except when trying to move SES out of the sandbox environment. In my experience at different companies, the process varied. Getting approval to use SES in production at one company was straightforward, with just one message. However, at another company, it required multiple stages before approval.

Positive

I rate the tool's deployment ease a ten out of ten. It is easy if your account is not in the sandbox. Integrating the code took as long as deploying Amazon SES. Once the code was live, Amazon SES was live. However, if we need to do a lot of configurations, like setting up NGINX and other things, the deployment can take up to 24 hours.

First, I make sure to have my credentials ready and push those credentials into the properties file. Since this is a Java application, I package the application into a WAR file. After packaging, I transfer the application to the server. Our running instance is usually attached to our server nodes. Once transferred, I start the service, and everything goes live.

You need one resource to handle the deployment. We don't need people to maintain this solution once it's deployed. It's very simple, and the chances of failure are very low. Most issues occur if someone adds an asset to the AWS account and removes the authentication credentials. If that doesn't happen, one person is enough to handle all the management tasks.

We can expect ROI with the tool's use. It improved our internal communication by replacing WhatsApp, which sometimes leads to unnecessary conversations.

I rate the solution's pricing as one out of ten. It is close to being cheap. Sometimes, the tool offers a generous amount of free messages, up to 40,000, which is great for startups like ours. This means that we don't accumulate any costs for some months because we stay within the free usage tier. When we exceed the free allocation, the costs are reasonable, and no hidden charges exist.

The tool is considered the industry standard for messaging services, and Amazon is well-known for being a leader in cloud technology. I rate it a ten out of ten. If your application involves sending many emails to customers, I highly recommend using Amazon WorkMail. It's straightforward and the best choice in my experience.

I use Amazon WorkMail to create email accounts and integrate them with Gmail and Microsoft Outlook. I've launched a website and migrated it to AWS infrastructure, and WorkMail is part of this integration.

Amazon WorkMail integrates with Route 53 and other AWS services, providing a seamless experience when using AWS infrastructure.

Amazon WorkMail's positive points include its security, user management, and organization and categorization features offered by the management console.

Amazon WorkMail's user interface could be more intuitive and user-friendly. Integration with Gmail using both SMTP and POP3 would be beneficial.

I have been working with Amazon WorkMail for about seven months.

I have not experienced any problems with the stability of Amazon WorkMail.

Amazon WorkMail is highly scalable, similar to other services offered by AWS, and is one of its most important features. However, with only two users currently, I cannot comment further on its scalability.

I have not contacted technical support for Amazon WorkMail.

Before using Amazon WorkMail, we used Bluehost as a cost-effective provider for email services, which was cheaper than AWS. However, the features provided by AWS were beneficial.

The initial setup of Amazon WorkMail took about an hour and involved learning through various tutorials due to the complex management console.

I deployed and maintained the solution myself, without any external help.

I pay four dollars per month for each user of Amazon WorkMail. I believe the price could be cheaper given the features provided.

I did not evaluate other solutions before choosing Amazon WorkMail.

Currently, I don't have any advice about using Amazon WorkMail. Since I only use AWS and am unfamiliar with its competitors, I can't recommend it.

We used the product to send email notifications to our customers, end users, or our internal team. If we are hosting any applications, the customer must know it.

The product is very user-friendly. It enables us to send emails to end users.

The product should improve technical support.

I have been using the solution for seven years.

I rate the stability a ten out of ten.

The solution has very good scalability. I rate the scalability a ten out of ten. More than 1000 people use the solution.

Technical support was good previously. The technical support engineers used to teach and guide us and help with deployment. Nowadays, I feel that technical support has a low standard. They ask us to refer to documents if we contact them with any issues. If we needed to refer documents, we could have done it ourselves. What we expect from support is real-time help.

Negative

I rate the ease of initial setup a nine out of ten.

The deployment process takes 15 minutes. We need not put extra effort into maintaining the product.

The solution should improve its price. I rate pricing a six out of ten.

I used the solution in my previous organization for our customers. I used the latest version of the solution. I use the service only for sending emails. Instead of maintaining a separate server for emailing, we can use the solution because it is scalable and can be maintained by admins. Overall, I rate the solution a nine out of ten.

Our primary use case is to send emails to any person using an identity.

The best feature is that Amazon SES provides verified email messages. There are many software and email services, but SES provides verified accounts for an organization. With SES, you can also handle any bounces or complaints we receive from emails.

There is room for improvement in the scalability. Currently, you can only send one notification at a time. It would be great if it could send to multiple recipients simultaneously using different email addresses. 

For example, in one organization, different departments like HR and engineering can use one identity each to send emails. This would make it more scalable and stable.

In future releases, I would add the ability to send multiple messages at the same time using different domains within the same company.

I have been using Amazon SES for the past four to five months.

Currently, for small and medium-scale usage, it's very stable.

Probably less than 20 to 30 percent of the workforce uses AWS in our organization. 

If you have an AWS account, the initial setup is easy.

I would recommend it because it is a very secure service.

Overall, I would rate the solution a nine out of ten. 

We primarily use the solution for:

1. Transactional emails. Applications can use SES to send emails related to specific user actions, such as password resets or account confirmations.
   
2. Marketing emails. SES can be used to send newsletters, promotional emails, and other marketing communications to large email lists.
   
3. Notification emails. SES can be used to send notifications or alerts to users or administrators, such as order confirmation emails or system status updates.
   
4. Custom emails. SES can be used to build custom email solutions, such as automated email responses or personalized email campaigns.

Overall, SES is designed to make it easy for businesses to send a high volume of emails quickly and reliably, with features like automatic retries and email-sending history tracking.

The solution has improved our organization by offering:

1. Scalability. Amazon SES can handle a high volume of emails, making it suitable for organizations with large email lists or that need to send a large number of emails on a regular basis.
   
2. Deliverability. SES uses machine learning and other techniques to help improve the deliverability of emails, increasing the likelihood that emails will be delivered to their intended recipients.
   
3. Reliability. SES has a 99.9% availability rate and automatically retries failed deliveries, helping to ensure that emails are delivered successfully.
   
4. Integration. SES can be easily integrated with other AWS services and third-party applications, allowing organizations to build custom email solutions or integrate email communication into their existing systems.
   

The most valuable aspects of the solution are:

1. Machine Learning. SES uses machine learning and other techniques to help improve the deliverability of emails, increasing the likelihood that emails will be delivered to their intended recipients.
   
2. Integration. SES can be easily integrated with other AWS services and third-party applications, allowing organizations to build custom email solutions or integrate email communication into their existing systems.
3. Automation. SES offers features like automatic retries and bounce, and complaint handling, which can help to automate some email management tasks and improve the efficiency of an organization's email communication.
   
4. Security. SES includes features like DomainKeys Identified Mail (DKIM) signing, email encryption, and authentication to help protect the security of emails and the reputation of an organization's domain.
   
5. Cost. SES offers a pay-as-you-go pricing model, so organizations only pay for the emails they send, helping to control costs.

We'd like to see the following improvements:

1. A/B testing. The ability to create and send multiple versions of an email to a small subset of an email list and then use data on which version performed better to inform future email campaigns would be helpful.
   
2. Email scheduling. We need the ability to schedule emails to be sent at a specific date and time in the future rather than being sent immediately.
   
3. Email personalization. We'd like the ability to insert personalized elements like a recipient's name or location into emails using data from an organization's systems.
   
4. Advanced analytics. It would be ideal to have detailed data and reporting on email opens, clicks, bounces, and other metrics, as well as integration with other business intelligence tools.
   
5. Advanced spam filtering. We need additional spam filtering options beyond the basic spam filtering already provided by SES, such as blocking specific types of content or customizing the spam filter's thresholds.

I've been using the solution for five years.

As an email infrastructure and deliverability expert, I have to choose multiple solutions based on the needs of an organization.

We always compare the solution with Sendgrid, Sparkpost, Mailchimp, Mailgun, etc., and based on the requirements, provide the solutions.

Our use case for sending out broadcasts and emails through our CRM.

The most valuable thing is that emails sent through SES have a delivery rate of greater than ninety percent. It's a big factor in gaining trust in Amazon, as most of the time, they land in the inboxes.

There is room for improvement in the support. It's just that customer support, though good, takes time to resolve issues.

I have been using Amazon SES for more than a year. We currently use the latest version.

I would rate the stability a nine out of ten. It is a stable solution.

I would rate the scalability a nine out of ten. 

There is room for improvement in support.

Positive

The initial setup is moderate, neither easy nor too hard. The deployment took me two to three hours.

It's very cheap. The cheapest among all the services available.

It's pretty complicated and not that easy to set up. But, in the long run, it's very helpful. It gives successful outcomes out there.

Overall, I would rate the solution a nine out of ten.

We use Amazon SES to send emails and notifications to our customers.

Amazon SES is very easy to configure. If I have an email ID in Gmail, I would have to learn the Gmail API to send an email programmatically. The advantage of Amazon SES is that I don't have to learn the API of the email service provider. I can just add my email on Amazon SES, do some verification, and send the email content directly to Amazon SES, which will then go through my email. So I don't have to learn the API of the email service provider. If tomorrow we start using a Yahoo account, I'll have to learn the API of the Yahoo email service. So, in this case, we can add both accounts to Amazon SES, and we only have to learn the API of Amazon SES.

When we first set up an email on Amazon SES, they had to verify it, which was not fast enough.

My senior has been using Amazon SES for more than one year, but I started using it around six months ago.

Amazon SES is a stable solution, and we haven't faced any bugs.

Amazon SES is a scalable solution. Three people use the solution in our organization.

The solution’s initial setup is very easy.

We chose Amazon SES because it was the recommended serverless service.

Other than Amazon SES, there isn't another alternative within AWS.

Overall, I rate Amazon SES ten out of ten.