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.
Co-Founder & CTO at a consultancy with 11-50 employees
Real User
Top 5
Jul 2, 2025
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.
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.
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.
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.
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.
Technical Consultant - Email Deliverability at Adobe
Real User
Top 20
Jan 6, 2023
We primarily use the solution for: * Transactional emails. Applications can use SES to send emails related to specific user actions, such as password resets or account confirmations. * Marketing emails. SES can be used to send newsletters, promotional emails, and other marketing communications to large email lists. * Notification emails. SES can be used to send notifications or alerts to users or administrators, such as order confirmation emails or system status updates. * 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.
Amazon WorkMail provides a fully managed email service, offering scalability, high availability, and seamless AWS integration, ensuring secure and efficient communication.Amazon WorkMail is designed to support a wide range of email communication needs, from transactional and marketing messages to internal notifications. It enhances email reliability through SES integration, utilizes machine learning for better deliverability, and offers robust security through domain protection and...
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.
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.
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.
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.
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.
We use the tool for transactional emails and marketing.
Our use case for sending out broadcasts and emails through our CRM.
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.
We primarily use the solution for: * Transactional emails. Applications can use SES to send emails related to specific user actions, such as password resets or account confirmations. * Marketing emails. SES can be used to send newsletters, promotional emails, and other marketing communications to large email lists. * Notification emails. SES can be used to send notifications or alerts to users or administrators, such as order confirmation emails or system status updates. * 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.