{"id":522,"date":"2024-04-11T05:08:20","date_gmt":"2024-04-11T05:08:20","guid":{"rendered":"https:\/\/blog.ngocha.biz\/?p=522"},"modified":"2024-04-11T05:08:20","modified_gmt":"2024-04-11T05:08:20","slug":"setup-aws-ses","status":"publish","type":"post","link":"https:\/\/blog.ngocha.biz\/?p=522","title":{"rendered":"How To Setup AWS SES: A Step-By-Step Guide"},"content":{"rendered":"

In this blog, I am going to setup AWS SES<\/strong> for you.<\/p>\n

The necessity of email notifications is very important, we all receive emails each day for various purposes, like promotion-related emails, newsletters, application updates, authentication emails, etc.<\/p>\n

If you are a person who is looking for this kind of requirement and also wants to send hundreds of emails each day, then you need an email service.<\/p>\n

In the cloud environment, AWS<\/strong> provides a service called Simple Email Service (SES)<\/strong>, which is capable of sending and receiving emails in a pay-as-you-go<\/strong> manner.<\/p>\n

Before we move to the setup, let’s see how the SES works.<\/p>\n

AWS SES Workflow<\/h2>\n

The following workflow explains the process of mailing from the sender to the receiver.<\/p>\n

\n
\ud83d\udca1<\/div>\n
AWS SES setup requires a domain name (e.g., email.devopsproject.dev<\/code>). So the domain name need to verified by the DNS server, in our case it is Route53<\/strong><\/b>.<\/div>\n<\/div>\n
\"aws<\/figure>\n

The explanation of the AWS SES workflow starts from.<\/p>\n

    \n
  1. An application (Sender) creates an API request to the AWS SES to send emails to users.<\/li>\n
  2. Verified SES services will process the email and send it out to the Internet.<\/li>\n
  3. The Internet Service Providers will pass it to various mail servers (e.g., Gmail, Yahoo, Zoho).<\/li>\n
  4. Once it reaches the correct mail server of the receiver, the email will be verified as not spam, and then it will reach the inbox.<\/li>\n<\/ol>\n

    Now, you have got understand how AWS SES works so that we can start the setup.<\/p>\n

    Step 1: Create Identity for SES<\/h2>\n

    You can create an SES service with your email address as the identity, but email has some limitations, so providing a valid domain name is recommended.<\/p>\n

    In this setup, I am using a valid domain name devopsproject.dev<\/strong>, which is hosted in Route53<\/strong>.<\/p>\n

    Open the AWS console and navigate to SES.<\/p>\n

    \"aws<\/figure>\n

    On the next window, under the configuration<\/strong> section, select the verified identities<\/strong> tab.<\/p>\n

    \"aws<\/figure>\n

    A new window will open, and you can see two options, which are Domain <\/strong>and Email address<\/strong>. You can choose one of the methods that suits your requirements.<\/p>\n

    Step 2: Choose the Identity Type<\/h2>\n

    If you are choosing Domain<\/strong>, you should provide a valid domain name. If you select Email address<\/strong>, you can provide any of your email addresses.<\/p>\n

    For this setup, I am choosing the Domain Identity<\/strong> type.<\/p>\n

    \"choosing<\/figure>\n

    After choosing the identity type and providing the domain name devopsproject.dev<\/strong>, a few options will be available to customize the service.<\/p>\n

    The first option you will see is Assign a default configuration set<\/strong>. sets<\/strong> are a set of rules that work with sending emails, example,<\/p>\n

      \n
    1. You can use a dedicated IP<\/strong> address for your marketing emails, and in SES, you can create IP pools.<\/strong><\/li>\n
    2. Integrate Transport Layer Security<\/strong> to make communication more secure.<\/li>\n
    3. Use a subdomain to handle the redirected responses.<\/li>\n
    4. You can analyze the bounce and compliance emails with the help of CloudWatch<\/a>.<\/li>\n
    5. You can also create a suppression list<\/strong> based on the bouncing and compliant emails.<\/li>\n<\/ol>\n

      These are the options you will see when you create a configuration set. Y<\/strong>ou can create multiple configuration sets<\/strong> and attach them to your emails.<\/p>\n

      Step 3: Create a Custom Mail From Domain<\/h2>\n

      The second option is to use a custom MAIL FROM domain<\/strong>. You can see only if you choose the Domain identity<\/strong>.<\/p>\n

      Here, you can provide a subdomain<\/strong> to send emails.<\/p>\n

      For example, my domain name is devopsproject.dev,<\/strong> and I want all of my sending emails <\/code>from address<\/strong> should be the subdomain, which is email.devopsproject.dev<\/strong>.<\/p>\n

      \"aws<\/figure>\n

      Step 4: Authentication Mechanism<\/h2>\n

      The third one is an authentication mechanism, which is DomainKeys Identified Mails (DKIM)<\/strong>.<\/p>\n

      This is a recommended option, and this security feature helps the sender’s mail server to verify the domain and the receiver’s <\/strong>mail server to ensure the authenticity of the mail.<\/strong><\/p>\n

      \"aws<\/figure>\n

      Step 5: Update DNS Records<\/h2>\n

      This setup will create CNAME<\/strong>, MX<\/strong>, and TXT<\/strong> DNS records, and you can directly update them in Route 53<\/strong> if your domain is hosted in Route 53<\/a>, otherwise, you have to update the DNS records to your intended DNS server manually.<\/p>\n

      \"aws<\/figure>\n

      The DNS server will verify the records; until then, the identity will not be verified.<\/p>\n

      \"aws<\/figure>\n

      For me, it took only a few minutes to get verified, in your case it may take an hour or so, and if it is not verified, ensure your DNS records are properly stored in the DNS server.<\/p>\n

      This is how the record is stored in Route 53.<\/strong><\/p>\n

      \"route53<\/figure>\n

      Once the verification process is completed, you can see the verified<\/strong> mark on your identity status.<\/p>\n

      \"aws<\/figure>\n

      Now, you can see in the top right corner that the Send test email<\/strong> function is enabled, so you can test the email service, but one thing you have to know is that now the service is in the Sandbox<\/strong> environment.<\/p>\n

      Step 6: Sandbox Environment<\/h2>\n

      Sandbox is only used to test the email and it has email limits that only 200 emails can sent each day, also, if you want to send an email to someone, that receiver’s mail ID should be verified.<\/p>\n

      To verify the receiver’s mail ID with AWS SES, you have to follow all the steps we have done for the domain validation, but here, instead of Domain<\/strong>, we use an email address<\/strong>.<\/p>\n

      \"aws<\/figure>\n

      The receiver will get an email with a URL, and clicking that link will verify the identity.<\/p>\n

      \"email<\/figure>\n

      Once the receiver’s identity is verified, you can send test emails to that specific email address.<\/p>\n

      \"aws<\/figure>\n

      Our configurations and the testing process are completed, now is the time to get out of the Sandbox environment.<\/p>\n

      Step 7: Get Over From Sandbox Environment<\/h2>\n

      In the account dashboard,<\/strong> we can see the request production access<\/strong><\/a> tab. Click that will navigate to another page, where you have to send a request with valid information.<\/p>\n

      \"aws<\/figure>\n

      The request will take almost one day to process, after that, your limitations will be removed.<\/p>\n

      Then you can see the dashboard like this, and from now on, we won’t have to verify the receiver’s email IDs to send emails.<\/p>\n

      \"aws<\/figure>\n

      Step 8: Send Emails through AWS SES<\/h2>\n

      Navigate to the Configuration<\/strong> section and open the verified identities<\/strong>. Then click to open the domain devopsproject.dev<\/strong>.<\/p>\n

      Click the send test email<\/strong> tab, and a new page will open. Here you can compose your emails.<\/p>\n

      SES provides two Email formats, one is Formatted<\/strong> and the other one is Raw<\/strong>.<\/p>\n

      If you want to create a custom Email format, then choosing RAW<\/strong> would satisfy your preference, the Multipurpose Internet Mail Extention Standard (MIME)<\/strong> helps you create the emails.<\/p>\n

      I am doing this for testing purposes, so I am choosing a Formatted<\/strong> format to send a mail.<\/p>\n

      \"aws<\/figure>\n

      In the next step, you have to provide the from-address<\/strong>, I am giving the subdomain prefix, which is email<\/strong>.<\/p>\n

      Instead of email, you can give other prefixes like bounce, support, etc, based on your email.<\/p>\n

      In the scenario <\/strong>section, you can choose a predefined one, like successful delivery or automatic response<\/strong>, or you can choose a custom one.<\/p>\n

      Then the remaining things are the subject and body part, and if you already created a configurations set, you can choose that too, but that is optional.<\/p>\n

      \"aws<\/figure>\n

      Once you send the mail, you will get the output like this.<\/p>\n

      \"email<\/figure>\n

      One more thing I want to include in this is that we know we can create a configuration set, which rules, we can attach with the sending emails, same as we can create rules for incoming emails that you can see in the Email Receiving tab.<\/p>\n

      Conclusion<\/h2>\n

      This is just a base setup of the AWS SES, there are a lot of options available, explore them and include them when you implement them in real situations.<\/p>\n

      Understanding more about the configuration set<\/strong> and the Email-receiving<\/strong> options will give you more customization features.<\/p>\n

      Also, your Email templates<\/strong> can be stored in SES and a suppression list<\/strong> helps to add emails for bounce and complaints.<\/p>\n

      Amazon SES pricing will be calculated based on criteria such as the number of incoming and outgoing messages, dedicated IP, size of the emails, etc.<\/p>\n

      To know about the pricing, please visit the official documentation<\/a>.<\/p>\n

      \n

      Ngu\u1ed3n:<\/strong> How To Setup AWS SES: A Step-By-Step Guide \u2014 DevOpsCube<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

      Source: https:\/\/devopscube.com\/setup-aws-ses\/<\/p>\n","protected":false},"author":1,"featured_media":523,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-522","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops"],"_links":{"self":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/522","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=522"}],"version-history":[{"count":0,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/522\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/media\/523"}],"wp:attachment":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=522"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=522"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=522"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}