Get Started
Last updated
Last updated
You need the following to get started with Send With SES.
An AWS Account - Emails and SMS are sent from this account.
An AWS IAM Role - This allows Send With SES to programmatically connect to your AWS account.
Move out of SES Sandbox - Raising an AWS support request to allow you to send Emails.
Move out of SMS Sandbox - Raising an AWS support request to allow you to send SMS.
A Send With SES Account (obviously) - To store and manage all your customer data.
If you are an AWS developer these steps should be very easy for you. If not, the whole process can take 20-30 minutes. If you do not have the time, you can stop here. If you do have the patience, Send With SES offers you everything you would expect from any reputed service provider in the same segment - minus the high cost and complexity.
Lets go through each step one by one.
Creating an AWS account is just like creating an new email account. It's free and should take just a few minutes. Click this to start the process. You will be asked to provide a credit card. Do not worry. AWS will not bill you until you exceed their generous .
An IAM Role allows Send With SES to programmatically connect to your AWS account to perform various actions like sending emails and sms. Please note that as of now Send With SES requires the 'IAMFULLACCESS' Role. Here's . Creating a role takes a minute or two. See the below video (upto 1:10 timestamp) for instructions.
IMPORTANT: AWS has datacenters in many regions. Send With SES currently supports the below three regions only.
US East (N. Virginia)
US West (Oregon)
EU (Ireland)
Select any one of these regions from the top-right dropdown in your AWS SES dashboard and then click 'Request production access'. See the below video for full instructions.
AWS usually grants you access within a few hours. They might however ask you for additional details before granting you access. Do not worry if they grant you lesser sending limits than what you asked. You can always raise a new support request.
IMPORTANT: Make sure the AWS region is the same as the one you selected when moving out of SES Sandbox.
Once AWS grants you your SMS spending limit increase, you will need to input that value in Send With SES (see below image).
Details for each step.
Select Primary Key for Contacts: The 'Primary Key' is the way you uniquely identify your users. This is usually the Email ID or Mobile Number with which they login to your app or website. Choose one accordingly. This cannot be changed once set.
Select AWS Region: Remember the AWS region you selected in steps 3 and 4 above? Select the same one here.
Enter IAM Role ARN: This is the one you created in step 2 above. Copy-paste it here and verify it.
Enter Domain To be Verified: This is the domain from which you will be sending your emails. You need to have a domain. Otherwise your emails will land up in spam folders. You can use a domain (example.com) or a sub domain here (emails.example.com).
Enter DNS Records: Once you enter your domain, you will be shown a set of DNS records. You will need to enter these DNS records with your domain registrar (i.e. the place where you purchased your domain from). It can take a few minutes to a few hours before your DNS records will be verified. Once verified, you are all set to start using Send With SES
These setups are a one time process. Once done, you can enjoy the benefits of a low cost, highly reliable email/sms service for as long as you wish.
In the early days of Send With SES, we asked full access permission only for SES and SNS. Send With SES is in a constant state of development. As we kept building the product we wanted permissions for S3 to store email images and SQS to queue email delivery notifications for further processing. Sometime later we wanted CloudWatch access to hold and process SMS related delivery notifications.
We also expected AWS to introduce breaking changes and wanted to be ready in such cases. Not surprisingly AWS sent everyone the following message a few months ago. (They later rolled backed on this requirement.)
"We are reaching out to notify you that AWS Managed Policy is making a change that will require your action. AWS Managed Policy is deprecating the managed policy "CloudWatchFullAccess" and replacing it with "CloudWatchFullAccessV2". After December 7, 2023, "CloudWatchFullAccess" will no longer be supported."
How do we provide an uninterrupted and seamless experience to end users when we have to constantly keep asking them to add specific permissions every now and then. This was not at all user friendly. Both end-user experience as well as product development suffered.
So we decided to ask only for one permission - IAM Full Access.
Some people were/are unhappy. Somehow their assumption was, "If we give you IAM Full Access you will misuse it.", or, "Your servers will get hacked and those hackers will do something bad." Understandably, these are valid assumptions, like, "Do not build a flying machine because it might crash."
We believe transparency and a proper explanation will convince some people and no amount of explanation will convince other people. To those people who are considering to use Send With SES, this is how we handle things.
Send With SES accesses your AWS Account by requesting a set of temporary keys using the 'IAM Role' provided by you. This is the recommended best practice by AWS. No third parties can access your account.
IAM Full Access is something similar to full admin access. It gives Send With SES the power to provision any resource within your AWS Account. However Send With SES only provisions resources which are required. Currently these are - SES, SQS, SNS, S3, Pinpoint, CloudWatch.
You can delete the IAM Role at any time to prevent Send With SES from accessing your AWS Account.
It is highly recommended you create a separate AWS Account exclusively for Send With SES. This way you can be sure that any resource launched within this AWS Account has been provisioned by Send With SES.
--------------IGNORE BELOW STEPS - OUTDATED---------------
Proceed with the below steps once you have created your AWS account. The whole process can take upto 20 minutes. AWS might take upto 24 hours (usually much lesser) to move your account out of the SES sandbox.
Create AWS Role and add that role Role in Send With SES settings.
Add DNS Records for your Domain.
Move out of SES Sandbox (to send emails).
For 1, 2, 3, click the videos below for step-by-step guides.
To prevent abuse AWS puts new accounts in '' with certain restrictions. You need to answer a few questions explaining your use case to move out of the sandbox.
To move out of the SMS Sandbox follow the instructions detailed .
You can send SMS to almost across the world. Some countries have additional requirements to send SMS.
Additional requirements for .
Additional requirements for .
For new accounts the monthly SMS spend limit is restricted to $1.00 (USD). Estimate your SMS sending cost and increase your monthly SMS spending quota by following instructions .
Now that you have completed the above steps, it's time to get your Send With SES account up and running. for an free account if you haven't already done so. Once you login you are automatically taken to the settings page. It looks like below.
For step 5, you might want to watch the below video from the timestamp.
Send With SES integrates with your own AWS account to send Transactional Emails and SMS's. We highly recommend you a separate AWS account for use exclusively with Send With SES.
Move out of SMS Sandbox (Optional. Only if you want to send SMS's). ().
