🐢Get Started
Last updated
Last updated
SENDUNE integrates with your AWS Account to send Emails and SMS. We recommend you create a separate AWS account exclusively for SENDUNE.
When you log in to SENDUNE for the first time, you are taken to the 'Settings' page. There are five steps you need to fulfill. Once these steps are done you need to raise support tickets with AWS to get your SES and SMS accounts out of the sandbox and into production mode.
The whole process can take upto 30 minutes (much lesser if you are familiar with AWS). If you do not have the time, you can STOP HERE. If you do have the patience, SENDUNE offers you everything you would expect from any reputed email service provider - minus the high cost and complexity.
The 'Primary Key' is the way you uniquely identify your users. This is usually the Email ID or Mobile Number with which your users log in to your app or website. Choose one accordingly. This cannot be changed once set.
AWS has datacenters in many regions. SENDUNE currently supports the below three regions only.
US East (N. Virginia)
US West (Oregon)
EU (Ireland)
Select any one that suits your requirement. All your email and sms sending is done from this region. Remember your selection because all your AWS support requests (for moving out of SES sandbox, raising sending limits, etc.) must be made from this region.
You need to create an ARN Role in your AWS account and add it in the SENDUNE dashboard. This allows SENDUNE to programmatically connect to your AWS account to perform various actions like sending emails and sms. Please note that as of now SENDUNE requires the 'IAMFULLACCESS' Role. Here's why. Follow step-by-step instructions below to create the ARN Role.
3.1 Sign in to your AWS account and go to the IAM section.
3.2 Select 'Role' from the side panel and click 'Create role'.
3.3 Follow the instructions as shown in below image to the dot.
IMPORTANT: When creating AWS Role, the 'Account ID' to be mentioned is 033267325636.
3.4 Search for 'iamfull' and check the box beside 'IAMFullAccess'. Click 'Next'.
3.5 Type in details as shown in below image and click 'Create role'. Your Role
3.6 Select the Role that has been created.
3.7 Copy the Role ID.
3.8 Paste the Role ID in SENDUNE settings dashboard and click 'Verify'. It might take a few seconds to verify your Role. Refresh browser and try again if verification does not work the first time.
3.9 Success. Your Role is verified. Your AWS account is now successfully connected to SENDUNE. You can proceed to the domain verification step.
This is the domain from which you will be sending your emails. We recommend you use a sub domain (Ex: emails.yourdomain.com) rather than your root domain.
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. It can take a few hours (usually much lesser) before your DNS records are verified.
The DNS records are related to DMARC, DKIM, and SPF protocols which protect your domain from spammers, phishers, and other unauthorized parties. Most importantly they create trust and prevent your emails from landing in spam folders.
One last step before you can put all this behind you - getting your SES and SMS accounts out of the sandbox and into production mode.
To prevent abuse AWS puts new accounts in 'Sandbox Mode' with certain restrictions. You need to raise a ticket with AWS to move out of the SES Sandbox. Make sure you have completed ALL the five steps above. Only then proceed with the step-by-step instructions below.
Login to your AWS account. Search for 'SES' and go to the Simple Email Service dashboard.
Click the the dropdown at the top-right. Select the AWS region from which you want to send emails. This must be the same region that you have selected in your SENDUNE settings dashboard (i.e. Step-2 above).
Click 'Get set up' from left panel and then click 'Request production access'.
Choose the type of emails you want to send, 'Marketing' or 'Transactional'. Enter the same domain or sub-domain that you have entered in your SENDUNE settings dashboard (i.e. Step-4 above). Accept terms and submit request. It is VERY IMPORTANT that the domain you enter here have an active website that showcases the nature of your business. AWS might reject your request if you do not have a website or just have a generic landing page.
That's it. You can sit back and relax. If everything is in order AWS will move your SES account into production and you will be able to send emails. It might take upto a day before AWS grants your request. Occasionally AWS might send you an email asking for more details. Reply with as much detail as possible. You must be able to convince AWS that you are a genuine email sender.
You will receive an email once AWS moves your SES account out of the sandbox. You can also click 'Account dashboard' from the left panel and see your sending limits. For new accounts AWS grants a sending limit of 50,000 emails er day with a sending rate of 14 emails per second.
If you need more you can always raise a request to increase your limits.
You can request a raise for your 'Sending quota'.
You can also request a raise for your 'Sending rate'.
And finally, keep an eye on your sending reputation. You can find this by clicking 'Reputation metrics' in the SES dashboard. Make sure your reputation is always 'Healthy'. AWS will block your account if you send unsolicited emails. These blocks are usually permanent. The block is not only for your AWS account but also for your domain.
WONDERFUL. If you have come this far, GREAT WORK. Your SENDUNE account is now ready to use.
======== Notes ========
In the early days of SENDUNE, we asked full access permission only for SES and SNS. SENDUNE 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 SENDUNE, this is how we handle things.
SENDUNE 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 SENDUNE the power to provision any resource within your AWS Account. However SENDUNE 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 SENDUNE from accessing your AWS Account.
It is highly recommended you create a separate AWS Account exclusively for SENDUNE. This way you can be sure that any resource launched within this AWS Account has been provisioned by SENDUNE.
