# Verified identities in Amazon SES Verified identities In Amazon SES, a *verified identity* is a domain or email address that you use to send or receive email. Before you can send an email using Amazon SES, you must create and verify each identity that you're going to use as a "From", "Source", "Sender", or "Return-Path" address. Verifying an identity with Amazon SES confirms that you own it and helps prevent unauthorized use. If your account is still in the Amazon SES sandbox, you also need to verify any email addresses which you plan on sending email to, unless you're sending to test inboxes provided by the [Amazon SES mailbox simulator](send-an-email-from-console.md#send-email-simulator). For more information, see [Using the mailbox simulator manually](send-an-email-from-console.md#send-email-simulator). You can create an identity by using the Amazon SES console or the Amazon SES API. The identity verification process depends on which type of identity you choose to create. **Tip** If you're a first time user of SES, you can use the [Get started wizard](setting-up.md#quick-start-verify-email-addresses) to create and verify your first identity (email address or domain). **Topics** + [ # Creating and verifying identities in Amazon SES ](creating-identities.md) + [ # Managing identities in Amazon SES ](managing-identities.md) + [ # Configuring identities in Amazon SES ](configure-identities.md) + [ # Sending test emails in Amazon SES with the simulator ](send-an-email-from-console.md) # Creating and verifying identities in Amazon SES Creating & verifying identities In Amazon SES, you can create an identity at the domain level or you can create an email address identity. These identity types aren’t mutually exclusive. In most cases, creating a domain identity eliminates the need for creating and verifying individual email address identities, unless you want to apply custom configurations to a specific email address. Whether you create a domain and utilize email addresses based on the domain, or create individual email addresses, there are benefits to both approaches. Which method you choose is dependent on your specific needs as discussed below. Creating and verifying an email address identity is the fastest way to get started in SES, but there are benefits to verifying an identity at the domain level. When you verify an email address identity, only that email address can be used to send mail, but when you verify a domain identity, you can send email from any subdomain or email address of the verified domain without having to verify each one individually. For example, if you create and verify a domain identity called example.com, you don't need to create separate subdomain identities for a.example.com, a.b.example.com, nor separate email address identities for user@example.com, user@a.example.com, and so on. However, keep in mind that an email address identity that's using the inherited verification from its domain is limited to straightforward email sending. If you want to do more advanced sending, you'll have to also explicitly verify it as an email address identity. Advanced sending includes using the email address with configuration sets, policy authorizations for delegate sending, and configurations that override the domain settings. To help clarify the verification inheritance and email sending capabilities discussed above, the following table categorizes each combination of domain/email address verification and lists the inheritance, sending level, and display status for each: | | Only domain verified | Only email address verified | Both domain & email address verified | | --- | --- | --- | --- | | Inheritance level | Subdomains and email addresses inherit verification from the parent domain. | Email address explicitly verified. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ses/latest/dg/creating-identities.html) | | Sending level | Email addresses limited to straightforward email sending. | Email address can be used in advanced sending\$1. | Email address can be used in advanced sending\$1. | | Displayed status | Console/API status: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ses/latest/dg/creating-identities.html) | Console/API status: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ses/latest/dg/creating-identities.html) | Console/API status: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ses/latest/dg/creating-identities.html) | *\$1Advanced sending includes using the email address with configuration sets, policy authorizations for delegate sending, and configurations that override the domain settings.* To send email from the same domain or email address in more than one AWS Region, you must create and verify a separate identity for each Region. You can verify as many as 10,000 identities in each Region. **When you create and verify domain and email address identities, consider the following:** + You can send email from any subdomain or email address of the verified domain without having to verify each one individually. For example, if you create and verify an identity for example.com, you don't need to create separate identities for a.example.com, a.b.example.com, user@example.com, user@a.example.com, and so on. + As specified in [RFC 1034](https://tools.ietf.org/html/rfc1034#section-3.6), each DNS label can have up to 63 characters, and the whole domain name must not exceed a total length of 255 characters. + If you verify a domain, subdomain, or email address that shares a root domain, the identity settings (such as feedback notifications) apply at the most granular level you verified. + Verified email address identity settings override verified domain identity settings. + Verified subdomain identity settings override verified domain identity settings, with lower-level subdomain settings overriding higher-level subdomain settings. For example, assume you verify user@a.b.example.com, a.b.example.com, b.example.com, and example.com. These are the verified identity settings that will be used in the following scenarios: + Emails sent from user@example.com (an email address that isn’t specifically verified) will use the settings for example.com. + Emails sent from user@a.b.example.com (an email address that is specifically verified) will use the settings for user@a.b.example.com. + Emails sent from user@b.example.com (an email address that isn’t specifically verified) will use the settings for b.example.com. + You can add labels to verified email addresses without performing additional verification steps. To add a label to an email address, add a plus sign (\$1) between the account name and the "at" sign (@), followed by a text label. For example, if you already verified sender@example.com, you can use sender\$1myLabel@example.com as the "From" or "Return-Path" address for your emails. You can use this feature to implement Variable Envelope Return Path (VERP). Then you can use VERP to detect and remove undeliverable email addresses from your mailing lists. + Domain names are case-insensitive. If you verify example.com, you can send from EXAMPLE.com also. + Email addresses *are* case sensitive. If you verify sender@EXAMPLE.com, you can't send email from sender@example.com unless you verify sender@example.com as well. + In each AWS Region, you can verify as many as 10,000 identities (domains and email addresses, in any combination). **Tip** If you're a first time user of SES, you can use the [Get started wizard](setting-up.md#quick-start-verify-email-addresses) to create and verify your first identity (email address or domain). **Topics** + [ ## Creating a domain identity ](#verify-domain-procedure) + [ ## Verifying a DKIM domain identity with your DNS provider ](#just-verify-domain-proc) + [ ## Creating an email address identity ](#verify-email-addresses-procedure) + [ ## Verifying an email address identity ](#just-verify-email-proc) + [ ## Create and verify an identity and assign a default configuration set at the same time ](#default-config-set-at-create-api) + [ ## Using custom verification email templates ](#send-email-verify-address-custom) ## Creating a domain identity Creating a domain identity Part of creating a domain identity is configuring its DKIM-based verification. DomainKeys Identified Mail (DKIM) is an email authentication method that Amazon SES uses to verify domain ownership, and receiving mail servers use to validate email authenticity. You can choose to configure DKIM by using either Easy DKIM or Bring Your Own DKIM (BYODKIM), and depending on your choice, you'll have to configure the signing key length of the private key as follows: + **Easy DKIM** - either accept the Amazon SES default of 2048 bits, or override it by selecting 1024 bits. + **BYODKIM** - private key length must be at least 1024 bits and up to 2048-bits. See [DKIM signing key length](send-email-authentication-dkim.md#send-email-authentication-dkim-1024-2048) to learn more about DKIM signing key lengths and how to change them. The following procedure shows you how to create a domain identity using the Amazon SES console. + If you've already created your domain and just need to verify it, skip to the procedure [Verifying a DKIM domain identity with your DNS provider](#just-verify-domain-proc) on this page. **To create a domain identity** 1. Sign in to the AWS Management Console and open the Amazon SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the navigation pane, under **Configuration**, choose **Identities**. 1. Choose **Create identity**. 1. Under **Identity details**, select **Domain** as the type of identity you want to create. You must have access to the domain’s DNS settings to complete the domain verification process. 1. Enter the name of the domain or subdomain in the **Domain** field. **Tip** If your domain is *www.example.com*, enter *example.com* as your domain. Don't include the "www." part, because the domain verification process won't succeed if you do. 1. (Optional) If you want to **Assign a default configuration set**, select the check box. 1. For **Default configuration set**, select the existing configuration set that you want to assign to your identity. If you haven’t created any configuration sets yet, see [Using configuration sets in Amazon SES](using-configuration-sets.md). **Note** Amazon SES only defaults to the assigned configuration set when no other set is specified at the time of sending. If a configuration set is specified, Amazon SES applies the specified set in place of the default set. 1. (Optional) If you want to **Use a custom MAIL FROM domain**, select the check box and complete the following steps. For more information, see [Using a custom MAIL FROM domain](mail-from.md). 1. For **MAIL FROM domain**, enter the subdomain that you want to use as the MAIL FROM domain. This must be a subdomain of the domain identity that you’re verifying. The MAIL FROM domain shouldn't be a domain from which you send email. 1. For **Behavior on MX failure**, indicate which action Amazon SES should take if it can’t find the required MX record at the time of sending. Choose one of the following options: + **Use default MAIL FROM domain** - If the custom MAIL FROM domain's MX record is not set up correctly, Amazon SES will use a subdomain of amazonses.com. The subdomain varies based on the AWS Region in which you use Amazon SES. + **Reject message** - If the custom MAIL FROM domain's MX record is not set up correctly, Amazon SES will return a `MailFromDomainNotVerified` error. If you choose this option, emails that you attempt to send from this domain are automatically rejected. 1. For **Publish DNS records to Route53**, if your domain is hosted through Amazon Route 53, you have the option to let SES publish the associated TXT and MX records at the time of creation by leaving **Enabled** checked. If you'd rather publish these records later, clear the **Enabled** checkbox. (You can come back at a later time to publish the records to Route 53 by editing the identity - see [Edit an identity using the SES console](edit-verified-domain.md).) 1. (Optional) To configure customized DKIM-based verification, other than the SES default setting which uses [Easy DKIM](send-email-authentication-dkim-easy.md) *with a 2048 bit signing length*, under **Verifying your domain**, expand **Advanced DKIM settings** and choose the type of DKIM you want to configure: 1. **Easy DKIM**: 1. Under **Identity type**, choose **Easy DKIM**. 1. In the **DKIM signing key length** field, choose either [**RSA\$12048\$1BIT** or **RSA\$11024\$1BIT**](send-email-authentication-dkim.md#send-email-authentication-dkim-1024-2048). 1. For **Publish DNS records to Route53**, if your domain is hosted through Amazon Route 53, you have the option to let SES publish the associated CNAME records at the time of creation by leaving **Enabled** checked. If you'd rather publish these records later, clear the **Enabled** checkbox. (You can come back at a later time to publish the records to Route 53 by editing the identity - see [Edit an identity using the SES console](edit-verified-domain.md).) 1. **Deterministic Easy DKIM (DEED)**: **Tip** This form of DKIM is to be used if you're creating a Global (replica) identity. DEED will utilize the Easy DKIM setup of an existing identity of the same name from a parent region and sign the new identity without requiring you to perform additional DNS setup. For more information, see [DEED](send-email-authentication-dkim-deed.md). 1. Under **Identity type**, choose **Deterministic Easy DKIM**. 1. From the **Parent region** dropdown menu, select a parent region where an Easy DKIM-signed identity with the same name as you entered for your Global (replica) identity resides. (Your replica region defaults to the region you signed into the SES console with.) 1. **Provide DKIM authentication token (BYODKIM)**: 1. Ensure you've already generated a public-private key pair and have added the public key to your DNS host provider. For more information, see [Provide your own DKIM authentication token (BYODKIM) in Amazon SES](send-email-authentication-dkim-bring-your-own.md). 1. Under **Identity type**, choose **Provide DKIM authentication token (BYODKIM)**. 1. For **Private key**, paste the private key you generated from your public-private key pair. The private key must use [at least 1024-bit RSA encryption and up to 2048-bit](send-email-authentication-dkim.md#send-email-authentication-dkim-1024-2048), and must be encoded using base64 [(PEM)](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail) encoding. **Note** You have to delete the first and last lines (`-----BEGIN PRIVATE KEY-----` and `-----END PRIVATE KEY-----`, respectively) of the generated private key. Additionally, you have to remove the line breaks in the generated private key. The resulting value is a string of characters with no spaces or line breaks. 1. For **Selector name**, enter the name of the selector to be specified in your domain’s DNS settings. 1. Ensure that the **Enabled** box is checked in the **DKIM signatures** field. 1. (Optional) Add one or more **Tags** to your domain identity by including a tag key and an optional value for the key: 1. Choose **Add new tag** and enter the **Key**. You can optionally add a **Value** for the tag. 1. Repeat for additional tags not to exceed 50, or choose **Remove** to remove tags. 1. Choose **Create identity**. Now that you’ve created and configured your domain identity with DKIM, you must complete the verification process with your DNS provider - proceed to [Verifying a DKIM domain identity with your DNS provider](#just-verify-domain-proc) and follow the DNS authentication procedures for the type of DKIM you configured your identity with. **Note** ## Verifying a DKIM domain identity with your DNS provider Verifying a domain identity After you’ve created your domain identity configured with DKIM, you must complete the verification process with your DNS provider by following the respective authentication procedures for the type of DKIM you chose. If you haven't created a domain identity, see [Creating a domain identity](#verify-domain-procedure). **Note** Verifying a domain identity requires access to the domain’s DNS settings. Changes to these settings can take up to 72 hours to propagate. If you created a Global (replica) identity using Deterministic Easy DKIM (DEED), no additional DNS setup is required—you can skip this step. For more information, see [DEED](send-email-authentication-dkim-deed.md). **To verify a DKIM domain identity with your DNS provider** 1. From the **Loaded identities** table, select the domain you want to verify. 1. On the **Authentication** tab of the identity details page, expand **Publish DNS records**. 1. Depending on which flavor of DKIM you configured your domain with, **Easy DKIM** or **BYODKIM**, follow the respective instructions: ------ #### [ Easy DKIM ] **To verify a domain configured with Easy DKIM** 1. From the **Publish DNS records** table, copy the three CNAME records that appear in this section to be published (added) to your DNS provider. Alternatively, you can choose **Download .csv record set** to save a copy of the records to your computer. The following image shows an example of the CNAME records to publish to your DNS provider. ![\[\]](http://docs.aws.amazon.com/ses/latest/dg/images/dkim_records.png) 1. Add the CNAME records to your domain’s DNS settings respective of your DNS host provider: + **All DNS host providers** *(excluding Route 53)* – Login to your domain’s DNS or web hosting provider, and then add the CNAME records containing the values that you copied or saved previously. Different providers have different procedures for updating DNS records. See the [DNS/Hosting provider table](#dns-hosting-providing-table) following these procedures. **Note** A small number of DNS providers don't allow you to include underscores (\$1) in record names. However, the underscore in the DKIM record name is required. If your DNS provider doesn't allow you to enter an underscore in the record name, contact the provider's customer support team for assistance. + **Route 53 as your DNS host provider** – If you use Route 53 on the same account that you use when you send email using SES, and the domain is registered, SES automatically updates the DNS settings for your domain if you enabled SES to publish them at the time of creation. Otherwise, you can easily publish them to Route 53 with a button click after creation - see [Edit an identity using the SES console](edit-verified-domain.md). If your DNS settings don’t update automatically, or you want to add CNAME records to Route 53 that aren't on the same account you use when you send email using SES, complete the procedures in [Editing records](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-editing.html). + **If you're not sure who your DNS provider is** – Ask your system administrator for more information. ------ #### [ BYODKIM ] **To verify a domain configured with BYODKIM** 1. To recap, when you created your domain with BYODKIM, or you configured an existing domain with BYODKIM, you added the private key (from your [self-generated public-private key pair](send-email-authentication-dkim-bring-your-own.md)) and selector name prefix into their respective fields on the SES console's Advance DKIM Settings page. Now you must complete the verification process by updating the following records for your DNS host provider. 1. From the **Publish DNS records** table, copy the selector name record that appears in the **Name** column to be published (added) to your DNS provider. Alternatively, you can choose **Download .csv record set** to save a copy of it to your computer. The following image shows an example of the selector name record to publish to your DNS provider. ![\[\]](http://docs.aws.amazon.com/ses/latest/dg/images/byodkim_records.png) 1. Login to your domain’s DNS or web hosting provider, and then add the selector name record you copied or saved previously. Different providers have different procedures for updating DNS records. See the [DNS/Hosting provider table](#dns-hosting-providing-table) following these procedures. **Note** A small number of DNS providers don't allow you to include underscores (\$1) in record names. However, the underscore in the DKIM record name is required. If your DNS provider doesn't allow you to enter an underscore in the record name, contact the provider's customer support team for assistance. 1. If you haven't done so already, be sure to add the public key from your from your [self-generated public-private key pair](send-email-authentication-dkim-bring-your-own.md) to your domain's DNS or web hosting provider. Note that in the **Publish DNS records** table, the public key record that appears in the **Value** column only displays, “p=*customerProvidedPublicKey*”, as a placeholder for the public key value you saved to your computer or supplied to your DNS provider. **Note** When you publish (add) your public key to your DNS provider, it must be formatted as follows: You have to delete the first and last lines (`-----BEGIN PUBLIC KEY-----` and `-----END PUBLIC KEY-----`, respectively) of the generated public key. Additionally, you have to remove the line breaks in the generated public key. The resulting value is a string of characters with no spaces or line breaks. You must include the `p=` prefix as shown in the *Value* column in the **Publish DNS records** table. ------ **Tip** When adding CNAME records to your DNS configuration: Use the exact record names as provided in the SES console. Do not add any additional underscores (`_`) at the beginning of the CNAME record names. The `_domainkey` portion is part of the record name and should be used exactly as shown. Example showing correct vs incorrect CNAME Record implementation: *Correct:* `abc123._domainkey.domain.com` *Incorrect:* `_abc123._domainkey.domain.com` 1. It can take up to 72 hours for changes to DNS settings to propagate. As soon as Amazon SES detects all of the required DKIM records in your domain’s DNS settings, the verification process is complete. Your domain’s **DKIM configuration** appears as **Successful** and the **Identity status** appears as **Verified**. 1. If want to configure and verify a [custom MAIL FROM domain](mail-from.md), follow the procedures in [Configuring your custom MAIL FROM domain](mail-from.md#mail-from-set). The following table includes links to the documentation for a few widely used DNS providers. This list isn't exhaustive and doesn't signify endorsement; likewise, if your DNS provider isn't listed, it doesn't imply you can't use the domain with Amazon SES. | DNS/Hosting provider | Documentation link | | --- | --- | | GoDaddy | [Add a CNAME record](https://www.godaddy.com/help/add-a-cname-record-19236) (external link) | | DreamHost | [How do I add custom DNS records?](https://help.dreamhost.com/hc/en-us/articles/215414867-How-do-I-add-custom-DNS-records-) (external link) | | Cloudflare | [Managing DNS records in Cloudflare](https://support.cloudflare.com/hc/en-us/articles/360019093151) (external link) | | HostGator | [Manage DNS Records with HostGator/eNom](https://www.hostgator.com/help/article/manage-dns-records-with-hostgatorenom) (external link) | | Namecheap | [How do I add TXT/SPF/DKIM/DMARC records for my domain? ](https://www.namecheap.com/support/knowledgebase/article.aspx/317/2237/how-do-i-add-txtspfdkimdmarc-records-for-my-domain) (external link) | | Names.co.uk | [Changing your domains DNS Settings](https://www.names.co.uk/support/1156-changing_your_domains_dns_settings.html) (external link) | | Wix | [Adding or Updating CNAME Records in Your Wix Account](https://support.wix.com/en/article/adding-or-updating-cname-records-in-your-wix-account) (external link) | ### Troubleshooting domain verification If you completed the steps above, but your domain isn't verified after 72 hours, check the following: + Make sure that you entered the values for the DNS records in the correct fields. Some DNS providers refer to the **Name/host** field as **Host** or **Hostname**. In addition, some providers refer to the **Record value** field as **Points to** or **Result**. + Make sure that your provider didn't automatically append your domain name to the **Name/host** value that you entered in the DNS record. Some providers append the domain name without indicating that they've done so. If your provider appended your domain name to the **Name/host** value, remove the domain name from the end of the value. You can also try adding a period to the end of the value in the DNS record. This period indicates to the provider that the domain name is fully qualified. + The underscore character (\$1) is required in the **Name/host** value of each DNS record. If your provider doesn't allow underscores in DNS record names, contact the provider's customer support department for additional assistance. + The validation records that you have to add to your domain’s DNS settings are different for each AWS Region. If you want to use a domain to send email from multiple AWS Regions, you have to create and verify a separate domain identity for each of those Regions. ## Creating an email address identity Creating an email address identity Complete the following procedure to create an email address identity by using the Amazon SES console. **To create an email address identity (console)** 1. Sign in to the AWS Management Console and open the Amazon SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the navigation pane, under **Configuration**, choose **Identities**. 1. Choose **Create identity**. 1. Under **Identity details**, choose **Email address** as the identity type you want to create. 1. For **Email address**, enter the email address that you want to use. The email address must be an address that’s able to receive mail and that you have access to. 1. (Optional) If you want to **Assign a default configuration set**, select the check box. 1. For **Default configuration set**, select the existing configuration set that you want to assign to your identity. If you haven’t created any configuration sets yet, see [Using configuration sets in Amazon SES](using-configuration-sets.md). **Note** Amazon SES only defaults to the assigned configuration set when no other set is specified at the time of sending. If a configuration set is specified, Amazon SES applies the specified set in place of the default set. 1. (Optional) Add one or more **Tags** to your domain identity by including a tag key and an optional value for the key: 1. Choose **Add new tag** and enter the **Key**. You can optionally add a **Value** for the tag. 1. Repeat for additional tags not to exceed 50, or choose **Remove** to remove tags. 1. To create your email address identity, choose **Create identity**. After it's created, you should receive a verification email within five minutes. The next step is to verify your email address by following the verification procedure in the next section. **Note** You can customize the messages that are sent to the email addresses you attempt to verify. For more information, see [Using custom verification email templates](#send-email-verify-address-custom). Now that you’ve created your email address identity, you must complete the verification process - proceed to [Verifying an email address identity](#just-verify-email-proc). ## Verifying an email address identity Verifying an email address identity After you’ve created your email address identity, you must complete the verification process. If you haven't created an email address identity, see [Creating an email address identity](#verify-email-addresses-procedure). **To verify an email address identity** 1. Check the inbox of the email address used to create your identity and look for an email from no-reply-aws@amazon.com. 1. Open the email and click the link to complete the verification process for the email address. After it's complete, the **Identity status** updates to **Verified**. ### Troubleshooting email address verification If you don't receive the verification email within five minutes of creating your identity, try the following troubleshooting steps: + Make sure you entered the email address correctly. + Make sure the email address that you're attempting to verify can receive email. You can test this by using another email address to send a test email to the address that you want to verify. + Check your junk mail folder. + The link in the verification email expires after 24 hours. To send a new verification email, choose **Resend** at the top of the identity details page. ## Create and verify an identity and assign a default configuration set at the same time Create & verify an identity and assign a default configuration set at the same time (API) You can use the [CreateEmailIdentity](https://docs.aws.amazon.com/ses/latest/APIReference-V2/API_CreateEmailIdentity.html) operation in the Amazon SES API v2 to create a new email identity and set its default configuration set at the same time. **Note** Before you complete the procedure in this section, you have to install and configure the AWS CLI. For more information, see the [AWS Command Line Interface User Guide](https://docs.aws.amazon.com/cli/latest/userguide/). **To set a default configuration set using the AWS CLI** + At the command line, enter the following command to use the [CreateEmailIdentity](https://docs.aws.amazon.com/ses/latest/APIReference-V2/API_CreateEmailIdentity.html) operation. ``` aws sesv2 create-email-identity --email-identity ADDRESS-OR-DOMAIN --configuration-set-name CONFIG-SET ``` In the preceding commands, replace *ADDRESS-OR-DOMAIN* with the email identity that you want to verify. Replace *CONFIG-SET* with the name of the configuration set you want to set as the default configuration set for the identity. If the command executes successfully, it exits without providing any output. **To verify your email address** 1. Check the inbox for the email address that you're verifying. You'll receive a message with the following subject line: "Amazon Web Services - Email Address Verification Request in region *RegionName*," where *RegionName* is the name of the AWS Region that you attempted to verify the email address in. Open the message, and then click the link in it. **Note** The link in the verification message expires 24 hours after the message was sent. If 24 hours have passed since you received the verification email, repeat steps 1–5 to receive a verification email with a valid link. 1. In the Amazon SES console, under **Identity Management**, choose **Email Addresses**. In the list of email addresses, locate the email address you're verifying. If the email address was verified, the value in the **Status** column is "verified". **To verify your domain** If you entered a domain name for the `--email-identity` parameter in the above command line procedure, see [Verifying a domain identity](#just-verify-domain-proc) for more information. ## Using custom verification email templates Using custom verification email templates When you attempt to verify an email address, Amazon SES sends an email to that address that resembles the example shown in the following image. ![\[Email verification request from Amazon SES and Pinpoint with confirmation link and instructions.\]](http://docs.aws.amazon.com/ses/latest/dg/images/verification_email_example.png) Several Amazon SES customers build applications (such as email marketing suites or ticketing systems) that send email through Amazon SES on behalf of their own customers. For the end users of these applications, the email verification process can be confusing: the verification email uses Amazon SES branding, rather than the branding of the application, and those end users never signed up to use Amazon SES directly. If your Amazon SES use case requires your customers to have their email addresses verified for use with Amazon SES, you can create customized verification emails. These customized emails help reduce customer confusion and increase the rates at which your customers complete the registration process. **Note** To use this feature, your Amazon SES account has to be out of the sandbox. For more information, see [Request production access (Moving out of the Amazon SES sandbox)](request-production-access.md). **Topics** + [ ### Creating a custom verification email template ](#send-email-verify-address-custom-creating) + [ ### Editing a custom verification email template ](#send-email-verify-address-custom-editing) + [ ### Sending verification emails using custom templates ](#send-email-verify-address-custom-sending) + [ ### Custom verification email frequently asked questions ](#send-email-verify-address-custom-faq) ### Creating a custom verification email template To create a custom verification email, use the `CreateCustomVerificationEmailTemplate` API operation. This operation takes the following inputs: **** | Attribute | Description | | --- | --- | | TemplateName | The name of the template. The name you specify must be unique. | | FromEmailAddress | The email address that the verification email is sent from. The address or domain you specify must be verified for use with your Amazon SES account. The `FromEmailAddress` attribute doesn't support display names (also known as "friendly from" names). | | TemplateSubject | The subject line of the verification email. | | TemplateContent | The body of the email. The email body can contain HTML, with certain restrictions. For more information, see [Custom verification email frequently asked questions](#send-email-verify-address-custom-faq). | | SuccessRedirectionURL | The URL that users are sent to, if their email addresses are successfully verified. | | FailureRedirectionURL | The URL that users are sent to, if their email addresses are not successfully verified. | You can use the AWS SDKs or the AWS CLI to create a custom verification email template with the `CreateCustomVerificationEmailTemplate` operation. To learn more about the AWS SDKs, see [Tools for Amazon Web Services](https://aws.amazon.com/tools/#sdk). For more information about the AWS CLI, see [AWS Command Line Interface.](https://aws.amazon.com/cli) The following section includes procedures for creating a custom verification email using the AWS CLI. These procedures assume that you have installed and configured the AWS CLI. For more information about installing and configuring the AWS CLI, see the [AWS Command Line Interface User Guide](https://docs.aws.amazon.com/cli/latest/userguide/). **Note** To complete the procedure in this section, you must use version 1.14.6 or later of the AWS CLI. For best results, upgrade to the latest version of the AWS CLI. For more information about updating the AWS CLI, see [Installing the AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/installing.html) in the AWS Command Line Interface User Guide. 1. In a text editor, create a new file. Paste the following content into the editor: ``` { "TemplateName": "SampleTemplate", "FromEmailAddress": "sender@example.com", "TemplateSubject": "Please confirm your email address", "TemplateContent": "

Ready to start sending email with ProductName?

We here at Example Corp are happy to have you on board! There's just one last step to complete before you can start sending email. Just click the following link to verify your email address. Once we confirm that you're really you, we'll give you some additional information to help you get started with ProductName.

", "SuccessRedirectionURL": "https://www.example.com/verifysuccess", "FailureRedirectionURL": "https://www.example.com/verifyfailure" } ``` **Important** To make the preceding example easier to read, the `TemplateContent` attribute contains line breaks. If you paste the preceding example into your text file, remove the line breaks before proceeding. Replace the values of `TemplateName`, `FromEmailAddress`, `TemplateSubject`, `TemplateContent`, `SuccessRedirectionURL`, and `FailureRedirectionURL` with your own values. **Note** The email address that you specify for the `FromEmailAddress` parameter has to be verified, or has to be an address on a verified domain. For more information, see [Verified identities in Amazon SES](verify-addresses-and-domains.md). When you finish, save the file as `customverificationemail.json`. 1. At the command line, type the following command to create the custom verification email template: ``` aws sesv2 create-custom-verification-email-template --cli-input-json file://customverificationemail.json ``` 1. (Optional) You can confirm that the template was created by typing the following command: ``` aws sesv2 list-custom-verification-email-templates ``` ### Editing a custom verification email template You can edit a custom verification email template by using the `UpdateCustomVerificationEmailTemplate` operation. This operation accepts the same inputs as the `CreateCustomVerificationEmailTemplate` operation (that is, the `TemplateName`, `FromEmailAddress`, `TemplateSubject`, `TemplateContent`, `SuccessRedirectionURL`, and `FailureRedirectionURL` attributes). However, with the `UpdateCustomVerificationEmailTemplate` operation, none of these attributes are required. When you pass a value for `TemplateName` that is the same as the name of an existing custom verification email template, the attributes you specify overwrite the attributes that were originally in the template. ### Sending verification emails using custom templates After you create at least one custom verification email template, you can send it to your customers by calling the [SendCustomVerificationEmail](http://docs.aws.amazon.com/ses/latest/APIReference/API_SendCustomVerificationEmail.html) API operation. You can call the `SendCustomVerificationEmail` operation by using any of the AWS SDKs or the AWS CLI. The `SendCustomVerificationEmail` operation takes the following inputs: **** | Attribute | Description | | --- | --- | | EmailAddress | The email address that is being verified. | | TemplateName | The name of the custom verification email template that is sent to email address that is being verified. | | ConfigurationSetName | (Optional) The name of a configuration set to use when sending the verification email. | For example, assume your customers register for your service using a form in your application. When the customer completes the form and submits it, your application calls the `SendCustomVerificationEmail` operation, passing the customer's email address and the name of the template you want to use. Your customer receives an email that uses the customized email template you created. Amazon SES automatically adds a unique link to the recipient, and also a brief disclaimer. The following image shows a sample verification email that uses the template created in [Creating a custom verification email template](#send-email-verify-address-custom-creating). ![\[Email verification message with instructions and a link to confirm the recipient's address.\]](http://docs.aws.amazon.com/ses/latest/dg/images/cve_sample_message.png) ### Custom verification email frequently asked questions Custom verification email FAQs This section contains answers to frequently asked questions about the custom verification email template feature. #### Q1. How many custom verification email templates can I create? You can create up to 50 custom verification email templates per Amazon SES account. #### Q2. How do custom verification emails appear to recipients? Custom verification emails include the content you specified when you created the template, followed by a link that recipients must click to verify their email addresses. #### Q3. Can I preview the custom verification email? To preview a custom verification email, use the `SendCustomVerificationEmail` operation to send a verification email to an address you own. If you don't click the verification link, Amazon SES does not create a new identity. If you do click the verification link, you can optionally delete the newly created identity by using the `DeleteIdentity` operation. #### Q4. Can I include images in my custom verification email templates? You can embed images in the HTML for your templates by using base64 encoding. When you embed images in this way, Amazon SES automatically converts them into attachments. You can encode an image at the command line by issuing one of the following commands: ------ #### [ Linux, macOS, or Unix ] ``` base64 -i imagefile.png | tr -d '\n' > output.txt ``` ------ #### [ Windows ] ``` certutil -encodehex -f imagefile.png output.txt 0x40000001 ``` ------ Replace `imagefile.png` with the name of the file you want to encode. In both of the commands above, the base64 encoded image is saved to `output.txt`. You can embed the base64-encoded image by including the following in the HTML for the template: `` In the previous example, replace `png` with the file type of the encoded image (such as jpg or gif), and replace `base64EncodedImage` with the base64 encoded image (that is, the contents of `output.txt` from one of the preceding commands). #### Q5. Are there any limits to the content that I can include in custom verification email templates? Custom verification email templates can't exceed 10 MB in size. Additionally, custom verification email templates that contain HTML can only use the tags and attributes listed in the following table. | HTML tag | Allowed attributes | | --- | --- | | abbr | class, id, style, title | | acronym | class, id, style, title | | address | class, id, style, title | | area | class, id, style, title | | b | class, id, style, title | | bdo | class, id, style, title | | big | class, id, style, title | | blockquote | cite, class, id, style, title | | body | class, id, style, title | | br | class, id, style, title | | button | class, id, style, title | | caption | class, id, style, title | | center | class, id, style, title | | cite | class, id, style, title | | code | class, id, style, title | | col | class, id, span, style, title, width | | colgroup | class, id, span, style, title, width | | dd | class, id, style, title | | del | class, id, style, title | | dfn | class, id, style, title | | dir | class, id, style, title | | div | class, id, style, title | | dl | class, id, style, title | | dt | class, id, style, title | | em | class, id, style, title | | fieldset | class, id, style, title | | font | class, id, style, title | | form | class, id, style, title | | h1 | class, id, style, title | | h2 | class, id, style, title | | h3 | class, id, style, title | | h4 | class, id, style, title | | h5 | class, id, style, title | | h6 | class, id, style, title | | head | class, id, style, title | | hr | class, id, style, title | | html | class, id, style, title | | i | class, id, style, title | | img | align, alt, class, height, id, src, style, title, width | | input | class, id, style, title | | ins | class, id, style, title | | kbd | class, id, style, title | | label | class, id, style, title | | legend | class, id, style, title | | li | class, id, style, title | | map | class, id, style, title | | menu | class, id, style, title | | ol | class, id, start, style, title, type | | optgroup | class, id, style, title | | option | class, id, style, title | | p | class, id, style, title | | pre | class, id, style, title | | q | cite, class, id, style, title | | s | class, id, style, title | | samp | class, id, style, title | | select | class, id, style, title | | small | class, id, style, title | | span | class, id, style, title | | strike | class, id, style, title | | strong | class, id, style, title | | sub | class, id, style, title | | sup | class, id, style, title | | table | class, id, style, summary, title, width | | tbody | class, id, style, title | | td | abbr, axis, class, colspan, id, rowspan, style, title, width | | textarea | class, id, style, title | | tfoot | class, id, style, title | | th | abbr, axis, class, colspan, id, rowspan, scope, style, title, width | | thead | class, id, style, title | | tr | class, id, style, title | | tt | class, id, style, title | | u | class, id, style, title | | ul | class, id, style, title, type | | var | class, id, style, title | **Note** Custom verification email templates can't include comment tags. #### Q6. How many verified email addresses can exist in my account? Your Amazon SES account can have up to 10,000 verified identities in each AWS Region. In Amazon SES, *identities* include both verified domains and email addresses. #### Q7. Can I create custom verification email templates using the Amazon SES console? Currently, it's only possible to create, edit, and delete custom verification emails using the Amazon SES API. #### Q8. Can I track open and click events that occur when customers receive custom verification emails? Custom verification emails can't include open or click tracking. #### Q9. Can custom verification emails include custom headers? Custom verification emails can't include custom headers. #### Q10. Can I remove the text that appears at the bottom of custom verification emails? The following text is automatically added to the end of every custom verification email and can't be removed: *If you did not request to verify this email address, please disregard this message. * #### Q11. Are custom verification emails DKIM-signed? In order for verification emails to be DKIM-signed, the email address that you specify in the `FromEmailAddress` attribute when you create the verification email template must be configured to generate a DKIM signature. For more information about setting up DKIM for domains and email addresses, see [Authenticating Email with DKIM in Amazon SES](send-email-authentication-dkim.md). #### Q12. Why don't the custom verification email template API operations appear in the SDK or CLI? If you're unable to use the custom verification email template operations in an SDK or the AWS CLI, you may be using an older version of the SDK or CLI. The custom verification email template operations are available in the following SDKs and CLIs: + Version 1.14.6 or later of the AWS Command Line Interface + Version 3.3.205.0 or later of the AWS SDK for .NET + Version 1.3.20170531.19 or later of the AWS SDK for C\$1\$1 + Version 1.12.43 or later of the AWS SDK for Go + Version 1.11.245 or later of the AWS SDK for Java + Version 2.166.0 or later of the AWS SDK for JavaScript + Version 3.45.2 or later of the AWS SDK for PHP + Version 1.5.1 or later of the AWS SDK for Python (Boto) + Version 1.5.0 or later of the `aws-sdk-ses` gem in the AWS SDK for Ruby #### Q13. Why do I receive `ProductionAccessNotGranted` errors when I send custom verification emails? The `ProductionAccessNotGranted` error indicates that your account is still in the Amazon SES sandbox. You can only send custom verification emails if your account has been removed from the sandbox. For more information, see [Request production access (Moving out of the Amazon SES sandbox)](request-production-access.md). # Managing identities in Amazon SES Managing identities In the Amazon SES console, you can view your created identities for each AWS Region, open an identity to see and edit its detail settings, associate a default configuration set, or delete one or more identities. **Note** The procedures referenced in this section apply only to identities in the selected AWS Region. To manage identities that were created in more than one Region, repeat the procedures for each AWS Region. **Topics** + [ # View identities using the SES console ](view-verified-domains.md) + [ # Delete an identity using the SES console ](remove-verified-domain.md) + [ # Edit an identity using the SES console ](edit-verified-domain.md) + [ # Edit an identity to use a default configuration set using the SES API ](managing-configuration-sets-default-adding.md) + [ # Retrieve the default configuration set used by the identity using the SES API ](managing-configuration-sets-default-returning.md) + [ # Override the current default configuration set used by the identity using the SES API ](managing-configuration-sets-default-overriding.md) # View identities using the SES console View identities using the console You can use the Amazon SES console to view domain and email address identities that are verified or are pending verification. You can also view those identifies for which verification was unsuccessful. **To view your domain and email address identities** 1. Sign in to the AWS Management Console and open the Amazon SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the console, use the Region selector to choose the AWS Region for which you want to view your list of identities. **Note** This procedure only displays a list of identities for the selected AWS Region. 1. In the navigation pane, under **Configuration**, choose **Verified identities**. The **Loaded identities** table displays both domain and email address identities. The **Status** column displays whether an identity has been verified, is pending verification, or has failed the verification process - definitions of all possible status values are as follows: + **Verified** – your identity is successfully verified for sending in SES. + **Failure** – SES was unable to verify your identity. If it's a domain, it means SES was unable to detect the DNS records within 72 hours. If it's an email address, it means the verification email that was sent to the email address was not acknowledged within 24 hours. + **Pending** – SES is still trying to verify the identity. + **Temporary Failure** – for a previously verified domain, SES will periodically check for the DNS record required for verification. If at some point, SES is unable to detect the record, the status would change to *Temporary Failure*. SES will recheck for the DNS record for 72 hours, and if it’s unable to detect the record, the domain status would change to *Failure*. If it’s able to detect the record, the domain status would change to *Verified*. + **Not started** – you have not yet started the verification process. 1. To sort identities by verification status, choose the **Status** column. 1. To view an identity’s details page, select the identity that you want to view. # Delete an identity using the SES console Delete an identity using the console You can use the Amazon SES console to remove a domain or email address identity from your account in the selected AWS Region. **To remove a domain or email address identity** 1. Sign in to the AWS Management Console and open the Amazon SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the console, use the Region selector to choose the AWS Region from which you want to delete one or more identities. 1. In the navigation pane, under **Configuration**, choose **Verified identities**. The **Loaded identities** table displays a list of both domain and email address identities. 1. In the **Identity** column, select the identity that you want to delete. You can delete multiple identities by checking the box next to each identity that you want to delete. 1. Choose **Delete**. # Edit an identity using the SES console Edit an identity using the console You can use the Amazon SES console to edit a domain or email address identity in your account in the selected AWS Region. **To edit a domain or email address identity** 1. Sign in to the AWS Management Console and open the Amazon SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the console, use the Region selector to choose the AWS Region from which you want to edit one or more identities. 1. In the navigation pane, under **Configuration**, choose **Verified identities**. The **Loaded identities** table displays a list of both domain and email address identities. 1. In the **Identity** column, select the identity that you want to edit (by clicking directly on the identity name as opposed to selecting its checkbox). 1. On the identity's detail page, select the tab containing the categories you'd like to edit. 1. In any of the selected tab's categorical containers, choose the **Edit** button of the attribute you wish to edit, make your changes, then choose **Save changes**. 1. If you wish to edit attributes under the **Authentication** tab and your domain identity is hosted in Amazon Route 53, and you haven't already published its DNS records, there will be a **Publish DNS records to Route53** button (next to the **Edit** button) in either or both of the **DomainKeys Identified Mail (DKIM)** or **Custom MAIL FROM domain** containers. **Note** The **Authentication** tab is only present when your account has a verified domain or an email address that uses a verified domain in your account. 1. You can publish the DNS records directly from the **Publish DNS records to Route53** button - just click it, a confirmation banner will be displayed, and the **Publish DNS records to Route53** button will no longer be visible for the respective container. 1. Repeat steps 5 & 6 for each attribute of the identity you'd like to edit. # Edit an identity to use a default configuration set using the SES API You can use the [PutEmailIdentityConfigurationSetAttributes](https://docs.aws.amazon.com/ses/latest/APIReference-V2/API_PutEmailIdentityConfigurationSetAttributes.html) operation to add or remove a default configuration set from an existing email identity. **Note** Before you complete the procedure in this section, you have to install and configure the AWS CLI. For more information, see the [AWS Command Line Interface User Guide](https://docs.aws.amazon.com/cli/latest/userguide/). **To add a default configuration set using the AWS CLI** + At the command line, enter the following command to use the [PutEmailIdentityConfigurationSetAttributes](https://docs.aws.amazon.com/ses/latest/APIReference-V2/API_PutEmailIdentityConfigurationSetAttributes.html) operation. ``` aws sesv2 put-email-identity-configuration-set-attributes --email-identity ADDRESS-OR-DOMAIN --configuration-set-name CONFIG-SET ``` In the preceding commands, replace *ADDRESS-OR-DOMAIN* with the email identity that you want to verify. Replace *CONFIG-SET* with the name of the configuration set you wish to set as the identity's default configuration set. If the command executes successfully, it exits without providing any output. **To remove a default configuration set using the AWS CLI** + At the command line, enter the following command to use the [PutEmailIdentityConfigurationSetAttributes](https://docs.aws.amazon.com/ses/latest/APIReference-V2/API_PutEmailIdentityConfigurationSetAttributes.html) operation. ``` aws sesv2 put-email-identity-configuration-set-attributes --email-identity ADDRESS-OR-DOMAIN ``` In the preceding commands, replace *ADDRESS-OR-DOMAIN* with the email identity that you want to verify. If the command executes successfully, it exits without providing any output. # Retrieve the default configuration set used by the identity using the SES API You can use the [GetEmailIdentity](https://docs.aws.amazon.com/ses/latest/APIReference-V2/API_GetEmailIdentity.html) operation to return the default configuration set for an email identity, if applicable. **Note** Before you complete the procedure in this section, you have to install and configure the AWS CLI. For more information, see the [AWS Command Line Interface User Guide](https://docs.aws.amazon.com/cli/latest/userguide/). **To return a default configuration set using the AWS CLI** + At the command line, enter the following command to use the [GetEmailIdentity](https://docs.aws.amazon.com/ses/latest/APIReference-V2/API_GetEmailIdentity.html) operation. ``` aws sesv2 get-email-identity --email-identity ADDRESS-OR-DOMAIN ``` In the preceding commands, replace *ADDRESS-OR-DOMAIN* with with email identity for which you wish to know the default configuration set, if any. If the command executes successfully, it provides a JSON object with the email identity details. # Override the current default configuration set used by the identity using the SES API You can use the [SendEmail](https://docs.aws.amazon.com/ses/latest/APIReference-V2/API_SendEmail.html) operation to send email with a different configuration set. If you do, the configuration set that you specify overrides the default configuration set for the identity. **Note** Before you complete the procedure in this section, you have to install and configure the AWS CLI. For more information, see the [AWS Command Line Interface User Guide](https://docs.aws.amazon.com/cli/latest/userguide/). **To override a default configuration set using the AWS CLI** + At the command line, enter the following command to use the [SendEmail](https://docs.aws.amazon.com/ses/latest/APIReference-V2/API_SendEmail.html) operation. ``` aws sesv2 send-email --destination file://DESTINATION-JSON --content file://CONTENT-JSON --from-email-address ADDRESS-OR-DOMAIN --configuration-set-name CONFIG-SET ``` In the preceding commands, replace *DESTINATION-JSON* with your destination JSON file, *CONTENT-JSON* with your content JSON file, *ADDRESS-OR-DOMAIN* with your FROM email address, and *CONFIG-SET* with the name of the configuration set you wish to use instead of the default configuration set for the identity. If the command executes successfully, it outputs a `MessageId`. # Configuring identities in Amazon SES Configuring identities Amazon Simple Email Service (Amazon SES) uses the Simple Mail Transfer Protocol (SMTP) to send email. Because SMTP doesn't provide any authentication by itself, spammers can send email messages that claim to originate from someone else, while hiding their true origin. By falsifying email headers and spoofing source IP addresses, spammers can mislead recipients into believing that the email messages that they are receiving are authentic. Most ISPs that forward email traffic take measures to evaluate whether email is legitimate. One such measure that ISPs take is to determine whether an email is *authenticated*. Authentication requires senders to verify that they're the owner of the account that they are sending from. In some cases, ISPs refuse to forward email that is not authenticated. To ensure optimal deliverability, we recommend that you authenticate your emails. The following sections describe two authentication mechanisms ISPs use—Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM)—and provide instructions for how to use these standards with Amazon SES. + To learn about SPF, which provides a way to trace an email message back to the system from which it was sent, see [Authenticating Email with SPF in Amazon SES](send-email-authentication-spf.md). + To learn about DKIM, a standard that allows you to sign your email messages to show ISPs that your messages are legitimate and have not been modified in transit, see [Authenticating Email with DKIM in Amazon SES](send-email-authentication-dkim.md). + To learn how to comply with Domain-based Message Authentication, Reporting and Conformance (DMARC), which relies on SPF and DKIM, see [Complying with DMARC authentication protocol in Amazon SES](send-email-authentication-dmarc.md). # Email authentication methods Email authentication methods Amazon Simple Email Service (Amazon SES) uses the Simple Mail Transfer Protocol (SMTP) to send email. Because SMTP does not provide any authentication by itself, spammers can send email messages that claim to originate from someone else, while hiding their true origin. By falsifying email headers and spoofing source IP addresses, spammers can mislead recipients into believing that the email messages that they are receiving are authentic. Most ISPs that forward email traffic take measures to evaluate whether email is legitimate. One such measure that ISPs take is to determine whether an email is authenticated. Authentication requires senders to verify that they are the owner of the account that they are sending from. In some cases, ISPs refuse to forward email that is not authenticated. To ensure optimal deliverability, we recommend that you authenticate your emails. **Topics** + [ # Authenticating Email with DKIM in Amazon SES ](send-email-authentication-dkim.md) + [ # Authenticating Email with SPF in Amazon SES ](send-email-authentication-spf.md) + [ # Using a custom MAIL FROM domain ](mail-from.md) + [ # Complying with DMARC authentication protocol in Amazon SES ](send-email-authentication-dmarc.md) + [ # Using BIMI in Amazon SES ](send-email-authentication-bimi.md) # Authenticating Email with DKIM in Amazon SES Authenticating Email with DKIM *DomainKeys Identified Mail* (*DKIM*) is an email security standard designed to make sure that an email that claims to have come from a specific domain was indeed authorized by the owner of that domain. It uses public-key cryptography to sign an email with a private key. Recipient servers can then use a public key published to a domain's DNS to verify that parts of the email have not been modified during the transit. DKIM signatures are optional. You might decide to sign your email using a DKIM signature to enhance deliverability with DKIM-compliant email providers. Amazon SES provides three options for signing your messages using a DKIM signature: + **Easy DKIM**: SES generates a public-private key pair and automatically adds a DKIM signature to every message that you send from that identity, see [Easy DKIM in Amazon SES](send-email-authentication-dkim-easy.md). + **Deterministic Easy DKIM (DEED)**: Enables you to maintain consistent DKIM signing across multiple AWS Regions by creating replica identities that automatically inherit the DKIM signing attributes as a parent identity that is using Easy DKIM, see [Using Deterministic Easy DKIM (DEED) in Amazon SES](send-email-authentication-dkim-deed.md). + **BYODKIM (Bring Your Own DKIM)**: You provide your own public-private key pair and SES adds a DKIM signature to every message that you send from that identity, see [Provide your own DKIM authentication token (BYODKIM) in Amazon SES](send-email-authentication-dkim-bring-your-own.md). + **Manually add DKIM signature**: You add your own DKIM signature to email that you send using the `SendRawEmail` API, see [Manual DKIM signing in Amazon SES](send-email-authentication-dkim-manual.md). ## DKIM signing key length DKIM signing key length Since many DNS providers now fully support DKIM 2048 bit RSA encryption, Amazon SES also supports DKIM 2048 to allow more secure authentication of emails and therefore uses it as the default key length when you configure Easy DKIM either from the API or the console. 2048 bit keys can be setup and used in Bring Your Own DKIM (BYODKIM) as well, where your signing key length must be at least 1024 bits and no more than 2048 bits. For the sake of security as well as your email’s deliverability, when configured with Easy DKIM, you have the choice to use either 1024 and 2048 bit key lengths along with the flexibility of flipping back to 1024 in the event there are problems caused by any DNS providers who still don’t support 2048. *When you create a new identity, it will be created with DKIM 2048 by default unless you specify 1024.* To preserve the deliverability of in transit emails, there are restrictions on the frequency at which you can change your DKIM key length. Restrictions include: + Not being able to switch to the same key length as is already configured. + Not being able to switch to different key length more than once in a 24 hour period (unless it’s the first downgrade to 1024 in that period). When your email is in transit, DNS is using your public key to authenticate your email; therefore, if you change keys too quickly or frequently, DNS may not be able to DKIM authenticate your email as the former key may already be invalidated, thus, these restrictions safeguard against that. ## DKIM considerations When you use DKIM to authenticate your email, the following rules apply: + You only need to set up DKIM for the domain that you use in your "From" address. You don't need to set up DKIM for domains that you use in "Return-Path" or "Reply-to" addresses. + Amazon SES is available in several AWS Regions. If you use more than one AWS Region to send email, you have to complete the DKIM setup process in each of those Regions to ensure that all of your email is DKIM-signed. + Because DKIM properties are inherited from the parent domain, when you verify a domain with DKIM authentication: + DKIM authentication will also apply to all subdomains of that domain. + DKIM settings for a subdomain can override the settings for the parent domain by disabling the inheritance if you don't want the subdomain to use DKIM authentication, as well as the ability to re-enable later. + DKIM authentication will also apply to all email sent from an email identity that references the DKIM verified domain in its address. + DKIM settings for an email address can override the settings for the subdomain (if applicable) and the parent domain by disabling the inheritance if you want to send mail without DKIM authentication, as well as the ability to re-enable later. ## Understanding inherited DKIM signing properties It's important to first understand that an email address identity inherits its DKIM signing properties from its parent domain if that domain was configured with DKIM, regardless of whether Easy DKIM or BYODKIM was used. Therefore, disabling or enabling DKIM signing on the email address identity, is in effect, overriding the domain's DKIM signing properties based on these key facts: + If you already set up DKIM for the domain that an email address belongs to, you do not need to enable DKIM signing for the email address identity as well. + When you set up DKIM for a domain, Amazon SES automatically authenticates every email from every address on that domain through the inherited DKIM properties from the parent domain. + DKIM settings for a specific email address identity *automatically override the settings of the parent domain or subdomain (if applicable)* that the address belongs to. Since the email address identity's DKIM signing properties are inherited from the parent domain, if you're planning on overriding these properties, you must keep in mind the hierarchical rules of overriding as explained in the table below. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ses/latest/dg/send-email-authentication-dkim.html) It’s generally never recommended to disable your DKIM signing as it risks tarnishing your sender reputation, and it increases the risk of having your sent mail go to junk or spam folders or having your domain spoofed. However, the capability exists to override the domain inherited DKIM signing properties on an email address identity for any particular use case or outlying business decision that you might have to either permanently or temporarily disable DKIM signing, or to re-enable it at a later time. See [Overriding inherited DKIM signing on an email address identity](send-email-authentication-dkim-easy-managing.md#send-email-authentication-dkim-easy-setup-email). # Easy DKIM in Amazon SES Easy DKIM When you set up Easy DKIM for a domain identity, Amazon SES automatically adds a 2048-bit DKIM key to every email that you send from that identity. You can configure Easy DKIM by using the Amazon SES console, or by using the API. **Note** To set up Easy DKIM, you have to modify the DNS settings for your domain. If you use Route 53 as your DNS provider, Amazon SES can automatically create the appropriate records for you. If you use another DNS provider, see your provider's documentation to learn more about changing the DNS settings for your domain. **Warning** If you currently have BYODKIM enabled and are transitioning over to Easy DKIM, be aware that Amazon SES will not use BYODKIM to sign your emails while Easy DKIM is being set up and your DKIM status is in a pending state. Between the moment you make the call to enable Easy DKIM (either through the API or console) and the moment when SES can confirm your DNS configuration, your emails may be sent by SES without a DKIM signature. Therefore, it is advised to use an intermediary step to migrate from one DKIM signing method to the other (e.g., using a subdomain of your domain with BYODKIM enabled and then deleting it once Easy DKIM verification has passed), or perform this activity during your application's downtime, if any. ## Setting up Easy DKIM for a verified domain identity Enabling on a domain The procedure in this section is streamlined to just show the steps necessary to configure Easy DKIM on a domain identity that you've already created. If you haven't yet created a domain identity or you want to see all available options for customizing a domain identity, such as using a default configuration set, custom MAIL FROM domain, and tags, see [Creating a domain identity](creating-identities.md#verify-domain-procedure). Part of creating an Easy DKIM domain identity is configuring its DKIM-based verification where you will have the choice to either accept the Amazon SES default of 2048 bits, or to override the default by selecting 1024 bits. See [DKIM signing key length](send-email-authentication-dkim.md#send-email-authentication-dkim-1024-2048) to learn more about DKIM signing key lengths and how to change them. **To set up Easy DKIM for a domain** 1. Sign in to the AWS Management Console and open the Amazon SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the navigation pane, under **Configuration**, choose **Identities**. 1. In the list of identities, choose an identity where the **Identity type** is *Domain*. **Note** If you need to create or verify a domain, see [Creating a domain identity](creating-identities.md#verify-domain-procedure). 1. Under the **Authentication** tab, in the **DomainKeys Identified Mail (DKIM)** container, choose **Edit**. 1. In the **Advanced DKIM settings** container, choose the **Easy DKIM** button in the **Identity type** field. 1. In the **DKIM signing key length** field, choose either [**RSA\$12048\$1BIT** or **RSA\$11024\$1BIT**](send-email-authentication-dkim.md#send-email-authentication-dkim-1024-2048). 1. In the **DKIM signatures** field, check the **Enabled** box. 1. Choose **Save changes**. 1. Now that you’ve configured your domain identity with Easy DKIM, you must complete the verification process with your DNS provider - proceed to [Verifying a DKIM domain identity with your DNS provider](creating-identities.md#just-verify-domain-proc) and follow the DNS authentication procedures for Easy DKIM. ## Change the Easy DKIM signing key length for an identity Change the Easy DKIM key length The procedure in this section shows how you can easily change the Easy DKIM bits required for the signing algorithm. While a signing length of 2048 bits is always preferred for the enhanced security it provides, there may be situations that require you to use the 1024 bit length, such as having to use a DNS provider who only supports DKIM 1024. To preserve the deliverability of in transit emails, there are restrictions on the frequency at which you can change or flip your DKIM key length. When your email is in transit, DNS is using your public key to authenticate your email; therefore, if you change keys too quickly or frequently, DNS may not be able to DKIM authenticate your email as the former key may already be invalidated, thus, the following restrictions safeguard against that: + You can't switch to the same key length as is already configured. + You can't switch to a different key length more than once in a 24 hour period (unless it’s the first downgrade to 1024 in that period). In using the following procedures to change your key length, if you violate one of these restrictions, the console will return an error banner stating that *the input you provided is invalid* along with the reason of why it was invalid. **To change the DKIM signing key length bits** 1. Sign in to the AWS Management Console and open the Amazon SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the navigation pane, under **Configuration**, choose **Verified identities**. 1. In the list of identities, choose the identity you want to change the DKIM signing key length for. 1. Under the **Authentication** tab, in the **DomainKeys Identified Mail (DKIM)** container, choose **Edit**. 1. In the **Advanced DKIM settings** container, choose either [**RSA\$12048\$1BIT** or **RSA\$11024\$1BIT**](send-email-authentication-dkim.md#send-email-authentication-dkim-1024-2048) in the **DKIM signing key length** field. 1. Choose **Save changes**. # Using Deterministic Easy DKIM (DEED) in Amazon SES Deterministic Easy DKIM (DEED) Deterministic Easy DKIM (DEED) offers a solution for managing DKIM configurations across multiple AWS Regions. By simplifying DNS management and ensuring consistent DKIM signing, DEED helps you streamline your multi-region email sending operations while maintaining robust email authentication practices. ## What is Deterministic Easy DKIM (DEED)? What is DEED? Deterministic Easy DKIM (DEED) is a feature that generates consistent DKIM tokens across all AWS Regions based on a parent domain that is configured with [Easy DKIM](send-email-authentication-dkim-easy.md). This enables you to replicate identities in different AWS Regions that automatically inherit and maintain the same DKIM signing configuration as a parent identity that is currently configured with Easy DKIM. With DEED, you only need to publish DNS records once for the parent identity, and replica identities will use the same DNS records to verify domain ownership and manage DKIM signing. By simplifying DNS management and ensuring consistent DKIM signing, DEED helps you streamline your multi-region email sending operations while maintaining best email authentication practices. Terminology used when talking about DEED: + **Parent identity** – A verified identity configured with Easy DKIM that serves as the source for DKIM configuration for a replica identity. + **Replica identity** – A copy of a parent identity that shares the same DNS setup and DKIM signing configuration. + **Parent region** – The AWS Region where a parent identity is set up. + **Replica region** – An AWS Region where a replica identity is set up. + **DEED identity** – Any identity that is used as either a parent identity or a replica identity. (When a new identity is created, it is initially treated as a regular (non-DEED) identity. However, once a replica is created, the identity is then considered a DEED identity.) Key benefits of using DEED include: + **Simplified DNS management** – Publish DNS records only once for the parent identity. + **Easier multi-region operations** – Simplify the process of expanding email sending operations to new regions. + **Reduced administrative overhead** – Manage DKIM configurations centrally from the parent identity. ## How Deterministic Easy DKIM (DEED) works How DEED works When you create a replica identity, Amazon SES automatically replicates the DKIM signing key from the parent identity to the replica identity. Any subsequent DKIM key rotations or key length changes made to the parent identity are automatically propagated to all replica identities. The process involves the following workflow: 1. Create a parent identity in an AWS Region using Easy DKIM. 1. Set up the required DNS records for the parent identity. 1. Create replica identities in other AWS Regions, specifying the parent identity's domain name and DKIM signing region. 1. Amazon SES automatically replicates the parent's DKIM configuration to the replica identities. Important considerations: + You cannot create a replica of an identity that is already a replica. + The parent identity must have [Easy DKIM](send-email-authentication-dkim-easy.md) enabled—you cannot create replicas of BYODKIM or manually signed identities. + Parent identities cannot be deleted until all replica identities are deleted. ## Setting up a replica identity using DEED Setting up a replica identity This section will provide examples showing you how to create and verify a replica identity using DEED along with the necessary permissions required. **Topics** + [ ### Creating a replica identity ](#creating-replica-identity) + [ ### Verifying replica identity configuration ](#verifying-replica-identity) + [ ### Required Permissions to use DEED ](#required-permissions) ### Creating a replica identity Creating a replica identity To create replica identity: 1. In the AWS Region where you want to create a replica identity, open the SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). (In the SES console, replica identities are referred to as *Global identities*.) 1. In the navigation pane, choose **Identities**. 1. Choose **Create identity**. 1. Select **Domain** under **Identity type** and enter the domain name of an existing identity configured with Easy DKIM that you want to replicate and serve as the parent. 1. Expand **Advanced DKIM settings** and select **Deterministic Easy DKIM**. 1. From the **Parent region** dropdown menu, select a parent region where an Easy DKIM-signed identity with the same name as you entered for your Global (replica) identity resides. (Your replica region defaults to the region you signed into the SES console with.) 1. Ensure **DKIM signatures** is enabled. 1. (Optional) Add one or more **Tags** to your domain identity. 1. Review the configuration and choose **Create identity**. Using the AWS CLI: To create a replica identity based on a parent identity configured with Easy DKIM, you need to specify the parent's domain name, the region where you want to create the replica identity, and the parent's DKIM signing region as shown in this example: ``` aws sesv2 create-email-identity --email-identity example.com --region us-west-2 --dkim-signing-attributes '{"DomainSigningAttributesOrigin": "AWS_SES_US_EAST_1"}' ``` In the preceding example: 1. Replace *example.com* with the parent domain identity being replicated. 1. Replace *us-west-2* with the region where the replica domain identity will be created. 1. Replace *AWS\$1SES\$1US\$1EAST\$11* with the parent's DKIM signing region that represents its Easy DKIM signing configuration that will be replicated to the replica identity. **Note** The `AWS_SES_` prefix indicates that DKIM was configured for the parent identity by using Easy DKIM, and `US_EAST_1` is the AWS Region where it was created. ### Verifying replica identity configuration Verifying replica identity After creating the replica identity, you can verify that it was configured correctly with the parent identity's DKIM signing configuration. **To verify a replica identity:** 1. In the AWS Region where you created the replica identity, open the SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the navigation pane, choose **Identities** and select the identity you want to verify from the **Identities** table. 1. Under the **Authentication** tab, the **DKIM configuration** field will indicate the status, and the **Parent region** field will indicate the region being used for the identity's DKIM signing configuration utilizing DEED. Using the AWS CLI: Use the `get-email-identity` command specifying the replica's domain name and region: ``` aws sesv2 get-email-identity --email-identity example.com --region us-west-2 ``` The response will include the value of the parent region in the `SigningAttributesOrigin` parameter signifying that the replica identity has been successfully configured with the parent identity's DKIM signing configuration: ``` { "DkimAttributes": { "SigningAttributesOrigin": "AWS_SES_US_EAST_1" } } ``` ### Required Permissions to use DEED Required permissions To use DEED, you need: 1. Standard permissions for creating email identities in the replica region. 1. Permission to replicate the DKIM signing key from the parent region. #### Example IAM policy for DKIM replication Example IAM policy The following policy allows DKIM signing key replication from a parent identity to specified replica regions: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowDKIMReplication", "Effect": "Allow", "Action": "ses:ReplicateEmailIdentityDKIMSigningKey", "Resource": "arn:aws:ses:us-east-1:123456789124:identity/example.com", "Condition": { "ForAllValues:StringEquals": { "ses:ReplicaRegion": ["us-east-1", "us-east-1"] } } } ] } ``` ------ ## Best practices Best practices The following best practices are recommended: + **Plan your parent and replica regions** – Give consideration to the parent region you choose, as it will be the source of truth for the DKIM configuration used in replica regions. + **Use consistent IAM policies** – Ensure that your IAM policies allow for DKIM replication across all intended regions. + **Keep parent identities active** – Remember that your replica identities inherit the DKIM signing configuration of the parent identity, because of this dependency, you cannot delete a parent identity until all replica identities are deleted. ## Troubleshooting Troubleshooting If you encounter issues with DEED, consider the following: + **Verification errors** – Ensure that you have the necessary permissions for DKIM replication. + **Replication delays** – Allow some time for replication to complete, especially when creating new replica identities. + **DNS issues** – Verify that the DNS records for the parent identity are correctly set up and propagated. # Provide your own DKIM authentication token (BYODKIM) in Amazon SES BYODKIM - Bring Your Own DKIM As an alternative to using [Easy DKIM](send-email-authentication-dkim-easy.md), you can instead configure DKIM authentication by using your own public-private key pair. This process is known as *Bring Your Own DKIM* (*BYODKIM*). With BYODKIM, you can use a single DNS record to configure DKIM authentication for your domains, as opposed to Easy DKIM, which requires you to publish three separate DNS records. Additionally, with BYODKIM you can rotate the DKIM keys for your domains as often as you want. **Topics** + [ ## Step 1: Create the key pair ](#send-email-authentication-dkim-bring-your-own-create-key-pair) + [ ## Step 2: Add the selector and public key to your DNS provider's domain configuration ](#send-email-authentication-dkim-bring-your-own-update-dns) + [ ## Step 3: Configure and verify a domain to use BYODKIM ](#send-email-authentication-dkim-bring-your-own-configure-identity) **Warning** If you currently have Easy DKIM enabled and are transitioning over to BYODKIM, be aware that Amazon SES will not use Easy DKIM to sign your emails while BYODKIM is being set up and your DKIM status is in a pending state. Between the moment you make the call to enable BYODKIM (either through the API or console) and the moment when SES can confirm your DNS configuration, your emails may be sent by SES without a DKIM signature. Therefore, it is advised to use an intermediary step to migrate from one DKIM signing method to the other (e.g., using a subdomain of your domain with Easy DKIM enabled and then deleting it once BYODKIM verification has passed), or perform this activity during your application's downtime, if any. ## Step 1: Create the key pair Create the key pair To use the Bring Your Own DKIM feature, you first have to create an RSA key pair. The private key that you generate has to be in either PKCS \$11 or PKCS \$18 format, must use at least 1024-bit RSA encryption and up to 2048-bit, and be encoded using base64 [(PEM)](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail) encoding. See [DKIM signing key length](send-email-authentication-dkim.md#send-email-authentication-dkim-1024-2048) to learn more about DKIM signing key lengths and how to change them. **Note** You can use third-party applications and tools to generate RSA key pairs as long as the private key is generated with at least 1024-bit RSA encryption and up to 2048-bit, and is encoded using base64 [(PEM)](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail) encoding. In the following procedure, the example code which uses the `openssl genrsa` command that's built into most Linux, macOS, or Unix operating systems to create the key pair will automatically use base64 [(PEM)](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail) encoding. **To create the key pair from the Linux, macOS, or Unix command line** 1. At the command line, enter the following command to generate the private key replacing *nnnn* with a bit length of at least 1024 and up to 2048: ``` openssl genrsa -f4 -out private.key nnnn ``` 1. At the command line, enter the following command to generate the public key: ``` openssl rsa -in private.key -outform PEM -pubout -out public.key ``` ## Step 2: Add the selector and public key to your DNS provider's domain configuration Add the selector and public key to your DNS provider Now that you've created a key pair, you have to add the public key as a TXT record to the DNS configuration for your domain. **To add the public key to the DNS configuration for your domain** 1. Sign in to the management console for your DNS or hosting provider. 1. Add a new text record to the DNS configuration for your domain. The record should use the following format: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ses/latest/dg/send-email-authentication-dkim-bring-your-own.html) In the preceding example, make the following changes: + Replace *selector* with a unique name that identifies the key. **Note** A small number of DNS providers don't allow you to include underscores (\$1) in record names. However, the underscore in the DKIM record name is required. If your DNS provider doesn't allow you to enter an underscore in the record name, contact the provider's customer support team for assistance. + Replace *example.com* with your domain. + Replace *yourPublicKey* with the public key that you created earlier and include the `p=` prefix as shown in the *Value* column above. **Note** When you publish (add) your public key to your DNS provider, it must be formatted as follows: You have to delete the first and last lines (`-----BEGIN PUBLIC KEY-----` and `-----END PUBLIC KEY-----`, respectively) of the generated public key. Additionally, you have to remove the line breaks in the generated public key. The resulting value is a string of characters with no spaces or line breaks. You must include the `p=` prefix as shown in the *Value* column in the table above. Different providers have different procedures for updating DNS records. The following table includes links to the documentation for a few widely used DNS providers. This list isn't exhaustive and doesn't signify endorsement; likewise, if your DNS provider isn't listed, it doesn't imply you can't use the domain with Amazon SES. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ses/latest/dg/send-email-authentication-dkim-bring-your-own.html) ## Step 3: Configure and verify a domain to use BYODKIM Configure and verify a domain to use BYODKIM You can set up BYODKIM for both new domains (that is, domains that you don't currently use to send email through Amazon SES) and existing domains (that is, domains that you've already set up to use with Amazon SES) by using either the console or AWS CLI. Before you use the AWS CLI procedures in this section, you first have to install and configure the AWS CLI. For more information, see the [AWS Command Line Interface User Guide](https://docs.aws.amazon.com/cli/latest/userguide/).. ### Option 1: Creating a new domain identity that uses BYODKIM This section contains procedures for creating a new domain identity that uses BYODKIM. A new domain identity is a domain that you haven't previously set up to send email using Amazon SES. If you want to configure an existing domain to use BYODKIM, complete the procedure in [Option 2: Configuring an existing domain identity](#send-email-authentication-dkim-bring-your-own-configure-identity-existing-domain) instead. **To create an identity using BYODKIM from the console** + Follow the procedures in [Creating a domain identity](creating-identities.md#verify-domain-procedure), and when you get to Step 8, follow the BYODKIM specific instructions. **To create an identity using BYODKIM from the AWS CLI** To configure a new domain, use the `CreateEmailIdentity` operation in the Amazon SES API. 1. In a text editor, paste the following code: ``` { "EmailIdentity":"example.com", "DkimSigningAttributes":{ "DomainSigningPrivateKey":"privateKey", "DomainSigningSelector":"selector" } } ``` In the preceding example, make the following changes: + Replace *example.com* with the domain that you want to create. + Replace *privateKey* with your private key. **Note** You have to delete the first and last lines (`-----BEGIN PRIVATE KEY-----` and `-----END PRIVATE KEY-----`, respectively) of the generated private key. Additionally, you have to remove the line breaks in the generated private key. The resulting value is a string of characters with no spaces or line breaks. + Replace *selector* with the unique selector that you specified when you created the TXT record in the DNS configuration for your domain. When you finish, save the file as `create-identity.json`. 1. At the command line, enter the following command: ``` aws sesv2 create-email-identity --cli-input-json file://path/to/create-identity.json ``` In the preceding command, replace *path/to/create-identity.json* with the complete path to the file that you created in the previous step. ### Option 2: Configuring an existing domain identity This section contains procedures for updating an existing domain identity to use BYODKIM. An existing domain identity is a domain that you have already set up to send email using Amazon SES. **To update a domain identity using BYODKIM from the console** 1. Sign in to the AWS Management Console and open the Amazon SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the navigation pane, under **Configuration**, choose **Verified identities**. 1. In the list of identities, choose an identity where the **Identity type** is *Domain*. **Note** If you need to create or verify a domain, see [Creating a domain identity](creating-identities.md#verify-domain-procedure). 1. Under the **Authentication** tab, in the **DomainKeys Identified Mail (DKIM)** pane, choose **Edit**. 1. In the **Advanced DKIM settings** pane, choose the **Provide DKIM authentication token (BYODKIM)** button in the **Identity type** field. 1. For **Private key**, paste the private key you generated earlier. **Note** You have to delete the first and last lines (`-----BEGIN PRIVATE KEY-----` and `-----END PRIVATE KEY-----`, respectively) of the generated private key. Additionally, you have to remove the line breaks in the generated private key. The resulting value is a string of characters with no spaces or line breaks. 1. For **Selector name**, enter the name of the selector that you specified in your domain’s DNS settings. 1. In the **DKIM signatures** field, check the **Enabled** box. 1. Choose **Save changes**. **To update a domain identity using BYODKIM from the AWS CLI** To configure an existing domain, use the `PutEmailIdentityDkimSigningAttributes` operation in the Amazon SES API. 1. In a text editor, paste the following code: ``` { "SigningAttributes":{ "DomainSigningPrivateKey":"privateKey", "DomainSigningSelector":"selector" }, "SigningAttributesOrigin":"EXTERNAL" } ``` In the preceding example, make the following changes: + Replace *privateKey* with your private key. **Note** You have to delete the first and last lines (`-----BEGIN PRIVATE KEY-----` and `-----END PRIVATE KEY-----`, respectively) of the generated private key. Additionally, you have to remove the line breaks in the generated private key. The resulting value is a string of characters with no spaces or line breaks. + Replace *selector* with the unique selector that you specified when you created the TXT record in the DNS configuration for your domain. When you finish, save the file as `update-identity.json`. 1. At the command line, enter the following command: ``` aws sesv2 put-email-identity-dkim-signing-attributes --email-identity example.com --cli-input-json file://path/to/update-identity.json ``` In the preceding command, make the following changes: + Replace *path/to/update-identity.json* with the complete path to the file that you created in the previous step. + Replace *example.com* with the domain that you want to update. ### Verifying the DKIM status for a domain that uses BYODKIM **To verify the DKIM status of a domain from the console** After you configure a domain to use BYODKIM, you can use the SES console to verify that DKIM is properly configured. 1. Sign in to the AWS Management Console and open the Amazon SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the navigation pane, under **Configuration**, choose **Verified identities**. 1. In the list of identities, choose the identity whose DKIM status you want to verify. 1. It can take up to 72 hours for changes to DNS settings to propagate. As soon as Amazon SES detects all of the required DKIM records in your domain’s DNS settings, the verification process is complete. If everything has been configured correctly, your domain’s **DKIM configuration** field displays **Successful** in the **DomainKeys Identified Mail (DKIM)** pane, and the **Identity status** field displays **Verified** in the **Summary** pane. **To verify the DKIM status of a domain using the AWS CLI** After you configure a domain to use BYODKIM, you can use the GetEmailIdentity operation to verify that DKIM is properly configured. + At the command line, enter the following command: ``` aws sesv2 get-email-identity --email-identity example.com ``` In the preceding command, replace *example.com* with your domain. This command returns a JSON object that contains a section that resembles the following example. ``` { ... "DkimAttributes": { "SigningAttributesOrigin": "EXTERNAL", "SigningEnabled": true, "Status": "SUCCESS", "Tokens": [ ] }, ... } ``` If all of the following are true, BYODKIM is properly configured for the domain: + The value of the `SigningAttributesOrigin` property is `EXTERNAL`. + The value of `SigningEnabled` is `true`. + The value of `Status` is `SUCCESS`. # Managing Easy DKIM and BYODKIM Managing Easy DKIM & BYODKIM You can manage the DKIM settings for your identities authenticated with either Easy DKIM or BYODKIM by using the web-based Amazon SES console, or by using the Amazon SES API. You can use either of these methods to obtain the DKIM records for an identity, or to enable or disable DKIM signing for an identity. ## Obtaining DKIM Records for an identity You can obtain the DKIM records for your domain or email address at any time by using the Amazon SES console. **To obtain the DKIM records for an identity by using the console** 1. Sign in to the AWS Management Console and open the Amazon SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the navigation pane, under **Configuration**, choose **Verified identities**. 1. In the list of identities, choose the identity for which you want to obtain DKIM records. 1. On the **Authentication** tab of the identity details page, expand **View DNS records**. 1. Copy either the three CNAME records if you used Easy DKIM, or the TXT record if you used BYODKIM, that appear in this section. Alternatively, you can choose **Download .csv record set** to save a copy of the records to your computer. The following image shows an example of the expanded **View DNS records** section revealing CNAME records associated with Easy DKIM. ![\[\]](http://docs.aws.amazon.com/ses/latest/dg/images/dkim_existing_dns.png) You can also obtain the DKIM records for an identity by using the Amazon SES API. A common method of interacting with the API is to use the AWS CLI. **To obtain the DKIM records for an identity by using the AWS CLI** 1. At the command line, type the following command: ``` aws ses get-identity-dkim-attributes --identities "example.com" ``` In the preceding example, replace *example.com* with the identity that you want to obtain DKIM records for. You can specify either an email address or a domain. 1. The output of this command contains a `DkimTokens` section, as shown in the following example: ``` { "DkimAttributes": { "example.com": { "DkimEnabled": true, "DkimVerificationStatus": "Success", "DkimTokens": [ "hirjd4exampled5477y22yd23ettobi", "v3rnz522czcl46quexamplek3efo5o6x", "y4examplexbhyhnsjcmtvzotfvqjmdqoj" ] } } } ``` You can use the tokens to create the CNAME records that you add to the DNS settings for your domain. To create the CNAME records, use the following template: ``` token1._domainkey.example.com CNAME token1.dkim.amazonses.com token2._domainkey.example.com CNAME token2.dkim.amazonses.com token3._domainkey.example.com CNAME token3.dkim.amazonses.com ``` Replace each instance of *token1* with the first token in the list you received when you ran the `get-identity-dkim-attributes` command, replace all instances of *token2* with the second token in the list, and replace all instances of *token3* with the third token in the list. For example, applying this template to the tokens shown in the preceding example produces the following records: ``` hirjd4exampled5477y22yd23ettobi._domainkey.example.com CNAME hirjd4exampled5477y22yd23ettobi.dkim.amazonses.com v3rnz522czcl46quexamplek3efo5o6x._domainkey.example.com CNAME v3rnz522czcl46quexamplek3efo5o6x.dkim.amazonses.com y4examplexbhyhnsjcmtvzotfvqjmdqoj._domainkey.example.com CNAME y4examplexbhyhnsjcmtvzotfvqjmdqoj.dkim.amazonses.com ``` **Note** Not all AWS Regions use the default SES DKIM domain, `dkim.amazonses.com`—to see if your region uses a region specific DKIM domain, check the [DKIM domains table](https://docs.aws.amazon.com/general/latest/gr/ses.html#ses_dkim_domains) in the *AWS General Reference*. ## Disabling Easy DKIM for an identity You can quickly disable DKIM authentication for an identity by using the Amazon SES console. **To disable DKIM for an identity** 1. Sign in to the AWS Management Console and open the Amazon SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the navigation pane, under **Configuration**, choose **Verified identities**. 1. In the list of identities, choose the identity for which you want to disable DKIM. 1. Under the **Authentication** tab, in the **DomainKeys Identified Mail (DKIM)** container, choose **Edit**. 1. In **Advanced DKIM settings**, clear the **Enabled** box in the **DKIM signatures** field. You can also disable DKIM for an identity by using the Amazon SES API. A common method of interacting with the API is to use the AWS CLI. **To disable DKIM for an identity by using the AWS CLI** + At the command line, type the following command: ``` aws ses set-identity-dkim-enabled --identity example.com --no-dkim-enabled ``` In the preceding example, replace *example.com* with the identity that you want to disable DKIM for. You can specify either an email address or a domain. ## Enabling Easy DKIM for an identity If you previously disabled DKIM for an identity, you can enable it again by using the Amazon SES console. **To enable DKIM for an identity** 1. Sign in to the AWS Management Console and open the Amazon SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the navigation pane, under **Configuration**, choose **Verified identities**. 1. In the list of identities, choose the identity for which you want to enable DKIM. 1. Under the **Authentication** tab, in the **DomainKeys Identified Mail (DKIM)** container, choose **Edit**. 1. In **Advanced DKIM settings**, check the **Enabled** box in the **DKIM signatures** field. You can also enable DKIM for an identity by using the Amazon SES API. A common method of interacting with the API is to use the AWS CLI. **To enable DKIM for an identity by using the AWS CLI** + At the command line, type the following command: ``` aws ses set-identity-dkim-enabled --identity example.com --dkim-enabled ``` In the preceding example, replace *example.com* with the identity that you want to enable DKIM for. You can specify either an email address or a domain. ## Overriding inherited DKIM signing on an email address identity Overriding DKIM signing on email address In this section you'll learn how to override (disable or enable) the inherited DKIM signing properties from the parent domain on a specific email address identity that you've already verified with Amazon SES. You can only do this for email address identities that belong to domains you already own because DNS settings are configured at the domain level. **Important** You can't disable/enable DKIM signing for email address identities... on domains that you don't own. For example, you can't toggle DKIM signing for a *gmail.com* or *hotmail.com* address, on domains that you own, but have not yet been verified in Amazon SES, on domains that you own, but have not enabled DKIM signing on the domain. This section contains the following topics: + [Understanding inherited DKIM signing properties](#dkim-easy-setup-email-key-points-mng) + [Overriding DKIM signing on an email address identity (console)](#override-dkim-email-console-mng) + [Overriding DKIM signing on an email address identity (AWS CLI)](#override-dkim-email-cli-mng) ### Understanding inherited DKIM signing properties It's important to first understand that an email address identity inherits its DKIM signing properties from its parent domain if that domain was configured with DKIM, regardless of whether Easy DKIM or BYODKIM was used. Therefore, disabling or enabling DKIM signing on the email address identity, is in effect, overriding the domain's DKIM signing properties based on these key facts: + If you already set up DKIM for the domain that an email address belongs to, you do not need to enable DKIM signing for the email address identity as well. + When you set up DKIM for a domain, Amazon SES automatically authenticates every email from every address on that domain through the inherited DKIM properties from the parent domain. + DKIM settings for a specific email address identity *automatically override the settings of the parent domain or subdomain (if applicable)* that the address belongs to. Since the email address identity's DKIM signing properties are inherited from the parent domain, if you're planning on overriding these properties, you must keep in mind the hierarchical rules of overriding as explained in the table below. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ses/latest/dg/send-email-authentication-dkim-easy-managing.html) It’s generally never recommended to disable your DKIM signing as it risks tarnishing your sender reputation, and it increases the risk of having your sent mail go to junk or spam folders or having your domain spoofed. However, the capability exists to override the domain inherited DKIM signing properties on an email address identity for any particular use case or outlying business decision that you might have to either permanently or temporarily disable DKIM signing, or to re-enable it at a later time. ### Overriding DKIM signing on an email address identity (console) Overriding DKIM signing (console) The following SES console procedure explains how to override (disable or enable) the inherited DKIM signing properties from the parent domain on a specific email address identity that you've already verified with Amazon SES. **To disable/enable DKIM signing for an email address identity using the console** 1. Sign in to the AWS Management Console and open the Amazon SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the navigation pane, under **Configuration**, choose **Verified identities**. 1. In the list of identities, choose an identity where the **Identity type** is *Email address* and belongs to one of your verified domains. 1. Under the **Authentication** tab, in the **DomainKeys Identified Mail (DKIM)** container, choose **Edit**. **Note** The **Authentication** tab is only present if the selected email address identity belongs to a domain that has already been verified by SES. If you haven't verified your domain yet, see [Creating a domain identity](creating-identities.md#verify-domain-procedure). 1. Under **Advanced DKIM settings**, in the **DKIM signatures** field, clear the **Enabled** checkbox to disable DKIM signing, or select it to re-enable DKIM signing (if it had been overridden previously). 1. Choose **Save changes**. ### Overriding DKIM signing on an email address identity (AWS CLI) Overriding DKIM signing (AWS CLI) The following example uses the AWS CLI with a SES API command and parameters that will override (disable or enable) the inherited DKIM signing properties from the parent domain on a specific email address identity that you've already verified with SES. **To disable/enable DKIM signing for an email address identity using the AWS CLI** + Assuming you own the *example.com* domain, and you want to disable DKIM signing for one of the domain's email addresses, at the command line, type the following command: ``` aws sesv2 put-email-identity-dkim-attributes --email-identity marketing@example.com --no-signing-enabled ``` 1. Replace *marketing@example.com* with the email address identity that you want to disable DKIM signing for. 1. `--no-signing-enabled` will disable DKIM signing. To re-enable DKIM signing, use `--signing-enabled`. # Manual DKIM signing in Amazon SES Manual DKIM signing As an alternative to using Easy DKIM, you can instead manually add DKIM signatures to your messages, and then send those messages using Amazon SES. If you choose to manually sign your messages, you first have to create a DKIM signature. After you create the message and the DKIM signature, you can use the [SendRawEmail](https://docs.aws.amazon.com/ses/latest/APIReference/API_SendRawEmail.html) API to send it. If you decide to manually sign your email, consider the following factors: + Every message that you send by using Amazon SES contains a DKIM header that references a signing domain of *amazonses.com* (that is, it contains the following string: `d=amazonses.com`). Therefore, if you manually sign your messages, your messages will include *two* DKIM headers: one for your domain, and the one that Amazon SES automatically creates for *amazonses.com*. + Amazon SES doesn't validate DKIM signatures that you manually add to your messages. If there are errors with the DKIM signature in a message, it might be rejected by email providers. + When you sign your messages, you should use a bit length of at least 1024 bits. + Don't sign the following fields: Message-ID, Date, Return-Path, Bounces-To. **Note** If you use an email client to send email using the Amazon SES SMTP interface, your client might automatically perform DKIM signing of your messages. Some clients might sign some of these fields. For information about which fields are signed by default, see the documentation for your email client. # Authenticating Email with SPF in Amazon SES Authenticating Email with SPF *Sender Policy Framework* (SPF) is an email validation standard that's designed to prevent email spoofing. Domain owners use SPF to tell email providers which servers are allowed to send email from their domains. SPF is defined in [RFC 7208](https://tools.ietf.org/html/rfc7208). Messages that you send through Amazon SES automatically use a subdomain of `amazonses.com` as the default MAIL FROM domain. SPF authentication successfully validates these messages because the default MAIL FROM domain matches the application that sent the email—in this case, SES. Therefore, in SES, SPF is implicitly set up for you. However, if you don't want to use the SES default MAIL FROM domain, and would rather use a subdomain of a domain that you own, this is referred to in SES as using a *custom* MAIL FROM domain. To do this, it requires you to publish your own SPF record for your custom MAIL FROM domain. In addition, SES also requires you to set up an MX record so that your custom MAIL FROM domain can receive the bounce and complaint notifications that email providers send you. **Learn how to set up SPF authentication** Instructions are given for configuring your domain with SPF and how to publish the MX and SPF (type TXT) records in [Using a custom MAIL FROM domain](mail-from.md). # Using a custom MAIL FROM domain When an email is sent, it has two addresses that indicate its source: a From address that's displayed to the message recipient, and a MAIL FROM address that indicates where the message originated. The MAIL FROM address is sometimes called the *envelope sender*, *envelope from*, *bounce address*, or *Return Path* address. Mail servers use the MAIL FROM address to return bounce messages and other error notifications. The MAIL FROM address is usually only viewable by recipients if they view the source code for the message. Amazon SES sets the MAIL FROM domain for the messages that you send to a default value unless you specify your own (custom) domain. This section discusses the benefits of setting up a custom MAIL FROM domain, and includes setup procedures. ## Why use a custom MAIL FROM domain? Messages that you send through Amazon SES automatically use a subdomain of `amazonses.com` as the default MAIL FROM domain. Sender Policy Framework (SPF) authentication successfully validates these messages because the default MAIL FROM domain matches the application that sent the email—in this case, SES. If you don't want to use the SES default MAIL FROM domain, and would rather use a subdomain of a domain that you own, this is referred to in SES as using a *custom* MAIL FROM domain. To do this, it requires you to publish your own SPF record for your custom MAIL FROM domain. In addition, SES also requires you to set up an MX record so that your domain can receive the bounce and complaint notifications that email providers send you. By using a custom MAIL FROM domain, you have the flexibility to use SPF, DKIM, or both to achieve [Domain-based Message Authentication, Reporting and Conformance (DMARC)](send-email-authentication-dmarc.md) validation. DMARC enables a sender's domain to indicate that emails sent from the domain are protected by one or more authentication systems. There are two ways to achieve DMARC validation: [Complying with DMARC through SPF](send-email-authentication-dmarc.md#send-email-authentication-dmarc-spf) and [Complying with DMARC through DKIM](send-email-authentication-dmarc.md#send-email-authentication-dmarc-dkim). ## Choosing a custom MAIL FROM domain In the following, the term *MAIL FROM domain* always refers to a subdomain of a domain that you own - this subdomain that you use for your custom MAIL FROM domain must not be used for anything else and meet the following requirements: + The MAIL FROM domain has to be a subdomain of the parent domain of a verified identity (email address or domain). + The MAIL FROM domain shouldn't be a subdomain that you also use to send email from. + The MAIL FROM domain shouldn't be a subdomain that you use to receive email. ## Using SPF with your custom MAIL FROM domain Using SPF with your custom MAIL FROM domain *Sender Policy Framework* (SPF) is an email validation standard that's designed to prevent email spoofing. You can configure your custom MAIL FROM domain with SPF to tell email providers which servers are allowed to send email from your custom MAIL FROM domain. SPF is defined in [RFC 7208](https://tools.ietf.org/html/rfc7208). To set up SPF, you publish a TXT record to the DNS configuration for your custom MAIL FROM domain. This record contains a list of the servers that you authorize to send email from using your custom MAIL FROM domain. When an email provider receives a message from your custom MAIL FROM domain, it checks the DNS records for that domain to make sure that the email was sent from an authorized server. If you want to use this SPF record as a way to comply with DMARC, the domain in the From address must match the MAIL FROM domain. See [Complying with DMARC through SPF](send-email-authentication-dmarc.md#send-email-authentication-dmarc-spf). The next section, [Configuring your custom MAIL FROM domain](#mail-from-set), explains how to set up SPF for your custom MAIL FROM domain. ## Configuring your custom MAIL FROM domain The process of setting up a custom MAIL FROM domain requires you to add records to the DNS configuration for the domain. SES requires you to publish an MX record so that your domain can receive the bounce and complaint notifications that email providers send you. You also have to publish an SPF (type TXT) record in order to prove that Amazon SES is authorized to send email from your domain. You can set up a custom MAIL FROM domain for an entire domain or subdomain, as well as for individual email addresses. The following procedures show how to use the Amazon SES console to configure a custom MAIL FROM domain. You can also configure a custom MAIL FROM domain using the [SetIdentityMailFromDomain](https://docs.aws.amazon.com/ses/latest/APIReference/API_SetIdentityMailFromDomain.html) API operation. ### Setting up a custom MAIL FROM domain for a verified domain These procedures show you how to configure a custom MAIL FROM domain for an entire domain or subdomain so that all messages sent from addresses on that domain will use the this custom MAIL FROM domain. **To configure a verified domain to use a specified custom MAIL FROM domain** 1. Open the Amazon SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the left navigation panel, under **Configuration**, choose **Identities**. 1. In the list of identities, choose the identity you want to configure where the **Identity type** is **Domain** and **Status** is *Verified*. 1. If the **Status** is *Unverified*, complete the procedures at [Verifying a DKIM domain identity with your DNS provider](creating-identities.md#just-verify-domain-proc) to verify the email address's domain. 1. At the bottom of the screen in the **Custom MAIL FROM domain** pane, choose **Edit** . 1. In the **General details** pane, do the following: 1. Select the **Use a custom MAIL FROM domain** checkbox. 1. For **MAIL FROM domain**, enter the subdomain that you want to use as the MAIL FROM domain. 1. For **Behavior on MX failure**, choose one of the following options: + **Use default MAIL FROM domain** – If the custom MAIL FROM domain's MX record is not set up correctly, Amazon SES uses a subdomain of `amazonses.com`. The subdomain varies based on the AWS Region that you use Amazon SES in. + **Reject message** – If the custom MAIL FROM domain's MX record is not set up correctly, Amazon SES returns a `MailFromDomainNotVerified` error. Emails that you attempt to send from this domain are automatically rejected. 1. Choose **Save changes** - you'll be returned to the previous screen. 1. Publish the MX and SPF (type TXT) records to the DNS server of the custom MAIL FROM domain: In the **Custom MAIL FROM domain** pane, the **Publish DNS records** table now displays the MX and SPF (type TXT) records in that you have to publish (add) to your domain's DNS configuration. These records use the formats shown in the following table. **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ses/latest/dg/mail-from.html) In the preceding records, + *subdomain*.*domain*.*com* will be populated with your MAIL FROM subdomain + *region* will be populated with the name of the AWS Region where you want to verify the MAIL FROM domain (such as `us-west-2`, `us-east-1`, or `eu-west-1`, etc.) + The number *10* listed along with the MX value is the preference order for the mail server and will need to be entered into a separate value field as specified by your DNS provider's GUI + The SPF's TXT record value usually has to include the quotation marks, but some DNS providers don't require them. From the **Publish DNS records** table, copy the MX and SPF (type TXT) records by choosing the copy icon next to each value and paste them into the corresponding fields in your DNS provider's GUI. Alternatively, you can choose **Download .csv record set** to save a copy of the records to your computer. **Important** The specific procedures for publishing the MX and SPF (type TXT) records depend on your DNS or hosting provider. See your provider's documentation or contact them for information about adding these records to the DNS configuration for your domain. To successfully set up a custom MAIL FROM domain with Amazon SES, you must publish exactly one MX record to the DNS server of your MAIL FROM domain. If the MAIL FROM domain has multiple MX records, the custom MAIL FROM setup with Amazon SES will fail. If Route 53 provides the DNS service for your MAIL FROM domain, and you're signed in to the AWS Management Console under the same account that you use for Route 53, then choose ** Publish Records Using Route 53**. The DNS records are automatically applied to your domain's DNS configuration. If you use a different DNS provider, you have to publish the DNS records to the MAIL FROM domain's DNS server manually. The procedure for adding DNS records to your domain's DNS server varies based on your web hosting service or DNS provider. The procedures for publishing DNS records for your domain depend on which DNS provider you use. The following table includes links to the documentation for a few widely used DNS providers. This list isn't exhaustive and doesn't signify endorsement; likewise, if your DNS provider isn't listed, it doesn't imply they don't support MAIL FROM domain configuration. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ses/latest/dg/mail-from.html) When Amazon SES detects that the records are in place, you receive an email informing you that your custom MAIL FROM domain was set up successfully. Depending on your DNS provider, there might be a delay of up to 72 hours before Amazon SES detects the MX record. ### Setting up a custom MAIL FROM domain for a verified email address You can also set up a custom MAIL FROM domain for a specific email address. In order to set up a custom MAIL FROM domain for an email address, you must modify the DNS records for the domain that the email address is associated with. **Note** You can't set up a custom MAIL FROM domain for addresses on a domain that you don't own (for example, you can't create a custom MAIL FROM domain for an address on the `gmail.com` domain, because you can't add the necessary DNS records to the domain). **To configure a verified email address to use a specified MAIL FROM domain** 1. Open the Amazon SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the left navigation panel, under **Configuration**, choose **Identities**. 1. In the list of identities, choose the identity you want to configure where the **Identity type** is **Email address** and **Status** is *Verified*. 1. If the **Status** is *Unverified*, complete the procedures at [Verifying an email address identity](creating-identities.md#just-verify-email-proc) to verify the email address's domain. 1. Under the **MAIL FROM Domain** tab, choose **Edit** in the **Custom MAIL FROM domain** pane. 1. In the **General details** pane, do the following: 1. Select the **Use a custom MAIL FROM domain** checkbox. 1. For **MAIL FROM domain**, enter the subdomain that you want to use as the MAIL FROM domain. 1. For **Behavior on MX failure**, choose one of the following options: + **Use default MAIL FROM domain** – If the custom MAIL FROM domain's MX record is not set up correctly, Amazon SES uses a subdomain of `amazonses.com`. The subdomain varies based on the AWS Region that you use Amazon SES in. + **Reject message** – If the custom MAIL FROM domain's MX record is not set up correctly, Amazon SES returns a `MailFromDomainNotVerified` error. Emails that you attempt to send from this email address are automatically rejected. 1. Choose **Save changes** - you'll be returned to the previous screen. 1. Publish the MX and SPF (type TXT) records to the DNS server of the custom MAIL FROM domain: In the **Custom MAIL FROM domain** pane, the **Publish DNS records** table now displays the MX and SPF (type TXT) records in that you have to publish (add) to your domain's DNS configuration. These records use the formats shown in the following table. **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ses/latest/dg/mail-from.html) In the preceding records, + *subdomain*.*domain*.*com* will be populated with your MAIL FROM subdomain + *region* will be populated with the name of the AWS Region where you want to verify the MAIL FROM domain (such as `us-west-2`, `us-east-1`, or `eu-west-1`, etc.) + The number *10* listed along with the MX value is the preference order for the mail server and will need to be entered into a separate value field as specified by your DNS provider's GUI + The SPF's TXT record value has to include the quotation marks From the **Publish DNS records** table, copy the MX and SPF (type TXT) records by choosing the copy icon next to each value and paste them into the corresponding fields in your DNS provider's GUI. Alternatively, you can choose **Download .csv record set** to save a copy of the records to your computer. **Important** To successfully set up a custom MAIL FROM domain with Amazon SES, you must publish exactly one MX record to the DNS server of your MAIL FROM domain. If the MAIL FROM domain has multiple MX records, the custom MAIL FROM setup with Amazon SES will fail. If Route 53 provides the DNS service for your MAIL FROM domain, and you're signed in to the AWS Management Console under the same account that you use for Route 53, then choose ** Publish Records Using Route 53**. The DNS records are automatically applied to your domain's DNS configuration. If you use a different DNS provider, you have to publish the DNS records to the MAIL FROM domain's DNS server manually. The procedure for adding DNS records to your domain's DNS server varies based on your web hosting service or DNS provider. The procedures for publishing DNS records for your domain depend on which DNS provider you use. The following table includes links to the documentation for a few widely used DNS providers. This list isn't exhaustive and doesn't signify endorsement; likewise, if your DNS provider isn't listed, it doesn't imply they don't support MAIL FROM domain configuration. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ses/latest/dg/mail-from.html) When Amazon SES detects that the records are in place, you receive an email informing you that your custom MAIL FROM domain was set up successfully. Depending on your DNS provider, there might be a delay of up to 72 hours before Amazon SES detects the MX record. ## Custom MAIL FROM domain setup states with Amazon SES Custom MAIL FROM domain setup states After you configure an identity to use a custom MAIL FROM domain, the state of the setup is "pending" while Amazon SES attempts to detect the required MX record in your DNS settings. The state then changes depending on whether Amazon SES detects the MX record. The following table describes the email-sending behavior, and the Amazon SES actions associated with each state. Each time the state changes, Amazon SES sends a notification to the email address associated with your AWS account. **** | State | Email sending behavior | Amazon SES actions | | --- | --- | --- | | Pending | Uses custom MAIL FROM fallback setting | Amazon SES attempts to detect the required MX record for 72 hours. If unsuccessful, the state changes to "Failed". | | Success | Uses custom MAIL FROM domain | Amazon SES continuously checks that the required MX record is in place. | | TemporaryFailure | Uses custom MAIL FROM fallback setting | Amazon SES attempts to detect the required MX record for 72 hours. If unsuccessful, the state changes to "Failed"; if successful, the state changes to "Success". | | Failed | Uses custom MAIL FROM fallback setting | Amazon SES no longer attempts to detect the required MX record. To use a custom MAIL FROM domain, you have to restart the setup process in [Configuring your custom MAIL FROM domain](#mail-from-set). | # Complying with DMARC authentication protocol in Amazon SES Authenticating Email with DMARC Domain-based Message Authentication, Reporting and Conformance (DMARC) is an email authentication protocol that uses Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) to detect email spoofing and phishing. In order to comply with DMARC, messages must be authenticated through either SPF or DKIM, but ideally, when both are used with DMARC, you'll be ensuring the highest level of protection possible for your email sending. Let's briefly review which each does and how DMARC ties them all together: + **SPF** – Identifies which mail servers are allowed to send mail on behalf of your custom MAIL FROM domain through a DNS TXT record that is used by DNS. Recipient mail systems refer to the SPF TXT record to determine whether a message from your custom domain comes from an authorized messaging server. Basically, SPF is designed to help prevent spoofing, but there are spoofing techniques that SPF is susceptible to in practice and this is why you need to also use DKIM along with DMARC. + **DKIM** – Adds a digital signature to your outbound messages in the email header. Receiving email systems can use this digital signature to help verify whether incoming email is signed by a key owned by the domain. However, when a receiving email system forwards a message, the message's envelope is changed in a way that invalidates SPF authentication. Since the digital signature stays with the email message because it's part of the email header, DKIM works even when a message has been forwarded between mail servers (as long as the message content has not been modified). + **DMARC** – Ensures that there is domain alignment with at least one of SPF and DKIM. Using SPF and DKIM alone does nothing to insure that the From address is authenticated (this is the email address your recipient sees in their email client). SPF only checks the domain specified in the MAIL FROM address (not seen by your recipient). DKIM only checks the domain specified in the DKIM signature (also, not seen by your recipient). DMARC addresses these two issues by requiring domain alignment to be correct on either SPF or DKIM: + For SPF to pass DMARC alignment the domain in the From address must match the domain in the MAIL FROM address (also referred to as Return-Path and Envelope-from address). This is rarely possible with forwarded mail because it gets stripped away or when sending mail through third-party bulk email providers because the Return-Path (MAIL FROM) is used for bounces and complaints that the provider (SES) tracks using an address they own. + For DKIM to pass DMARC alignment, the domain specified in the DKIM signature must match the domain in the From address. If you use third-party senders or services that send mail on your behalf, this can be accomplished by ensuring the third-party sender is properly configured for DKIM signing and you have added the appropriate DNS records within your domain. Receiving mail servers will then be able to verify email sent to them by your third-party as if it was email sent by someone authorized to use an address within the domain. **Putting it all together with DMARC** The DMARC alignment checks we discussed above show how SPF, DKIM, and DMARC all work together to increase trust of your domain and delivery of your email to inboxes. DMARC accomplishes this by ensuring that the From address, seen by the recipient, is authenticated by either SPF or DKIM: + A message passes DMARC if one or both of the described SPF or DKIM checks pass. + A message fails DMARC if both of the described SPF or DKIM checks fail. Therefore, both SPF and DKIM are necessary for DMARC to have the best chance at achieving authentication for your sent email, and by utilizing all three, you'll help to ensure you have a fully protected sending domain. DMARC also allows you to instruct email servers how to handle emails when they fail DMARC authentication through policies that you set. This will be explained in the following section, [Setting up the DMARC policy on your domain](#send-email-authentication-dmarc-dns), that contains information on how to configure your SES domains so that the emails you send comply with the DMARC authentication protocol through both SPF and DKIM. ## Setting up the DMARC policy on your domain To set up DMARC, you have to modify the DNS settings for your domain. The DNS settings for your domain should include a TXT record that specifies the domain's DMARC settings. The procedures for adding TXT records to your DNS configuration depend on which DNS or hosting provider you use. If you use Route 53, see [Working with Records](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html) in the *Amazon Route 53 Developer Guide*. If you use another provider, see the DNS configuration documentation for your provider. The name of the TXT record you create should be `_dmarc.example.com`, where `example.com` is your domain. The value of the TXT record contains the DMARC policy that applies to your domain. The following is an example of a TXT record that contains a DMARC policy: | Name | Type | Value | | --- | --- | --- | | \$1dmarc.example.com | TXT | "v=DMARC1;p=quarantine;rua=mailto:my\$1dmarc\$1report@example.com" | In the preceding DMARC policy example, this policy tells email providers to do the following: + For any messages that fail authentication, send them to the Spam folder as specified by the policy parameter, `p=quarantine`. Other options include doing nothing by using `p=none`, or reject the message outright by using `p=reject`. + The next section discusses how and when to use these three policy settings—*using the wrong one at the wrong time can cause your email to not be delivered,* see [Best practices for implementing DMARC](#send-email-authentication-dmarc-implement). + Send reports about all emails that failed authentication in a digest (that is, a report that aggregates the data for a certain time period, rather than sending individual reports for each event) as specified by the reporting parameter, `rua=mailto:my_dmarc_report@example.com` (*rua* stands for Reporting URI for Aggregate reports). Email providers typically send these aggregated reports once per day, although these policies differ from provider to provider. To learn more about configuring DMARC for your domain, see the [Overview](https://dmarc.org/overview/) on the DMARC website. For complete specifications of the DMARC system, see [Internet Engineering Task Force (IETF) DMARC Draft](https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/). ## Best practices for implementing DMARC Implementing DMARC It's best to implement your DMARC policy enforcement in a gradual and phased approach so that it doesn't interrupt the rest of your mail flow. Create and implement a roll-out plan that follows these steps. Do each of these steps first with each of your sub-domains, and finally with the top-level domain in your organization before moving on to the next step. 1. Monitor the impact of implementing DMARC (p=none). + Start with a simple monitoring-mode record for a sub-domain or domain that requests that mail receiving organizations send you statistics about messages that they see using that domain. A monitoring-mode record is a DMARC TXT record that has its policy set to none `p=none`. + Reports generated through DMARC will give the numbers and sources of messages that pass these checks, versus those that don't. You can easily see how much of your legitimate traffic is or isn't covered by them. You'll see signs of forwarding, since forwarded messages will fail SPF and DKIM if the content is modified. You'll also begin to see how many fraudulent messages are being sent, and where they're sent from. + The goals of this step are to learn what emails will be impacted when you implement one of the next two steps, and to have any third-party or authorized senders get their SPF or DKIM policies into alignment. + Best for existing domains. 1. Request that external mail systems quarantine mail that fails DMARC (p=quarantine). + When you believe that all or most of your legitimate traffic is sending domain-aligned with either SPF or DKIM, and you understand the impact of implementing DMARC, you can implement a quarantine policy. A quarantine policy is a DMARC TXT record that has its policy set to quarantine `p=quarantine`. By doing this, you're asking DMARC receivers to put messages from your domain that fail DMARC into the local equivalent of a spam folder instead of your customers' inboxes. + Best for transitioning domains that have analyzed DMARC reports during Step 1. 1. Request that external mail systems not accept messages that fail DMARC (p=reject). + Implementing a reject policy is usually the final step. A reject policy is a DMARC TXT record that has its policy set to reject `p=reject`. When you do this, you're asking DMARC receivers not to accept messages that fail the DMARC checks—this means they won't even be quarantined to a spam or junk folder, but will be rejected outright. + When using a reject policy, you'll know exactly which messages are failing the DMARC policy as the rejection will result in a SMTP bounce. With quarantine, the aggregate data provides information about the percentages of email passing or failing SPF, DKIM, and DMARC checks. + Best for new domains or existing domains that have gone through the prior two steps. ## Complying with DMARC through SPF For an email to comply with DMARC based on SPF, both of the following conditions must be met: + The message must pass an SPF check based on having a valid SPF (type TXT) record that you've to published to your custom MAIL FROM domain's DNS configuration. + The domain in the From address of the email header must align (match) with the domain, or a subdomain of, that's specified in the MAIL FROM address. In order to achieve SPF alignment with SES, the domain's DMARC policy must not specify a strict SPF policy (aspf=s). To comply with these requirements, complete the following steps: + Set up a custom MAIL FROM domain by completing the procedures in [Using a custom MAIL FROM domain](mail-from.md). + Ensure that your sending domain uses a relaxed policy for SPF. If you haven't changed your domain's policy alignment, it uses a relaxed policy by default as does SES. **Note** You can determine your domain's DMARC alignment for SPF by typing the following command at the command line, replacing `example.com` with your domain: ``` dig TXT _dmarc.example.com ``` In the output of this command, under **Non-authoritative answer**, look for a record that begins with `v=DMARC1`. If this record includes the string `aspf=r`, or if the `aspf` string is not present at all, then your domain uses relaxed alignment for SPF. If the record includes the string `aspf=s`, then your domain uses strict alignment for SPF. Your system administrator will need to remove this tag from the DMARC TXT record in your domain's DNS configuration. Alternatively, you can use a web-based DMARC lookup tool, such as the [DMARC Inspector](https://dmarcian.com/dmarc-inspector/) from the dmarcian website or the [DMARC Check Tool](https://mxtoolbox.com/dmarc.aspx) tool from the MxToolBox website, to determine your domain's policy alignment for SPF. ## Complying with DMARC through DKIM For an email to comply with DMARC based on DKIM, both of the following conditions must be met: + The message must have a valid DKIM signature and passes the DKIM check. + The domain specified in the DKIM signature must align (match) with the domain in the From address. If the domain's DMARC policy specifies strict alignment for DKIM, these domains must match exactly (SES uses a strict DKIM policy by default). To comply with these requirements, complete the following steps: + Set up Easy DKIM by completing the procedures in [Easy DKIM in Amazon SES](send-email-authentication-dkim-easy.md). When you use Easy DKIM, Amazon SES automatically signs your emails. **Note** Rather than use Easy DKIM, you can also [manually sign your messages](send-email-authentication-dkim-manual.md). However, use caution if you choose to do so, because Amazon SES does not validate the DKIM signature that you construct. For this reason, we highly recommend using Easy DKIM. + Ensure the domain specified in the DKIM signature is aligned to the domain in the From address. Or, if sending from a subdomain of the domain in the From address, ensure that your DMARC policy is set to relaxed alignment. **Note** You can determine your domain's DMARC alignment for DKIM by typing the following command at the command line, replacing `example.com` with your domain: ``` dig TXT _dmarc.example.com ``` In the output of this command, under **Non-authoritative answer**, look for a record that begins with `v=DMARC1`. If this record includes the string `adkim=r`, or if the `adkim` string is not present at all, then your domain uses relaxed alignment for DKIM. If the record includes the string `adkim=s`, then your domain uses strict alignment for DKIM. Your system administrator will need to remove this tag from the DMARC TXT record in your domain's DNS configuration. Alternatively, you can use a web-based DMARC lookup tool, such as the [DMARC Inspector](https://dmarcian.com/dmarc-inspector/) from the dmarcian website or the [DMARC Check Tool](https://mxtoolbox.com/dmarc.aspx) tool from the MxToolBox website, to determine your domain's policy alignment for DKIM. # Using BIMI in Amazon SES Using BIMI in SES Brand Indicators for Message Identification (BIMI) is an email specification that enables email inboxes to display a brand’s logo next to the brand’s authenticated email messages within supporting email clients. BIMI is an email specification that's directly connected to authentication, but it’s not a standalone email authentication protocol as it requires all your email to comply with [DMARC](send-email-authentication-dmarc.md) authentication. While BIMI requires DMARC, DMARC requires your domain to have either SPF or DKIM records to align, but it’s best to include both SPF and DKIM records for additional security, and because some email service providers (ESPs) require both when using BIMI. The following section goes over the steps to implement BIMI in Amazon SES. ## Setting up BIMI in SES You can configure BIMI for an email domain that you own—in SES that's referred to as a *custom* MAIL FROM domain. Once configured, all of the messages that you send from that domain will display your BIMI logo in [email clients that support BIMI](https://bimigroup.org/bimi-infographic/). Enabling your emails to display a BIMI logo requires some prerequisites to be in place within SES—in the following procedure, these prerequisites are generalized and will reference dedicated sections that cover these topics in detail. The steps specific to BIMI and what is necessary to configure it in SES will be detailed here. **To set up BIMI on a custom MAIL FROM domain** 1. You must have a custom MAIL FROM domain configured in SES with both SPF (type TXT) and MX records published for that domain. If you don't have a custom MAIL FROM domain, or would like to create a new one for your BIMI logo, see [Using a custom MAIL FROM domain](mail-from.md). 1. Configure your domain with Easy DKIM. See [Easy DKIM in Amazon SES](send-email-authentication-dkim-easy.md). 1. Configure your domain with DMARC by publishing a TXT record with your DNS provider with the following enforcement policy specifics required for BIMI similar to either of the two examples: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ses/latest/dg/send-email-authentication-bimi.html) In the preceding DMARC policy example as required for BIMI: + `example.com` should be replaced with your domain or subdomain name. + The `p=` value can be either: + *quarantine* with a *pct* value set to *100* as shown, or + *reject* as shown. + If you're sending from a subdomain, BIMI requires that the parent domain must also have this enforcement policy. Subdomains will fall under the parent domain’s policy. However, if you add a DMARC record for your subdomain in addition to what is posted for the parent domain, your subdomain must also have the same enforcement policy to be eligible for BIMI. + If you've never set up a DMARC policy for your domain, see [Complying with DMARC authentication protocol in Amazon SES](send-email-authentication-dmarc.md) ensuring that you only use the DMARC policy values specific to BIMI as shown. 1. Produce your BIMI logo as a Scalable Vector Graphics (SVG) `.svg` file—the specific SVG profile required by BIMI is defined as SVG Portable/Secure (SVG P/S). In order for your logo to display in the email client it must conform exactly to these specifications. See the [BIMI Group's](https://bimigroup.org/) guidance on [creating SVG logo files](https://bimigroup.org/creating-bimi-svg-logo-files/) and recommended [SVG conversion tools](https://bimigroup.org/svg-conversion-tools-released/). 1. (Optional) Obtain a Verified Mark Certificate (VMC). Some ESPs, such as Gmail and Apple, require a VMC to provide evidence that you own the trademark and content of your BIMI logo. Although this isn't a requirement for implementing BIMI on your domain, your BIMI logo will not display in the email client if the ESP you send mail to enforces VMC compliance. See the BIMI Group's references to [participating certificate authorities](https://bimigroup.org/verified-mark-certificates-vmc-and-bimi/) to obtain a VMC for your logo. 1. Host your BIMI logo's SVG file on a server you have access to making it publicly accessible through HTTPS. For example, you could upload it to an [Amazon S3 bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/creating-buckets-s3.html). 1. Create and publish a BIMI DNS record that includes a URL to your logo. When an [ESP that supports BIMI](https://bimigroup.org/bimi-infographic/) checks your DMARC record, it will also look for a BIMI record containing the URL for your logo's `.svg` file, and if configured, the URL for your VMC's `.pem` file. If the records match, they'll display your BIMI logo. Configure your domain with BIMI by publishing a TXT record with your DNS provider with the following values as shown—sending from a domain is represented in the first example; sending from a subdomain is represented in the second example: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ses/latest/dg/send-email-authentication-bimi.html) In the preceding BIMI record examples: + The name value should literally specify `default._bimi.` as a subdomain of `example.com` or `marketing.example.com` which should be replaced with your domain or subdomain name. + The `v=` value is the *version* of the BIMI record. + The `l=` value is the *logo* representing the URL pointing to your image's `.svg` file. + The `a=` value is the *authority* representing the URL pointing to your certificate's `.pem` file. You can validate your BIMI record with a tool like the BIMI Group's [BIMI Inspector](https://bimigroup.org/bimi-generator/). The final step in this process is to have a regular sending pattern to the ESPs that support BIMI logo placement. Your domain should have a regular delivery cadence and should have a good reputation with the ESPs that you're sending to. BIMI logo placement may take time to populate to ESPs where you don’t have an established reputation or sending cadence. You can find more information and resources pertaining to BIMI through the [BIMI Group](https://bimigroup.org/) organization. # Setting up event notifications for Amazon SES Setting up event notifications In order to send email using Amazon SES, you must have a system in place for managing bounces and complaints. Amazon SES can notify you of bounce or complaint events in three ways: by sending a notification email, by notifying an Amazon SNS topic, or by publishing sending events. This section contains information about setting up Amazon SES to send certain kinds of notifications by email or by notifying an Amazon SNS topic. For more information about publishing sending events, see [Monitor email sending using Amazon SES event publishing](monitor-using-event-publishing.md). You can set up notifications using the Amazon SES console or the Amazon SES API. **Topics** + [ ## Important considerations ](#monitor-sending-activity-using-notifications-considerations) + [ # Receiving Amazon SES notifications through email ](monitor-sending-activity-using-notifications-email.md) + [ # Receiving Amazon SES notifications using Amazon SNS ](monitor-sending-activity-using-notifications-sns.md) ## Important considerations There are several important points to consider when you set up Amazon SES to send notifications: + Email and Amazon SNS notifications apply to individual identities (the verified email addresses or domains you use to send email). When you enable notifications for an identity, Amazon SES only sends notifications for emails sent from that identity, and only in the AWS Region you configured notifications in. + You have to enable one method of receiving bounce or complaint notifications. You can send notifications to the domain or email address that generated the bounce or complaint, or to an Amazon SNS topic. You can also use [event publishing](monitor-using-event-publishing.md) to send notifications about several different types of events (including bounces, complaints, deliveries, and more) to an Amazon SNS topic or an Firehose stream. If you don't set up one of these methods of receiving bounce or complaint notifications, Amazon SES automatically forwards bounce and complaint notifications to the Return-Path address (or the Source address, if you didn't specify a Return-Path address) in the email that resulted in the bounce or complaint event, even if you disabled email feedback forwarding. If you disable email feedback forwarding and enable event publishing, you must apply the configuration set that contains the event publishing rule to all emails you send. In this situation, if you don't use the configuration set, Amazon SES automatically forwards bounce and complaint notifications to the Return-Path or Source address in the email that resulted in the bounce or complaint event. + If you set up Amazon SES to send bounce and complaint events using more than one method (such as by sending email notifications and by using sending events), you may receive more than one notification for the same event. # Receiving Amazon SES notifications through email Receive notifications through email Amazon SES can send you email when you receive bounces and complaints by using a process called *email feedback forwarding*. In order to send email using Amazon SES, you must configure it to send bounce and complaint notifications by using one of the following methods: + By enabling email feedback forwarding. The procedure for setting up this type of notification is included in this section. + By sending notifications to an Amazon SNS topic. For more information, see [Receiving Amazon SES notifications using Amazon SNS](monitor-sending-activity-using-notifications-sns.md). + By publishing event notifications. For more information, see [Monitor email sending using Amazon SES event publishing](monitor-using-event-publishing.md). **Important** For several important points about notifications, see [Setting up event notifications for Amazon SES](monitor-sending-activity-using-notifications.md). **Topics** + [ ## Enabling email feedback forwarding ](#monitor-sending-activity-using-notifications-email-enabling) + [ ## Disabling email feedback forwarding ](#monitor-sending-activity-using-notifications-email-disabling) + [ ## Email feedback forwarding destination ](#monitor-sending-activity-using-notifications-email-destination) ## Enabling email feedback forwarding Enabling email feedback forwarding with Amazon SES Email feedback forwarding is enabled by default. If you previously disabled it, you can enable it by following the procedures in this section. **To enable bounce and complaint forwarding through email using the Amazon SES console** 1. Sign in to the AWS Management Console and open the Amazon SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the navigation pane, under **Configuration**, choose **Verified identities**. 1. In the list of verified email addresses or domains, choose the email address or domain that you want to configure bounce and complaint notifications for. 1. In the details pane, expand the **Notifications** section. 1. Choose **Edit Configuration**. 1. Under **Email Feedback Forwarding**, choose **Enabled**. **Note** Changes you make on this page may take a few minutes to take effect. You can also enable bounce and complaint notifications through email by using the [ SetIdentityFeedbackForwardingEnabled](https://docs.aws.amazon.com/ses/latest/APIReference/API_SetIdentityFeedbackForwardingEnabled.html) API operation. ## Disabling email feedback forwarding Disabling Email Feedback Forwarding with Amazon SES If you set up a different method of providing bounce and complaint notifications, you can disable email feedback forwarding so that you don't receive multiple notifications when a bounce or complaint event occurs. **To disable bounce and complaint forwarding through email using the Amazon SES console** 1. Sign in to the AWS Management Console and open the Amazon SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the navigation pane, under **Configuration**, choose **Verified identities**. 1. In the list of verified email addresses or domains, choose the email address or domain that you want to configure bounce and complaint notifications for. 1. In the details pane, expand the **Notifications** section. 1. Choose **Edit Configuration**. 1. Under **Email Feedback Forwarding**, choose **Disabled**. **Note** You must configure one method of receiving bounce and complaint notifications in order to send email through Amazon SES. If you disable email feedback forwarding, you must enable notifications sent by Amazon SNS, or publish bounce and complaint events to an Amazon SNS topic or a Firehose stream by using [event publishing](monitor-using-event-publishing.md). If you use event publishing, you must also apply the configuration set that contains the event publishing rule to each email you send. If you don't set up a method of receiving bounce and complaint notifications, Amazon SES automatically forwards feedback notifications by email to the address in the Return-Path field (or the Source field, if you didn't specify a Return-Path address) of the message that resulted in the bounce or complaint event. In this situation, Amazon SES forwards bounce and complaint notifications even if you disabled email feedback notifications. 1. To save your notification configuration, choose **Save Config**. **Note** Changes you make on this page might take a few minutes to take effect. You can also disable bounce and complaint notifications through email by using the [SetIdentityFeedbackForwardingEnabled](https://docs.aws.amazon.com/ses/latest/APIReference/API_SetIdentityFeedbackForwardingEnabled.html) API operation. ## Email feedback forwarding destination Amazon SES Email feedback forwarding destination When you receive notifications by email, Amazon SES rewrites the `From` header and sends the notification to you. The address to which Amazon SES forwards the notification depends on how you sent the original message. If you used the SMTP interface to send the message, then the notifications are delivered according to the following rules:. + If you specified a `Return-Path` header in the `SMTP DATA` section, then notifications go to that address. + Otherwise, notifications go to the address you specified when you issued the MAIL FROM command. If you used the `SendEmail` API operation to send the message, then the notifications are delivered according to the following rules: + If you specified the optional `ReturnPath` parameter in your call to the `SendEmail` API, then notifications go to that address. + Otherwise, notifications go to the address specified in the required `Source` parameter of `SendEmail`. If you used the `SendRawEmail` API operation to send the message, then the notifications are delivered according to the following rules: + If you specified a `Return-Path` header in the raw message, then notifications go to that address. + Otherwise, if you specified a `Source` parameter in your call to the `SendRawEmail` API, then notifications go to that address. + Otherwise, notifications go to the address in the `From` header of the raw message. **Note** When you specify a `Return-Path` address in an email, you receive notifications at that address. However, the version of the message that the recipient receives contains a `Return-Path` header that includes an anonymized email address (such as *a0b1c2d3e4f5a6b7-c8d9e0f1-a2b3-c4d5-e6f7-a8b9c0d1e2f3-000000@amazonses.com*). This anonymization happens regardless of how you sent the email. # Receiving Amazon SES notifications using Amazon SNS Receive notifications using Amazon SNS You can configure Amazon SES to notify an Amazon SNS topic when you receive bounces or complaints, or when emails are delivered. Amazon SNS notifications are in [JavaScript Object Notation (JSON)](http://www.json.org) format, which enables you to process them programmatically. In order to send email using Amazon SES, you must configure it to send bounce and complaint notifications by using one of the following methods: + By sending notifications to an Amazon SNS topic. The procedure for setting up this type of notification is included in this section. + By enabling email feedback forwarding. For more information, see [Receiving Amazon SES notifications through email](monitor-sending-activity-using-notifications-email.md). + By publishing event notifications. For more information, see [Monitor email sending using Amazon SES event publishing](monitor-using-event-publishing.md). **Important** See [Setting up event notifications for Amazon SES](monitor-sending-activity-using-notifications.md) for important information about notifications. **Topics** + [ # Configuring Amazon SNS notifications for Amazon SES ](configure-sns-notifications.md) + [ # Amazon SNS notification contents for Amazon SES ](notification-contents.md) + [ # Amazon SNS notification examples for Amazon SES ](notification-examples.md) # Configuring Amazon SNS notifications for Amazon SES Configuring Amazon SNS notifications Amazon SES can notify you of your bounces, complaints, and deliveries through [Amazon Simple Notification Service (Amazon SNS)](https://aws.amazon.com/sns). You can configure notifications in the Amazon SES console, or by using the Amazon SES API. **Topics** + [ ## Prerequisites ](#configure-feedback-notifications-prerequisites) + [ ## Configuring notifications using the Amazon SES console ](#configure-feedback-notifications-console) + [ ## Configuring notifications using the Amazon SES API ](#configure-feedback-notifications-api) + [ ## Troubleshooting feedback notifications ](#configure-feedback-notifications-troubleshooting) ## Prerequisites Complete the following steps before you set up Amazon SNS notifications in Amazon SES: 1. Create a topic in Amazon SNS. For more information, see [Create a Topic](https://docs.aws.amazon.com/sns/latest/dg/CreateTopic.html) in the *Amazon Simple Notification Service Developer Guide*. **Important** When you create your topic using Amazon SNS, for **Type**, only choose **Standard**. (SES does not support FIFO type topics.) Whether you create a new SNS topic or select an existing one, you need to give access to SES to publish notifications to the topic. To give Amazon SES permission to publish notifications to the topic, on the **Edit topic** screen in the SNS console, expand **Access policy** and in the **JSON editor**, add the following permission policy: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "notification-policy", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ses.amazonaws.com" }, "Action": "sns:Publish", "Resource": "arn:aws:sns:us-east-1:111122223333:topic_name", "Condition": { "StringEquals": { "AWS:SourceAccount": "111122223333", "AWS:SourceArn": "arn:aws:ses:topic_region:111122223333:identity/identity_name" } } } ] } ``` ------ Make the following changes to the preceding policy example: + Replace *topic\$1region* with the AWS Region where you created the SNS topic. + Replace *111122223333* with your AWS account ID. + Replace *topic\$1name* with the name of your SNS topic. + Replace *identity\$1name* with the verified identity (email address or domain) that you're subscribing to the SNS topic. 1. Subscribe at least one endpoint to the topic. For example, if you want to receive notifications by text message, subscribe an SMS endpoint (that is, a mobile phone number) to the topic. To receive notifications by email, subscribe an email endpoint (an email address) to the topic. For more information, see [Getting Started](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html) in the *Amazon Simple Notification Service Developer Guide*. 1. (Optional) If your Amazon SNS topic uses AWS Key Management Service (AWS KMS) for server-side encryption, you have to add permissions to the AWS KMS key policy. You can add permissions by attaching the following policy to the AWS KMS key policy: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowSESToUseKMSKey", "Effect": "Allow", "Principal": { "Service": "ses.amazonaws.com" }, "Action": [ "kms:GenerateDataKey", "kms:Decrypt" ], "Resource": "*" } ] } ``` ------ ## Configuring notifications using the Amazon SES console **To configure notifications using the Amazon SES console** 1. Open the Amazon SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the navigation pane, under **Configuration**, choose **Identities**. 1. In the **Identities** container, select the verified identity you want to receive feedback notifications for when a message sent from this identity results in either a bounce, complaint, or delivery. **Important** Verified domain notification settings apply to all mail sent from email addresses in that domain *except* for email addresses that are also verified. 1. In the details screen of the verified identity you selected, choose the **Notifications** tab and select **Edit** in the **Feedback notifications** container. 1. Expand the SNS topic list box of each feedback type you want to receive notifications for, and select either an SNS topic you own, **No SNS topic**, or **SNS topic you don’t own**. 1. If you chose **SNS topic you don’t own**, the **SNS topic ARN** field will be presented where you must enter the SNS topic ARN shared with you by your delegate sender. (Only your delegate sender will get these notifications because they own the SNS topic. To learn more about delegate sending, see [Overview of sending authorization](sending-authorization-overview.md).) **Important** The Amazon SNS topics that you use for bounce, complaint, and delivery notifications have to be in the same AWS Region that in which you use Amazon SES. Additionally, you have to subscribe one or more endpoints to the topic in order to receive notifications. For example, if you want to have notifications sent to an email address, you have to subscribe an email endpoint to the topic. For more information, see [Getting Started](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html) in the *Amazon Simple Notification Service Developer Guide*. 1. (Optional) If you want your topic notification to include the headers from the original email, check the **Include original email headers** box directly underneath the SNS topic name of each feedback type. This option is only available if you've assigned an Amazon SNS topic to the associated notification type. For information about the contents of the original email headers, see the `mail` object in [Notification contents](notification-contents.md). 1. Choose **Save changes**. The changes you made to your notification settings might take a few minutes to take effect. 1. (Optional) If you chose Amazon SNS topic notifications for both bounces and complaints, you can disable email notifications entirely so that you don't receive double notifications through email and SNS notifications. To disable email notifications for bounces and complaints, under the **Notifications** tab on the details screen of the verified identity, in the **Email Feedback Forwarding** container, choose **Edit**, uncheck the **Enabled** box, and choose **Save changes**. . After you configure your settings, you will start receiving bounce, complaint, and delivery notifications to your Amazon SNS topics. These notifications are in JavaScript Object Notation (JSON) format and follow the structure described in [Notification contents](notification-contents.md). You will be charged standard Amazon SNS rates for bounce, complaint, and delivery notifications. For more information, see the [Amazon SNS pricing page](https://aws.amazon.com/sns/pricing). **Note** If an attempt to publish to your Amazon SNS topic fails because the topic has been deleted or your AWS account no longer has permissions to publish to it, Amazon SES removes the configuration for that topic if it's been configured for bounces or complaints (not deliveries - for delivery notifications, SES won't delete the SNS topic configuration setting). Additionally, Amazon SES re-enables bounce and complaint email notifications for the identity, and you receive a notification of the change by email. If multiple identities are configured to use the topic, the topic configuration for each identity is changed when each identity experiences a failure to publish to the topic. ## Configuring notifications using the Amazon SES API You can also configure bounce, complaint, and delivery notifications by using the Amazon SES API. Use the following operations to configure notifications: + [SetIdentityNotificationTopic](https://docs.aws.amazon.com/ses/latest/APIReference/API_SetIdentityNotificationTopic.html) + [SetIdentityFeedbackForwardingEnabled](https://docs.aws.amazon.com/ses/latest/APIReference/API_SetIdentityFeedbackForwardingEnabled.html) + [GetIdentityNotificationAttributes](https://docs.aws.amazon.com/ses/latest/APIReference/API_GetIdentityNotificationAttributes.html) + [SetIdentityHeadersInNotificationsEnabled](https://docs.aws.amazon.com/ses/latest/APIReference/API_SetIdentityHeadersInNotificationsEnabled.html) You can use these API actions to write a customized front-end application for notifications. For a complete description of the API actions related to notifications, see the [Amazon Simple Email Service API Reference](https://docs.aws.amazon.com/ses/latest/APIReference/). ## Troubleshooting feedback notifications **Not receiving notifications** If you aren't receiving notifications, make sure that you subscribed an endpoint to the topic that the notifications are sent through. When you subscribe an email endpoint to a topic, you receive an email asking you to confirm your subscription. You have to confirm your subscription before you start receiving email notifications. For more information, see [Getting Started](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html) in the *Amazon Simple Notification Service Developer Guide*. **`InvalidParameterValue` error when choosing a topic** If you receive an error stating that an `InvalidParameterValue` error occurred, check the Amazon SNS topic to see if it's encrypted using AWS KMS. If it is, you have to modify the policy for the AWS KMS key. See [Prerequisites](#configure-feedback-notifications-prerequisites) for a sample policy. # Amazon SNS notification contents for Amazon SES Notification contents Bounce, complaint, and delivery notifications are published to [Amazon Simple Notification Service (Amazon SNS)](https://aws.amazon.com/sns) topics in JavaScript Object Notation (JSON) format. The top-level JSON object contains a `notificationType` string, a `mail` object, and either a `bounce` object, a `complaint` object, or a `delivery` object. See the following sections for descriptions of the different types of objects: + [Top-level JSON object](#top-level-json-object) + [`mail` object](#mail-object) + [`bounce` object](#bounce-object) + [`complaint` object](#complaint-object) + [`delivery` object](#delivery-object) The following are some important notes about the contents of Amazon SNS notifications for Amazon SES: + For a given notification type, you might receive one Amazon SNS notification for multiple recipients, or you might receive a single Amazon SNS notification per recipient. Your code should be able to parse the Amazon SNS notification and handle both cases; SES does not make ordering or batching guarantees for notifications sent through Amazon SNS. However, different Amazon SNS notification types (for example, bounces and complaints) are not combined into a single notification. + You might receive multiple types of Amazon SNS notifications for one recipient. For example, the receiving mail server might accept the email (triggering a delivery notification), but after processing the email, the receiving mail server might determine that the email actually results in a bounce (triggering a bounce notification). However, these are always separate notifications because they are different notification types. + SES reserves the right to add additional fields to the notifications. As such, applications that parse these notifications must be flexible enough to handle unknown fields. + SES overwrites the headers of the message when it sends the email. You can retrieve the headers of the original message from the `headers` and `commonHeaders` fields of the `mail` object. ## Top-Level JSON object Top-level JSON object The top-level JSON object in an SES notification contains the following fields. | Field name | Description | | --- | --- | | notificationType | A string that holds the type of notification represented by the JSON object. Possible values are `Bounce`, `Complaint`, or `Delivery`. If you [set up event publishing](monitor-sending-using-event-publishing-setup.md), this field is named `eventType`. | | mail | A JSON object that contains information about the original mail to which the notification pertains. For more information, see [Mail object](#mail-object). | | bounce | This field is present only if the `notificationType` is `Bounce` and contains a JSON object that holds information about the bounce. For more information, see [Bounce object](#bounce-object). | | complaint | This field is present only if the `notificationType` is `Complaint` and contains a JSON object that holds information about the complaint. For more information, see [Complaint object](#complaint-object). | | delivery | This field is present only if the `notificationType` is `Delivery` and contains a JSON object that holds information about the delivery. For more information, see [Delivery object](#delivery-object). | ## Mail object `mail` object Each bounce, complaint, or delivery notification contains information about the original email in the `mail` object. The JSON object that contains information about a `mail` object has the following fields. | Field name | Description | | --- | --- | | timestamp | The time at which the original message was sent (in ISO8601 format). | | messageId | A unique ID that SES assigned to the message. SES returned this value to you when you sent the message. This message ID was assigned by SES. You can find the message ID of the original email in the `headers` field of the `mail` object. | | source | The email address from which the original message was sent (the envelope MAIL FROM address). | | sourceArn | The Amazon Resource Name (ARN) of the identity that was used to send the email. In the case of sending authorization, the `sourceArn` is the ARN of the identity that the identity owner authorized the delegate sender to use to send the email. For more information about sending authorization, see [Email authentication methodsUsing sending authorization](sending-authorization.md). | | sourceIp | The originating public IP address of the client that performed the email sending request to SES. | | sendingAccountId | The AWS account ID of the account that was used to send the email. In the case of sending authorization, the `sendingAccountId` is the delegate sender's account ID. | | callerIdentity | The IAM identity of the SES user who sent the email. | | destination | A list of email addresses that were recipients of the original mail. | | headersTruncated | This object is only present if you configured the notification settings to include the headers from the original email. Indicates whether the headers are truncated in the notification. SES truncates the headers in the notification when the headers from the original message are 10 KB or larger in size. Possible values are `true` and `false`. | | headers | This object is only present if you configured the notification settings to include the headers from the original email. A list of the email's original headers. Each header in the list has a `name` field and a `value` field. Any message ID within the `headers` object is from the original message that you passed to SES. The message ID that SES subsequently assigned to the message is in the `messageId` field of the `mail` object. | | commonHeaders | This object is only present if you configured the notification settings to include the headers from the original email. Includes information about common email headers from the original email, including the From, To, and Subject fields. Within this object, each header is a key. The From and To fields are represented by arrays that can contain multiple values. For events, any message ID within the `commonHeaders` field is the message ID that Amazon SES subsequently assigned to the message in the `messageId` field of the mail object. Notifications will contain the message ID of the original email. | The following is an example of a `mail` object that includes the original email headers. When this notification type is not configured to include the original email headers, the `mail` object does not include the `headersTruncated`, `headers`, and `commonHeaders` fields. ``` { "timestamp":"2018-10-08T14:05:45 +0000", "messageId":"000001378603177f-7a5433e7-8edb-42ae-af10-f0181f34d6ee-000000", "source":"sender@example.com", "sourceArn": "arn:aws:ses:us-east-1:888888888888:identity/example.com", "sourceIp": "127.0.3.0", "sendingAccountId":"123456789012", "destination":[ "recipient@example.com" ], "headersTruncated":false, "headers":[ { "name":"From", "value":"\"Sender Name\" " }, { "name":"To", "value":"\"Recipient Name\" " }, { "name":"Message-ID", "value":"custom-message-ID" }, { "name":"Subject", "value":"Hello" }, { "name":"Content-Type", "value":"text/plain; charset=\"UTF-8\"" }, { "name":"Content-Transfer-Encoding", "value":"base64" }, { "name":"Date", "value":"Mon, 08 Oct 2018 14:05:45 +0000" } ], "commonHeaders":{ "from":[ "Sender Name " ], "date":"Mon, 08 Oct 2018 14:05:45 +0000", "to":[ "Recipient Name " ], "messageId":" custom-message-ID", "subject":"Message sent using SES" } } ``` ## Bounce object `bounce` object The JSON object that contains information about bounces contains the following fields. | Field name | Description | | --- | --- | | bounceType | The type of bounce, as determined by SES. For more information, see [Bounce types](#bounce-types). | | bounceSubType | The subtype of the bounce, as determined by SES. For more information, see [Bounce types](#bounce-types). | | bouncedRecipients | A list that contains information about the recipients of the original mail that bounced. For more information, see [Bounced recipients](#bounced-recipients). | | timestamp | The date and time at which the bounce was sent (in ISO8601 format). Note that this is the time at which the notification was sent by the ISP, and not the time at which it was received by SES. | | feedbackId | A unique ID for the bounce. | If SES was able to contact the remote Message Transfer Authority (MTA), the following field is also present. | Field name | Description | | --- | --- | | remoteMtaIp | The IP address of the MTA to which SES attempted to deliver the email. | If a delivery status notification (DSN) was attached to the bounce, the following field is also present. | Field name | Description | | --- | --- | | reportingMTA | The value of the `Reporting-MTA` field from the DSN. This is the value of the MTA that attempted to perform the delivery, relay, or gateway operation described in the DSN. | The following is an example of a `bounce` object. ``` { "bounceType":"Permanent", "bounceSubType": "General", "bouncedRecipients":[ { "status":"5.0.0", "action":"failed", "diagnosticCode":"smtp; 550 user unknown", "emailAddress":"recipient1@example.com" }, { "status":"4.0.0", "action":"delayed", "emailAddress":"recipient2@example.com" } ], "reportingMTA": "example.com", "timestamp":"2012-05-25T14:59:38.605Z", "feedbackId":"000001378603176d-5a4b5ad9-6f30-4198-a8c3-b1eb0c270a1d-000000", "remoteMtaIp":"127.0.2.0" } ``` ### Bounced recipients A bounce notification may pertain to a single recipient or to multiple recipients. The `bouncedRecipients` field holds a list of objects—one per recipient to whom the bounce notification pertains—and always contains the following field. | Field name | Description | | --- | --- | | emailAddress | The email address of the recipient. If a DSN is available, this is the value of the `Final-Recipient` field from the DSN. | Optionally, if a DSN is attached to the bounce, the following fields may also be present. | Field name | Description | | --- | --- | | action | The value of the `Action` field from the DSN. This indicates the action performed by the Reporting-MTA as a result of its attempt to deliver the message to this recipient. | | status | The value of the `Status` field from the DSN. This is the per-recipient transport-independent status code that indicates the delivery status of the message. | | diagnosticCode | The status code issued by the reporting MTA. This is the value of the `Diagnostic-Code` field from the DSN. This field may be absent in the DSN (and therefore also absent in the JSON). | The following is an example of an object that might be in the `bouncedRecipients` list. ``` { "emailAddress": "recipient@example.com", "action": "failed", "status": "5.0.0", "diagnosticCode": "X-Postfix; unknown user" } ``` ### Bounce types The bounce object contains a bounce type of `Undetermined`, `Permanent` *(hard)*, or `Transient` *(soft)*. The `Permanent` *(hard)* and `Transient` *(soft)* bounce types can also contain one of several bounce subtypes. When you receive a bounce notification with a bounce type of `Transient` *(soft)*, you might be able to send email to that recipient in the future if the issue that caused the message to bounce is resolved. When you receive a bounce notification with a bounce type of `Permanent` *(hard)*, it's unlikely that you'll be able to send email to that recipient in the future. For this reason, you should immediately remove the recipient whose address produced the bounce from your mailing lists. **Note** When a *soft bounce* (a bounce related to a temporary issue, such as the recipient's inbox being full) occurs, SES attempts to redeliver the email for a certain period of time. At the end of that period of time, if SES still can't deliver the email, it stops trying. SES provides notifications for hard bounces, and for soft bounces that it stopped trying to deliver. If you want to receive a notification each time a soft bounce occurs, [enable event publishing](monitor-sending-using-event-publishing-setup.md) and configure it to send notifications when delivery delay events occur. | bounceType | bounceSubType | Description | | --- | --- | --- | | Undetermined | Undetermined | The recipient's email provider sent a bounce message. The bounce message didn't contain enough information for SES to determine the reason for the bounce. The bounce email, which was sent to the address in the Return-Path header of the email that resulted in the bounce, might contain additional information about the issue that caused the email to bounce. | | Permanent | General | The recipient's email provider sent a hard bounce message. When you receive this type of bounce notification, you should immediately remove the recipient's email address from your mailing list. Sending messages to addresses that produce hard bounces can have a negative impact on your reputation as a sender. If you continue sending email to addresses that produce hard bounces, we might pause your ability to send additional email. See [Using the Amazon SES account-level suppression list](sending-email-suppression-list.md). | | Permanent | NoEmail | It was not possible to retrieve the recipient email address from the bounce message. | | Permanent | Suppressed | The recipient's email address is on the SES suppression list because it has a recent history of producing hard bounces. To override the global suppression list, see [Using the Amazon SES account-level suppression list](sending-email-suppression-list.md). | | Permanent | OnAccountSuppressionList | SES has suppressed sending to this address because it is on the [account-level suppression list](sending-email-suppression-list.md). This does not count toward your bounce rate metric. | | Permanent | UnsubscribedRecipient | This bounce type occurs when the recipient contact has unsubscribed from the topic and a mail is sent to them using [list management options](sending-email-list-management.md#configuring-list-management-list-contacts). SES respects the contact preference and doesn't attempt delivery. Also, this bounce doesn't impact sender reputation since the delivery was not attempted, nor is the recipient contact added to a suppression list due to the bounce. It's recommended that you subscribe to UnsubscribedRecipient events to avoid continued sending to to unsubscribed recipients. Consider [Using list management](sending-email-list-management.md). List management should be the source of truth for your subscriber list. From the perspective of SES enforcement, if you continue to send to suppressed or unsubscribed recipients, you'll have the reputation of not adhering to best practices for email sending. | | Transient | General | The recipient's email provider sent a general bounce message. You might be able to send a message to the same recipient in the future if the issue that caused the message to bounce is resolved. If you send an email to a recipient who has an active automatic response rule (such as an "out of the office" message), you might receive this type of notification. Even though the response has a notification type of `Bounce`, SES doesn't count automatic responses when it calculates the bounce rate for your account. | | Transient | MailboxFull | The recipient's email provider sent a bounce message because the recipient's inbox was full. You might be able to send to the same recipient in the future when the mailbox is no longer full. | | Transient | MessageTooLarge | The recipient's email provider sent a bounce message because message you sent was too large. You might be able to send a message to the same recipient if you reduce the size of the message. | | Transient | ContentRejected | The recipient's email provider sent a bounce message because the message you sent contains content that the provider doesn't allow. You might be able to send a message to the same recipient if you change the content of the message. | | Transient | AttachmentRejected | The recipient's email provider sent a bounce message because the message contained an unacceptable attachment. For example, some email providers may reject messages with attachments of a certain file type, or messages with very large attachments. You might be able to send a message to the same recipient if you remove or change the content of the attachment. | ## Complaint object `complaint` object The JSON object that contains information about complaints has the following fields. | Field name | Description | | --- | --- | | complainedRecipients | A list that contains information about recipients that may have been responsible for the complaint. For more information, see [Complained recipients](#complained-recipients). | | timestamp | The date and time when the ISP sent the complaint notification, in ISO 8601 format. The date and time in this field might not be the same as the date and time when SES received the notification. | | feedbackId | A unique ID associated with the complaint. | | complaintSubType | The value of the `complaintSubType` field can either be null or `OnAccountSuppressionList`. If the value is `OnAccountSuppressionList`, SES accepted the message, but didn't attempt to send it because it was on the [account-level suppression list](sending-email-suppression-list.md). | Further, if a feedback report is attached to the complaint, the following fields may be present. | Field name | Description | | --- | --- | | userAgent | The value of the `User-Agent` field from the feedback report. This indicates the name and version of the system that generated the report. | | complaintFeedbackType | The value of the `Feedback-Type` field from the feedback report received from the ISP. This contains the type of feedback. | | arrivalDate | The value of the `Arrival-Date` or `Received-Date` field from the feedback report (in ISO8601 format). This field may be absent in the report (and therefore also absent in the JSON). | The following is an example of a `complaint` object. ``` { "userAgent":"ExampleCorp Feedback Loop (V0.01)", "complainedRecipients":[ { "emailAddress":"recipient1@example.com" } ], "complaintFeedbackType":"abuse", "arrivalDate":"2009-12-03T04:24:21.000-05:00", "timestamp":"2012-05-25T14:59:38.623Z", "feedbackId":"000001378603177f-18c07c78-fa81-4a58-9dd1-fedc3cb8f49a-000000" } ``` ### Complained recipients The `complainedRecipients` field contains a list of recipients that may have submitted the complaint. You should use this information to determine which recipient submitted the complaint, and then immediately remove that recipient from your mailing lists. **Important** Most ISPs remove the email address of the recipient who submitted the complaint from their complaint notification. For this reason, this list contains information about recipients who might have sent the complaint, based on the recipients of the original message and the ISP from which we received the complaint. SES performs a lookup against the original message to determine this recipient list. JSON objects in this list contain the following field. | Field name | Description | | --- | --- | | emailAddress | The email address of the recipient. | The following is an example of a complained recipient object. ``` { "emailAddress": "recipient1@example.com" } ``` **Note** Because of this behavior, you can be more certain that you know which email address complained about your message if you limit your sending to one message per recipient (rather than sending one message with 30 different email addresses in the bcc line). #### Complaint types You may see the following complaint types in the `complaintFeedbackType` field as assigned by the reporting ISP, according to the [Internet Assigned Numbers Authority website](http://www.iana.org/assignments/marf-parameters/marf-parameters.xml#marf-parameters-2): + `abuse`—Indicates unsolicited email or some other kind of email abuse. + `auth-failure`—Email authentication failure report. + `fraud`—Indicates some kind of fraud or phishing activity. + `not-spam`—Indicates that the entity providing the report does not consider the message to be spam. This may be used to correct a message that was incorrectly tagged or categorized as spam. + `other`—Indicates any other feedback that does not fit into other registered types. + `virus`—Reports that a virus is found in the originating message. ## Delivery object `delivery` object The JSON object that contains information about deliveries always has the following fields. | Field name | Description | | --- | --- | | timestamp | The time SES delivered the email to the recipient's mail server (in ISO8601 format). | | processingTimeMillis | The time in milliseconds between when SES accepted the request from the sender to passing the message to the recipient's mail server. | | recipients | A list of the intended recipients of the email to which the delivery notification applies. | | smtpResponse | The SMTP response message of the remote ISP that accepted the email from SES. This message varies by email, by receiving mail server, and by receiving ISP. | | reportingMTA | The hostname of the SES mail server that sent the mail. | | remoteMtaIp | The IP address of the MTA to which SES delivered the email. | The following is an example of a `delivery` object. ``` { "timestamp":"2014-05-28T22:41:01.184Z", "processingTimeMillis":546, "recipients":["success@simulator.amazonses.com"], "smtpResponse":"250 ok: Message 64111812 accepted", "reportingMTA":"a8-70.smtp-out.amazonses.com", "remoteMtaIp":"127.0.2.0" } ``` # Amazon SNS notification examples for Amazon SES Notification examples The following sections provide examples of the three types of notifications: + For bounce notification examples, see [Amazon SNS bounce notification examples](#notification-examples-bounce). + For complaint notification examples, see [Amazon SNS complaint notification examples](#notification-examples-complaint). + For delivery notification examples, see [Amazon SNS delivery notification example](#notification-examples-delivery). ## Amazon SNS bounce notification examples This section contains examples of bounce notifications with and without a Delivery Status Notification (DSN) provided by the email receiver that sent the feedback. ### Bounce notification with a DSN The following is an example of a bounce notification that contains a DSN and the original email headers. When bounce notifications are not configured to include the original email headers, the `mail` object within the notifications does not include the `headersTruncated`, `headers`, and `commonHeaders` fields. ``` { "notificationType":"Bounce", "bounce":{ "bounceType":"Permanent", "reportingMTA":"dns; email.example.com", "bouncedRecipients":[ { "emailAddress":"jane@example.com", "status":"5.1.1", "action":"failed", "diagnosticCode":"smtp; 550 5.1.1 ... User" } ], "bounceSubType":"General", "timestamp":"2016-01-27T14:59:38.237Z", "feedbackId":"00000138111222aa-33322211-cccc-cccc-cccc-ddddaaaa068a-000000", "remoteMtaIp":"127.0.2.0" }, "mail":{ "timestamp":"2016-01-27T14:59:38.237Z", "source":"john@example.com", "sourceArn": "arn:aws:ses:us-east-1:888888888888:identity/example.com", "sourceIp": "127.0.3.0", "sendingAccountId":"123456789012", "callerIdentity": "IAM_user_or_role_name", "messageId":"00000138111222aa-33322211-cccc-cccc-cccc-ddddaaaa0680-000000", "destination":[ "jane@example.com", "mary@example.com", "richard@example.com"], "headersTruncated":false, "headers":[ { "name":"From", "value":"\"John Doe\" " }, { "name":"To", "value":"\"Jane Doe\" , \"Mary Doe\" , \"Richard Doe\" " }, { "name":"Message-ID", "value":"custom-message-ID" }, { "name":"Subject", "value":"Hello" }, { "name":"Content-Type", "value":"text/plain; charset=\"UTF-8\"" }, { "name":"Content-Transfer-Encoding", "value":"base64" }, { "name":"Date", "value":"Wed, 27 Jan 2016 14:05:45 +0000" } ], "commonHeaders":{ "from":[ "John Doe " ], "date":"Wed, 27 Jan 2016 14:05:45 +0000", "to":[ "Jane Doe , Mary Doe , Richard Doe " ], "messageId":"custom-message-ID", "subject":"Hello" } } } ``` ### Bounce notification without a DSN The following is an example of a bounce notification that includes the original email headers but does not include a DSN. When bounce notifications are not configured to include the original email headers, the `mail` object within the notifications does not include the `headersTruncated`, `headers`, and `commonHeaders` fields. ``` { "notificationType":"Bounce", "bounce":{ "bounceType":"Permanent", "bounceSubType": "General", "bouncedRecipients":[ { "emailAddress":"jane@example.com" }, { "emailAddress":"richard@example.com" } ], "timestamp":"2016-01-27T14:59:38.237Z", "feedbackId":"00000137860315fd-869464a4-8680-4114-98d3-716fe35851f9-000000", "remoteMtaIp":"127.0.2.0" }, "mail":{ "timestamp":"2016-01-27T14:59:38.237Z", "messageId":"00000137860315fd-34208509-5b74-41f3-95c5-22c1edc3c924-000000", "source":"john@example.com", "sourceArn": "arn:aws:ses:us-east-1:888888888888:identity/example.com", "sourceIp": "127.0.3.0", "sendingAccountId":"123456789012", "callerIdentity": "IAM_user_or_role_name", "destination":[ "jane@example.com", "mary@example.com", "richard@example.com" ], "headersTruncated":false, "headers":[ { "name":"From", "value":"\"John Doe\" " }, { "name":"To", "value":"\"Jane Doe\" , \"Mary Doe\" , \"Richard Doe\" " }, { "name":"Message-ID", "value":"custom-message-ID" }, { "name":"Subject", "value":"Hello" }, { "name":"Content-Type", "value":"text/plain; charset=\"UTF-8\"" }, { "name":"Content-Transfer-Encoding", "value":"base64" }, { "name":"Date", "value":"Wed, 27 Jan 2016 14:05:45 +0000" } ], "commonHeaders":{ "from":[ "John Doe " ], "date":"Wed, 27 Jan 2016 14:05:45 +0000", "to":[ "Jane Doe , Mary Doe , Richard Doe " ], "messageId":"custom-message-ID", "subject":"Hello" } } } ``` ## Amazon SNS complaint notification examples This section contains examples of complaint notifications, with and without a feedback report, provided by the email receiver that sent the feedback. ### Complaint notification with a feedback report The following is an example of a complaint notification that contains a feedback report and the original email headers. When complaint notifications are not configured to include the original email headers, the `mail` object within the notifications does not include the `headersTruncated`, `headers`, and `commonHeaders` fields. ``` { "notificationType":"Complaint", "complaint":{ "userAgent":"AnyCompany Feedback Loop (V0.01)", "complainedRecipients":[ { "emailAddress":"richard@example.com" } ], "complaintFeedbackType":"abuse", "arrivalDate":"2016-01-27T14:59:38.237Z", "timestamp":"2016-01-27T14:59:38.237Z", "feedbackId":"000001378603177f-18c07c78-fa81-4a58-9dd1-fedc3cb8f49a-000000" }, "mail":{ "timestamp":"2016-01-27T14:59:38.237Z", "messageId":"000001378603177f-7a5433e7-8edb-42ae-af10-f0181f34d6ee-000000", "source":"john@example.com", "sourceArn": "arn:aws:ses:us-east-1:888888888888:identity/example.com", "sourceIp": "127.0.3.0", "sendingAccountId":"123456789012", "callerIdentity": "IAM_user_or_role_name", "destination":[ "jane@example.com", "mary@example.com", "richard@example.com" ], "headersTruncated":false, "headers":[ { "name":"From", "value":"\"John Doe\" " }, { "name":"To", "value":"\"Jane Doe\" , \"Mary Doe\" , \"Richard Doe\" " }, { "name":"Message-ID", "value":"custom-message-ID" }, { "name":"Subject", "value":"Hello" }, { "name":"Content-Type", "value":"text/plain; charset=\"UTF-8\"" }, { "name":"Content-Transfer-Encoding", "value":"base64" }, { "name":"Date", "value":"Wed, 27 Jan 2016 14:05:45 +0000" } ], "commonHeaders":{ "from":[ "John Doe " ], "date":"Wed, 27 Jan 2016 14:05:45 +0000", "to":[ "Jane Doe , Mary Doe , Richard Doe " ], "messageId":"custom-message-ID", "subject":"Hello" } } } ``` ### Complaint notification without a feedback report The following is an example of a complaint notification that includes the original email headers but does not include a feedback report. When complaint notifications are not configured to include the original email headers, the `mail` object within the notifications does not include the `headersTruncated`, `headers`, and `commonHeaders` fields. ``` { "notificationType":"Complaint", "complaint":{ "complainedRecipients":[ { "emailAddress":"richard@example.com" } ], "timestamp":"2016-01-27T14:59:38.237Z", "feedbackId":"0000013786031775-fea503bc-7497-49e1-881b-a0379bb037d3-000000" }, "mail":{ "timestamp":"2016-01-27T14:59:38.237Z", "messageId":"0000013786031775-163e3910-53eb-4c8e-a04a-f29debf88a84-000000", "source":"john@example.com", "sourceArn": "arn:aws:ses:us-east-1:888888888888:identity/example.com", "sourceIp": "127.0.3.0", "sendingAccountId":"123456789012", "callerIdentity": "IAM_user_or_role_name", "destination":[ "jane@example.com", "mary@example.com", "richard@example.com" ], "headersTruncated":false, "headers":[ { "name":"From", "value":"\"John Doe\" " }, { "name":"To", "value":"\"Jane Doe\" , \"Mary Doe\" , \"Richard Doe\" " }, { "name":"Message-ID", "value":"custom-message-ID" }, { "name":"Subject", "value":"Hello" }, { "name":"Content-Type", "value":"text/plain; charset=\"UTF-8\"" }, { "name":"Content-Transfer-Encoding", "value":"base64" }, { "name":"Date", "value":"Wed, 27 Jan 2016 14:05:45 +0000" } ], "commonHeaders":{ "from":[ "John Doe " ], "date":"Wed, 27 Jan 2016 14:05:45 +0000", "to":[ "Jane Doe , Mary Doe , Richard Doe " ], "messageId":"custom-message-ID", "subject":"Hello" } } } ``` ## Amazon SNS delivery notification example The following is an example of a delivery notification that includes the original email headers. When delivery notifications are not configured to include the original email headers, the `mail` object within the notifications does not include the `headersTruncated`, `headers`, and `commonHeaders` fields. ``` { "notificationType":"Delivery", "mail":{ "timestamp":"2016-01-27T14:59:38.237Z", "messageId":"0000014644fe5ef6-9a483358-9170-4cb4-a269-f5dcdf415321-000000", "source":"john@example.com", "sourceArn": "arn:aws:ses:us-east-1:888888888888:identity/example.com", "sourceIp": "127.0.3.0", "sendingAccountId":"123456789012", "callerIdentity": "IAM_user_or_role_name", "destination":[ "jane@example.com" ], "headersTruncated":false, "headers":[ { "name":"From", "value":"\"John Doe\" " }, { "name":"To", "value":"\"Jane Doe\" " }, { "name":"Message-ID", "value":"custom-message-ID" }, { "name":"Subject", "value":"Hello" }, { "name":"Content-Type", "value":"text/plain; charset=\"UTF-8\"" }, { "name":"Content-Transfer-Encoding", "value":"base64" }, { "name":"Date", "value":"Wed, 27 Jan 2016 14:58:45 +0000" } ], "commonHeaders":{ "from":[ "John Doe " ], "date":"Wed, 27 Jan 2016 14:58:45 +0000", "to":[ "Jane Doe " ], "messageId":"custom-message-ID", "subject":"Hello" } }, "delivery":{ "timestamp":"2016-01-27T14:59:38.237Z", "recipients":["jane@example.com"], "processingTimeMillis":546, "reportingMTA":"a8-70.smtp-out.amazonses.com", "smtpResponse":"250 ok: Message 64111812 accepted", "remoteMtaIp":"127.0.2.0" } } ``` # Using identity authorization in Amazon SES Using identity authorization Identity authorization policies define how individual verified identities can use Amazon SES by specifying which SES API actions are allowed or denied for the identity and under what conditions. Through the use of these authorization polices, you can maintain control over your identities by changing or revoking permissions at any time. You can even authorize other users to use the identities that you own (domains or email addresses) with their own SES accounts. **Topics** + [ # Amazon SES policy anatomy ](policy-anatomy.md) + [ # Creating an identity authorization policy in Amazon SES ](identity-authorization-policies-creating.md) + [ # Identity policy examples in Amazon SES ](identity-authorization-policy-examples.md) + [ # Managing your identity authorization policies in Amazon SES ](managing-policies.md) # Amazon SES policy anatomy Policy anatomy Policies adhere to a specific structure, contain elements, and must meet certain requirements. ## Policy structure Each authorization policy is a JSON document that is attached to an identity. Each policy includes the following sections: + Policy-wide information at the top of the document. + One or more individual statements, each of which describes a set of permissions. The following example policy grants AWS account ID *123456789012* permissions specified in the *Action* section for the verified domain *example.com*. ------ #### [ JSON ] **** ``` { "Id":"ExampleAuthorizationPolicy", "Version":"2012-10-17", "Statement":[ { "Sid":"AuthorizeAccount", "Effect":"Allow", "Resource":"arn:aws:ses:us-east-1:123456789012:identity/example.com", "Principal":{ "AWS":[ "123456789012" ] }, "Action":[ "ses:GetEmailIdentity", "ses:UpdateEmailIdentityPolicy", "ses:ListRecommendations", "ses:CreateEmailIdentityPolicy", "ses:DeleteEmailIdentity" ] } ] } ``` ------ You can find more authorization policy examples at [Identity policy examples](identity-authorization-policy-examples.md). ## Policy elements This section describes the elements contained in identity authorization policies. First we describe policy-wide elements, and then we describe elements that apply only to the statement in which they are included. We follow with a discussion of how to add conditions to your statements. For specific information about the syntax of the elements, see [Grammar of the IAM Policy Language](https://docs.aws.amazon.com/IAM/latest/UserGuide/policies-grammar.html) in the *IAM User Guide*. ### Policy-wide information There are two policy-wide elements: `Id` and `Version`. The following table provides information about these elements. **** | Name | Description | Required | Valid values | | --- | --- | --- | --- | | `Id` | Uniquely identifies the policy. | No | Any string | | `Version` | Specifies the policy access language version. | No | Any string. As a best practice, we recommend that you include this field with a value of "2012-10-17". | ### Statements specific to the policy Identity authorization policies require at least one statement. Each statement can include the elements described in the following table. **** | Name | Description | Required | Valid values | | --- | --- | --- | --- | | `Sid` | Uniquely identifies the statement. | No | Any string. | | `Effect` | Specifies the result that you want the policy statement to return at evaluation time. | Yes | "Allow" or "Deny". | | `Resource` | Specifies the identity to which the policy applies. (For [sending authorization](sending-authorization-identity-owner-tasks-policy.md), this is the email address or domain that the identity owner is authorizing the delegate sender to use.) | Yes | The Amazon Resource Name (ARN) of the identity. | | `Principal` | Specifies the AWS account, user, or AWS service that receives the permission in the statement. | Yes | A valid AWS account ID, user ARN, or AWS service. AWS account IDs and user ARNs are specified using `"AWS"` (for example, `"AWS": ["123456789012"]` or `"AWS": ["arn:aws:iam::123456789012:root"]`). AWS service names are specified using `"Service"` (for example, `"Service": ["cognito-idp.amazonaws.com"]`). For examples of the format of user ARNs, see the [AWS General Reference](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html#arn-syntax-iam.html). | | `Action` | Specifies the action that the statement applies to. | Yes | "ses:BatchGetMetricData", "ses:CancelExportJob", "ses:CreateDeliverabilityTestReport", "ses:CreateEmailIdentityPolicy", "ses:CreateExportJob", "ses:DeleteEmailIdentity", "ses:DeleteEmailIdentityPolicy", "ses:GetDomainStatisticsReport", "ses:GetEmailIdentity","ses:GetEmailIdentityPolicies", "ses:GetExportJob", "ses:ListExportJobs", "ses:ListRecommendations", "ses:PutEmailIdentityConfigurationSetAttributes", "ses:PutEmailIdentityDkimAttributes", "ses:PutEmailIdentityDkimSigningAttributes", "ses:PutEmailIdentityFeedbackAttributes", "ses:PutEmailIdentityMailFromAttributes", "ses:TagResource", "ses:UntagResource", "ses:UpdateEmailIdentityPolicy" ([Sending authorization](sending-authorization-identity-owner-tasks-policy.md) actions: "ses:SendEmail", "ses:SendRawEmail", "ses:SendTemplatedEmail", "ses:SendBulkTemplatedEmail") You can specify one or more of these operations. | | `Condition` | Specifies any restrictions or details about the permission. | No | See the information about conditions following this table. | ### Conditions A *condition* is any restriction about the permission in the statement. The part of the statement that specifies the conditions can be the most detailed of all the parts. A *key* is the specific characteristic that's the basis for access restriction, such as the date and time of the request. You use both conditions and keys together to express the restriction. For example, if you want to restrict the delegate sender from making requests to Amazon SES on your behalf after July 30, 2019, you use the condition called `DateLessThan`. You use the key called `aws:CurrentTime` and set it to the value `2019-07-30T00:00:00Z`. SES implements only the following AWS-wide policy keys: + `aws:CurrentTime` + `aws:EpochTime` + `aws:SecureTransport` + `aws:SourceIp` + `aws:SourceVpc` + `aws:SourceVpce` + `aws:UserAgent` + `aws:VpcSourceIp` For more information about these keys, see the [IAM User Guide](https://docs.aws.amazon.com/IAM/latest/UserGuide/AccessPolicyLanguage_ElementDescriptions.html#Condition). ## Policy requirements Policies must meet all of the following requirements: + Each policy has to include at least one statement. + Each policy has to include at least one valid principal. + Each policy has to specify one resource, and that resource has to be the ARN of the identity that the policy is attached to. + Identity owners can associate up to 20 policies with each unique identity. + Policies can't exceed 4 kilobytes (KB) in size. + Policy names can't exceed 64 characters. Additionally, they can only include alphanumeric characters, dashes, and underscores. # Creating an identity authorization policy in Amazon SES Creating an identity authorization policy An identity authorization policy is comprised of statements specifying what API actions are allowed or denied for an identity and under what conditions. To authorize an Amazon SES domain or email address identity that you own, you create an authorization policy, and then attach that policy to the identity. An identity can have zero, one, or many policies. However, a single policy can only be associated with a single identity. For a list of API actions that can be used in an identity authorization policy, see the *Action* row in the [Statements specific to the policy](policy-anatomy.md#identity-authorization-policy-statements) table. You can create an identity authorization policy in the following ways: + **By using the policy generator** – You can create a simple policy by using the policy generator in the SES console. In addition to allowing or denying permissions on SES API actions, you can constrain the actions with conditions. You can also use the policy generator to quickly create the basic structure of a policy and then customize it later by editing the policy. + **By creating a custom policy** – If you want to include more advanced conditions or use an AWS service as the principal, you can create a custom policy and attach it to the identity by using the SES console or the SES API. **Topics** + [ # Using the policy generator ](using-policy-generator.md) + [ # Creating a custom policy ](creating-custom-policy.md) # Using the policy generator You can use the policy generator to create a simple authorization policy by following these steps. **To create a policy by using the policy generator** 1. Sign in to the AWS Management Console and open the Amazon SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the navigation pane, under **Configuration**, choose **Identities**. 1. In the **Identities** container on the **Identities** screen, select the verified identity you wish to create an authorization policy for. 1. In the details screen of the verified identity you selected in the previous step, choose the **Authorization** tab. 1. In the **Authorization policies** pane, choose **Create policy** and select **Use policy generator** from the dropdown. 1. In the **Create statement** pane, choose **Allow** in the **Effect** field. (If you want to create a policy to restrict this identity, choose **Deny** instead.) 1. In the **Principals** field, enter the *AWS account ID*, *IAM user ARN*, or AWS service to receive the permissions you want to authorize for this identity, then choose **Add**. (If you wish to authorize more than one, repeat this step for each one.) 1. In the **Actions** field, select the check box for each action you would like to authorize for your principals. 1. (Optional) Expand **Specify conditions** if you wish to add a qualifying statement to the permission. 1. Select an operator from the **Operator** dropdown. 1. Select a type from the **Key** dropdown. 1. Respective to the key type you selected, enter its value in the **Value** field. (If you wish to add more conditions, choose **Add new condition** and repeat this step for each additional one.) 1. Choose **Save statement**. 1. (Optional) Expand **Create another statement** if you wish to add more statements to your policy and repeat steps 6 - 10. 1. Choose **Next** and on the **Customize policy** screen, the **Edit policy details** container has fields where you can change or customize the policy’s **Name** and the **Policy document** itself. 1. Choose **Next** and on the **Review and apply** screen, the **Overview** container will show the verified identity you’re authorizing as well as the name of this policy. In the **Policy document** pane will be the actual policy you just wrote along with any conditions you added - review the policy and if it looks correct, choose **Apply policy**. (If you need to change or correct something, choose **Previous** and work in the **Edit policy details** container.) # Creating a custom policy If you want to create a custom policy and attach it to an identity, you have the following options: + **Using the Amazon SES API** – Create a policy in a text editor and then attach the policy to the identity by using the `PutIdentityPolicy` API described in the [Amazon Simple Email Service API Reference](https://docs.aws.amazon.com/ses/latest/APIReference/). + **Using the Amazon SES console** – Create a policy in a text editor and attach it to an identity by pasting it into the custom policy editor in the Amazon SES console. The following procedure describes this method. **To create a custom policy by using the custom policy editor** 1. Sign in to the AWS Management Console and open the Amazon SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the navigation pane, under **Configuration**, choose **Identities**. 1. In the **Identities** container on the **Identities** screen, select the verified identity you wish to create an authorization policy for. 1. In the details screen of the verified identity you selected in the previous step, choose the **Authorization** tab. 1. In the **Authorization policies** pane, choose **Create policy** and select **Create custom policy** from the dropdown. 1. In the **Policy document** pane, type or paste the text of your policy in JSON format. You can also use the policy generator to quickly create the basic structure of a policy and then customize it here. 1. Choose **Apply Policy**. (If you ever need to modify your custom policy, just select its check box under the **Authorization** tab, choose **Edit**, and make your changes in the **Policy document** pane followed by **Save changes**). # Identity policy examples in Amazon SES Identity policy examples Identity authorization enables you to specify the fine-grained conditions under which you allow or deny API actions for an identity. **Topics** + [ ## Specifying the principal ](#identity-authorization-policy-example-delegate-user) + [ ## Restricting the action ](#sending-authorization-policy-example-restricting-action) + [ ## Using multiple statements ](#identity-authorization-policy-example-multiple-statements) ## Specifying the principal The *principal*, which is the entity to which you are granting permission, can be an AWS account, an AWS Identity and Access Management (IAM) user, or an AWS service that belongs to the same account. The following example shows a simple policy that allows AWS ID *123456789012* to control the verified identity *example.com* which is also owned by AWS account *123456789012*. ------ #### [ JSON ] **** ``` { "Id":"SampleAuthorizationPolicy", "Version":"2012-10-17", "Statement":[ { "Sid":"AuthorizeMarketer", "Effect":"Allow", "Resource":"arn:aws:ses:us-east-1:123456789012:identity/example.com", "Principal":{ "AWS":[ "123456789012" ] }, "Action":[ "ses:DeleteEmailIdentity", "ses:PutEmailIdentityDkimSigningAttributes" ] } ] } ``` ------ The following example policy grants permission to two users to control the verified identity *example.com*. Users are specified by their Amazon Resource Name (ARN). ------ #### [ JSON ] **** ``` { "Id":"ExampleAuthorizationPolicy", "Version":"2012-10-17", "Statement":[ { "Sid":"AuthorizeIAMUser", "Effect":"Allow", "Resource":"arn:aws:ses:us-east-1:123456789012:identity/example.com", "Principal":{ "AWS":[ "arn:aws:iam::123456789012:user/John", "arn:aws:iam::123456789012:user/Jane" ] }, "Action":[ "ses:DeleteEmailIdentity", "ses:PutEmailIdentityDkimSigningAttributes" ] } ] } ``` ------ ## Restricting the action There are multiple actions that can be specified in an identity authorization policy depending on the level of control you want to authorize: ``` 1. "BatchGetMetricData", 2. "ListRecommendations", 3. "CreateDeliverabilityTestReport", 4. "CreateEmailIdentityPolicy", 5. "DeleteEmailIdentity", 6. "DeleteEmailIdentityPolicy", 7. "GetDomainStatisticsReport", 8. "GetEmailIdentity", 9. "GetEmailIdentityPolicies", 10. "PutEmailIdentityConfigurationSetAttributes", 11. "PutEmailIdentityDkimAttributes", 12. "PutEmailIdentityDkimSigningAttributes", 13. "PutEmailIdentityFeedbackAttributes", 14. "PutEmailIdentityMailFromAttributes", 15. "TagResource", 16. "UntagResource", 17. "UpdateEmailIdentityPolicy" ``` Identity authorization policies also enable you to restrict the principal to just one of those actions. ------ #### [ JSON ] **** ``` { "Id": "ExamplePolicy", "Version":"2012-10-17", "Statement": [ { "Sid": "ControlAction", "Effect": "Allow", "Resource": "arn:aws:ses:us-east-1:123456789012:identity/example.com", "Principal": { "AWS": [ "123456789012" ] }, "Action": [ "ses:PutEmailIdentityMailFromAttributes" ] } ] } ``` ------ ## Using multiple statements Your identity authorization policy can include multiple statements. The following example policy has two statements. The first statement denies two users to access `getemailidentity` from *sender@example.com* within the same account `123456789012`. The second statement denies `UpdateEmailIdentityPolicy` for the principal, *Jack*, within the same account `123456789012`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Sid":"DenyGet", "Effect":"Deny", "Resource":"arn:aws:ses:us-east-1:123456789012:identity/sender@example.com", "Principal":{ "AWS":[ "arn:aws:iam::123456789012:user/John", "arn:aws:iam::123456789012:user/Jane" ] }, "Action":[ "ses:GetEmailIdentity" ] }, { "Sid":"DenyUpdate", "Effect":"Deny", "Resource":"arn:aws:ses:us-east-1:123456789012:identity/sender@example.com", "Principal":{ "AWS":"arn:aws:iam::123456789012:user/Jack" }, "Action":[ "ses:UpdateEmailIdentityPolicy" ] } ] } ``` ------ # Managing your identity authorization policies in Amazon SES Managing your policies In addition to creating and attaching policies to identities, you can edit, remove, list, and retrieve an identity's policies as described in the following sections. ## Managing policies using the Amazon SES console Managing policies using the console Managing Amazon SES polices entails viewing, editing, or deleting a policy attached to an identity by using the Amazon SES console. **To manage policies using the Amazon SES console** 1. Sign in to the AWS Management Console and open the Amazon SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the left navigation pane, choose **Verified identities**. 1. In the list of identities, choose the identity you want to manage. 1. On the identity's detail page, navigate to the **Authorization** tab. Here you’ll find a list of all the policies attached to this identity. 1. Select the policy you want to manage by choosing its checkbox. 1. Depending on the desired management task, choose the respective button as follows: 1. To view the policy, choose **View policy**. If you need a copy of it, choose the **Copy** button and it will be copied to your clipboard. 1. To edit the policy, choose **Edit**. In the **Policy document** pane, edit the policy, and then choose **Save changes**. **Note** To revoke permissions, you can either edit the policy or remove it. 1. To remove the policy, choose **Delete**. **Important** Removing a policy is permanent. We recommend that you back up the policy by copying and pasting it into a text file before you remove it. ## Managing policies using the Amazon SES API Managing policies using the API Managing Amazon SES polices entails viewing, editing, or deleting a policy attached to an identity by using the Amazon SES API. **To list and view policies using the Amazon SES API** + You can list the policies that are attached to an identity by using the [ListIdentityPolicies API operation](https://docs.aws.amazon.com/ses/latest/APIReference/API_ListIdentityPolicies.html). You can also retrieve the policies themselves by using the [GetIdentityPolicies API operation](https://docs.aws.amazon.com/ses/latest/APIReference/API_GetIdentityPolicies.html). **To edit a policy using the Amazon SES API** + You can edit a policy that's attached to an identity by using the [PutIdentityPolicy API operation](https://docs.aws.amazon.com/ses/latest/APIReference/API_PutIdentityPolicy.html). **To delete a policy using the Amazon SES API** + You can delete a policy that's attached to an identity by using the [DeleteIdentityPolicy API operation](https://docs.aws.amazon.com/ses/latest/APIReference/API_DeleteIdentityPolicy.html). # Using sending authorization with Amazon SES Using sending authorization You can configure Amazon SES to authorize other users to send emails from the identities that you own (domains or email addresses) using their own Amazon SES accounts. With the *sending authorization* feature, you can maintain control over your identities so that you can change or revoke permissions at any time. For example, if you're a business owner, you can use sending authorization to enable a third party (such as an email marketing company) to send email from a domain you own. This chapter covers the specifics of sending authorization which replaces the legacy cross-account notifications feature. You should first understand the basics of identity based authorization using authorization policies as explained in [Using identity authorization in Amazon SES](identity-authorization-policies.md) which covers important topics such as the anatomy of an authorization policy and how to manage your polices. ## Cross-account notifications legacy support Cross-account notifications legacy support Feedback notifications for bounces, complaints, and deliveries associated with email sent from a delegate sender that's been authorized by an identity owner to send from one of his verified identities, have traditionally been configured using cross-account notifications where the delegate sender would associate a topic with an identity they didn't own (that’s the cross-account). However, cross-account notifications have been replaced by using configuration sets and verified identities in association with delegate sending where the delegate sender has been authorized by the identity owner to use one of their verified identities to send email from. This new method allows the flexibility to configure bounce, complaint, delivery, and other event notifications by the following two constructs depending if you're the delegate sender or the owner of the verified identity: + **Configuration sets** – The delegate sender can set up event publishing in his own configuration set that he can specify when sending email from a verified identity he doesn't own, but has been authorized to send from by the identity owner through an authorization policy. Event publishing allows bounce, complaint, delivery, and other event notifications to be published to Amazon CloudWatch, Amazon Data Firehose, Amazon Pinpoint, and Amazon SNS. See [Create event destinations](event-destinations-manage.md). + **Verified identities** – Besides having the identity owner authorize the delegate sender to use one of his verified identities to send email from, he can also, at the request of the delegate sender, configure feedback notifications on the shared identity to use SNS topics owned by the delegate sender. Only the delegate sender will get these notifications because they own the SNS topic. See Step 14 for how to [configure an "SNS topic you don't own"](sending-authorization-identity-owner-tasks-policy.md#configure-sns-topic-you-dont-own) in the authorization policy procedures. **Note** For compatibility, cross-account notifications are being supported for legacy cross-account notifications currently being used in your account. This support is limited to being able to modify and use any current cross-accounts you created in the Amazon SES classic console; however, you can no longer create *new* cross-account notifications. To create new ones in the Amazon SES new console, use the new methods of delegate sending either with configuration sets using [event publishing](event-destinations-manage.md), or with verified identities [configured with your own SNS topics](sending-authorization-identity-owner-tasks-policy.md#configure-sns-topic-you-dont-own). **Topics** + [ ## Cross-account notifications legacy support ](#sending-authorization-cross-account-sunsetting) + [ # Overview of Amazon SES sending authorization ](sending-authorization-overview.md) + [ # Identity owner tasks for Amazon SES sending authorization ](sending-authorization-identity-owner-tasks.md) + [ # Delegate sender tasks for Amazon SES sending authorization ](sending-authorization-delegate-sender-tasks.md) # Overview of Amazon SES sending authorization Overview of sending authorization This topic provides an overview of the sending authorization process and then explains how the email sending features of Amazon SES, such as sending quotas and notifications, work with sending authorization. This section uses the following terms: + **Identity** – An email address or domain that Amazon SES users use to send email. + **Identity owner** – An Amazon SES user who has verified ownership of an email address or domain by using the procedures described in [Verified identities](verify-addresses-and-domains.md). + **Delegate sender** – An AWS account, an AWS Identity and Access Management (IAM) user, or an AWS service that's been authorized through an authorization policy to send email on behalf of the identity owner. + **Sending authorization policy** – A document that you attach to an identity to specify who may send for that identity and under which conditions. + **Amazon Resource Name (ARN)** – A standardized way to uniquely identify an AWS resource across all AWS services. For sending authorization, the resource is the identity that the identity owner has authorized the delegate sender to use. An example of an ARN is *arn:aws:ses:us-east-1:123456789012:identity/example.com*. ## Sending authorization process Sending authorization is based on sending authorization policies. If you want to enable a delegate sender to send on your behalf, you create a sending authorization policy and associate the policy to your identity by using the Amazon SES console or the Amazon SES API. When the delegate sender attempts to send an email through Amazon SES on your behalf, the delegate sender passes the ARN of your identity in the request or in the header of the email. When Amazon SES receives the request to send the email, it checks your identity's policy (if present) to determine if you have authorized the delegate sender to send on the identity's behalf. If the delegate sender is authorized, Amazon SES accepts the email; otherwise, Amazon SES returns an error message. The following diagram shows the high-level relationship between sending authorization concepts: ![\[Sending authorization overview\]](http://docs.aws.amazon.com/ses/latest/dg/images/sending_authorization_overview.png) The sending authorization process consists of the following steps: 1. The identity owner selects a verified identity for the delegate sender to use. (If you haven't verified an identity, see [Verified identities](verify-addresses-and-domains.md).) **Note** The verified identity you choose for your delegate sender cannot have a [default configuration set](managing-configuration-sets.md#default-config-sets) assigned to it. 1. The delegate sender lets the identity owner know which AWS account ID or IAM user ARN they want to use for sending. 1. If the identity owner agrees to allow the delegate sender to send from one of the owner's accounts, the owner creates a sending authorization policy and attaches the policy to the chosen identity by using the Amazon SES console or the Amazon SES API. 1. The identity owner gives the delegate sender the ARN of the authorized identity so that the delegate sender can provide the ARN to Amazon SES at the time of email sending. 1. The delegate sender can set up bounce and complaint notifications through [event publishing](monitor-using-event-publishing.md) enabled in a configuration set specified during delegate sending. The identity owner can also set up email feedback notifications for bounce and complaint events to be sent to the delegate sender's Amazon SNS topics. **Note** If the identity owner disables sending event notifications, the delegate sender must set up event publishing to publish bounce and complaint events to an Amazon SNS topic or a Firehose stream. The sender must also apply the configuration set that contains the event publishing rule to each email they send. If neither the identity owner nor the delegate sender sets up a method of sending notifications for bounce and complaint events, then Amazon SES automatically sends event notifications by email to the address in the Return-Path field of the email (or the address in the Source field, if you didn't specify a Return-Path address), even if the identity owner disabled email feedback forwarding. 1. The delegate sender attempts to send an email through Amazon SES on behalf of the identity owner by passing the ARN of the identity owner's identity in the request or in the header of the email. The delegate sender can send the email by using either the Amazon SES SMTP interface or the Amazon SES API. Upon receiving the request, Amazon SES examines any policies that are attached to the identity, and accepts the email if the delegate sender is authorized to use the specified "From" address and "Return Path" address; otherwise, Amazon SES returns an error and does not accept the message. **Important** The AWS account of the delegate sender has to be removed from the sandbox before it can be used to send email to non-verified addresses. 1. If the identity owner needs to de-authorize the delegate sender, the identity owner edits the sending authorization policy or deletes the policy entirely. The identity owner can perform either action by using the Amazon SES console or the Amazon SES API. For more information about how the identity owner or delegate sender can perform those tasks, see [Identity owner tasks](sending-authorization-identity-owner-tasks.md) or [Delegate sender tasks](sending-authorization-delegate-sender-tasks.md), respectively. ## Attribution of email sending features It's important to understand the role of the delegate sender and the identity owner with respect to Amazon SES email sending features such as daily sending quota, bounces and complaints, DKIM signing, feedback forwarding, and so on. The attribution is the following: + **Sending quotas** – Email sent from the identity owner's identities count against the delegate sender's quotas. + **Bounces and complaints** – Bounce and complaint events are recorded against the delegate sender's Amazon SES account, and can therefore impact the delegate sender's reputation. + **DKIM signing** – If the identity owner has enabled Easy DKIM signing for an identity, all email sent from that identity will be DKIM-signed, including email sent by the delegate sender. Only the identity owner can control whether the emails are DKIM-signed. + **Notifications** – Both the identity owner and the delegate sender can set up notifications for bounces and complaints. The email identity owner can also enable email feedback forwarding. For information about setting up notifications, see [Monitoring your Amazon SES sending activity](monitor-sending-activity.md). + **Verification** – Identity owners are responsible for following the procedure in [Verified identities](verify-addresses-and-domains.md) to verify that they own the email addresses and domains that they're authorizing delegate senders to use. Delegate senders don't need to verify any email addresses or domains specifically for sending authorization. **Important** The AWS account of the delegate sender has to be removed from the sandbox before it can be used to send email to non-verified addresses. + **AWS Regions** – The delegate sender must send the emails from the AWS Region in which the identity owner's identity is verified. The sending authorization policy that gives permission to the delegate sender must be attached to the identity in that Region. + **Billing** – All messages that are sent from the delegate sender's account, including emails that the delegate sender sends using the identity owner's addresses, are billed to the delegate sender. # Identity owner tasks for Amazon SES sending authorization Identity owner tasks This section describes the steps that identity owners must take when configuring sending authorization. **Topics** + [ # Verifying an identity for Amazon SES sending authorization ](sending-authorization-identity-owner-tasks-verification.md) + [ # Setting up identity owner notifications for Amazon SES sending authorization ](sending-authorization-identity-owner-tasks-notifications.md) + [ # Getting information from the delegate sender for Amazon SES sending authorization ](sending-authorization-identity-owner-tasks-information.md) + [ # Creating a sending authorization policy in Amazon SES ](sending-authorization-identity-owner-tasks-policy.md) + [ # Sending policy examples ](sending-authorization-policy-examples.md) + [ # Providing the delegate sender with the identity information for Amazon SES sending authorization ](sending-authorization-identity-owner-tasks-identity.md) # Verifying an identity for Amazon SES sending authorization Verifying an identity The first step in configuring sending authorization is to prove that you own the email address or domain that the delegate sender will use to send email. The verification procedure is described in [Verified identities](verify-addresses-and-domains.md). You can confirm that an email address or domain is verified by checking its status in the Verified Identities section of the [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/) or by using the `GetIdentityVerificationAttributes` API operation. Before you or the delegate sender can send email to non-verified email addresses, you have to submit a request to have your account removed from the Amazon SES sandbox. For more information, see [Request production access (Moving out of the Amazon SES sandbox)](request-production-access.md). **Important** The AWS account of the delegate sender must be removed from the sandbox before it can be used to send email to or from non-verified addresses. If your account is in sandbox, you cannot send to email addresses that are not verified in your account, even if those domains or email addresses have been verified in the identity account # Setting up identity owner notifications for Amazon SES sending authorization Setting up notifications If you authorize a delegate sender to send email on your behalf, Amazon SES counts all bounces or complaints that those emails generate toward the delegate sender's bounce and complaint limits, rather than your own. However, if your IP address appears on third-party anti-spam, DNS-based Blackhole Lists (DNSBLs) as a result of messages sent by a delegate sender, the reputation of your identities may be damaged. For this reason, if you're an identity owner, you should set up email feedback forwarding for all your identities, including those that you've authorized for delegate sending. For more information, see [Receiving Amazon SES notifications through email](monitor-sending-activity-using-notifications-email.md). Delegate senders can and should set up their own bounce and complaint notifications for the identities that you have authorized them to use. They can set up [event publishing](monitor-using-event-publishing.md) to to publish bounce and complaint events to an Amazon SNS topic or a Firehose stream. If neither the identity owner nor the delegate sender sets up a method of sending notifications for bounce and complaint events, or if the sender doesn't apply the configuration set that uses the event publishing rule, then Amazon SES automatically sends event notifications by email to the address in the Return-Path field of the email (or the address in the Source field, if you didn't specify a Return-Path address), even if you disabled email feedback forwarding. This process is illustrated in the following image. ![\[Flowchart showing notification paths for bounce/complaint events based on various settings.\]](http://docs.aws.amazon.com/ses/latest/dg/images/feedback_forwarding.png) # Getting information from the delegate sender for Amazon SES sending authorization Getting information from the delegate sender Your sending authorization policy must specify at least one *principal*, which is the entity of your delegate sender that you're granting access to so they can send on behalf of one of your verified identities. For Amazon SES sending authorization policies, the principal can be either your delegate sender's AWS account or AWS Identity and Access Management (IAM) user ARN, or an AWS service. An easy way to think about this is that the *principal* (delegate sender) is the grantee, and you (identity owner) are the grantor in the authorization policy where you are granting them the *Allow* permission to send any combination of email, raw email, templated email, or bulk templated email from the *resource* (verified identity) that you own. If you want the finest grain control, ask the delegate sender to set up an IAM user so that only one delegate sender can send for you rather than any user in the delegate sender's AWS account. The delegate sender can find information about setting up an IAM user in [Creating an IAM user in Your AWS Account](https://docs.aws.amazon.com/IAM/latest/UserGuide/Using_SettingUpUser.html) in the *IAM User Guide*. Ask your delegate sender for the AWS account ID or the IAM user's Amazon Resource Name (ARN) so that you can include it in your sending authorization policy. You can refer your delegate sender to the instructions for finding this information in [Providing information to the identity owner](sending-authorization-delegate-sender-tasks-information.md). If the delegate sender is an AWS service, see the documentation for that service to determine the service name. The following example policy illustrates the basic elements of what is needed in a policy created by the identity owner to authorize the delegate sender to send from the identity owner's resource. The identity owner would go into the Verified identities workflow, and under Authorization, use the Policy generator to create, in its simplest form, the following basic policy allowing the delegate sender to send on behalf of a resource owned by the identity owner: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowSESSendEmail", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:root" }, "Action": [ "ses:SendEmail", "ses:SendRawEmail" ], "Resource": [ "arn:aws:ses:us-east-1:444455556666:identity/bob@example.com" ], "Condition": {} } ] } ``` ------ For the policy above, the following legend explains the key elements and who owns them: + **Principal** – this field is populated with the delegate sender's IAM user ARN. + **Action** – this field is populated with two SES actions (`SendEmail` & `SendRawEmail`) that the identity owner is allowing the delegate sender to perform from the identity owner's resource. + **Resource** – this field is populated with the identity owner's verified resource that they are authorizing the delegate sender to send from. # Creating a sending authorization policy in Amazon SES Creating a sending authorization policy Similar to creating any authorization policy in Amazon SES, as explained in [Creating an identity authorization policy](identity-authorization-policies-creating.md), to authorize a delegate sender to send emails using an email address or domain (an *identity*) that you own, you create the policy with SES sending API actions specified, and then attach that policy to the identity. For a list of API actions that can be specified in a sending authorization policy, see the *Action* row in the [Statements specific to the policy](policy-anatomy.md#identity-authorization-policy-statements) table. You can create a sending authorization policy by either using the policy generator or by creating a custom policy. Procedures specific to creating a sending authorization policy are provided for either method. **Note** Sending authorization policies that you attach to email address identities take precedence over policies that you attach to their corresponding domain identities. For example, if you create a policy for *example.com* that disallows a delegate sender, and you create a policy for *sender@example.com* that allows the delegate sender, then the delegate sender can send email from *sender@example.com*, but not from any other address on the *example.com* domain. If you create a policy for *example.com* that allows a delegate sender, and you create a policy for *sender@example.com* that disallows the delegate sender, then the delegate sender can send email from any address on the *example.com* domain, except for *sender@example.com*. If you're unfamiliar with the structure of SES authorization policies, see [Policy anatomy](policy-anatomy.md). If the identity you're authorizing is duplicated in a secondary region as part of the [Global endpoints](global-endpoints.md) feature, you'll need to create sending authorization policies on the identity in both the primary and secondary regions so that the delegate sender has permission to use this identity for sending in both regions. ## Creating a sending authorization policy by using the policy generator Using the policy generator for sending authorization You can use the policy generator to create a sending authorization policy by following these steps. **To create a sending authorization policy by using the policy generator** 1. Sign in to the AWS Management Console and open the Amazon SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the navigation pane, under **Configuration**, choose **Identities**. 1. In the **Identities** container on the **Verified identities** screen, select the verified identity you wish to authorize for the delegate sender to send on your behalf. 1. Choose the verified identity's **Authorization** tab. 1. In the **Authorization policies** pane, choose **Create policy** and select **Use policy generator** from the dropdown. 1. In the **Create statement** pane, choose **Allow** in the **Effect** field. (If you want to create a policy to restrict your delegate sender, choose **Deny** instead.) 1. In the **Principals** field, enter the *AWS account ID* or *IAM user ARN* that your delegate sender shared with you to authorize them to send email on behalf of your account for this identity, then choose **Add**. (If you wish to authorize more than one delegate sender, repeat this step for each one.) 1. In the **Actions** field, select the check box for each send type you would like to authorize for your delegate sender. 1. (Optional) Expand **Specify conditions** if you wish to add a qualifying statement to the delegate sender permission. 1. Select an operator from the **Operator** dropdown. 1. Select a type from the **Key** dropdown. 1. Respective to the key type you selected, enter its value in the **Value** field. (If you wish to add more conditions, choose **Add new condition** and repeat this step for each additional one.) 1. Choose **Save statement**. 1. (Optional) Expand **Create another statement** if you wish to add more statements to your policy and repeat steps 6 - 10. 1. Choose **Next** and on the **Customize policy** screen, the **Edit policy details** container has fields where you can change or customize the policy’s **Name** and the **Policy document** itself. 1. Choose **Next** and on the **Review and apply** screen, the **Overview** container will show the verified identity you’re authorizing for your delegate sender as well as the name of this policy. In the **Policy document** pane will be the actual policy you just wrote along with any conditions you added - review the policy and if it looks correct, choose **Apply policy**. (If you need to change or correct something, choose **Previous** and work in the **Edit policy details** container.) The policy you just created will allow your delegate sender to send on your behalf. 1. (Optional) If your delegate sender also wants to use an SNS topic that they own, to receive feedback notifications when they receive bounces or complaints, or when emails are delivered, you’ll need to configure their SNS topic in this verified identity. (Your delegate sender will need to share with you their SNS topic ARN.) Select the **Notifications** tab and select **Edit** in the **Feedback notifications** container: 1. On the **Configure SNS topics** pane, in any of the feedback fields, (Bounce, Complaint, or Delivery), select **SNS topic you don’t own** and enter the **SNS topic ARN** owned and shared with you by your delegate sender. (Only your delegate sender will get these notifications because they own the SNS topic - you, as the identity owner, will not.) 1. (Optional) If you want your topic notification to include the headers from the original email, check the **Include original email headers** box directly underneath the SNS topic name of each feedback type. This option is only available if you've assigned an Amazon SNS topic to the associated notification type. For information about the contents of the original email headers, see the `mail` object in [Notification contents](notification-contents.md). 1. Choose **Save changes**. The changes you made to your notification settings might take a few minutes to take effect. 1. (Optional) Since your delegate sender will be getting Amazon SNS topic notifications for bounces and complaints, you can disable email notifications entirely if you don’t want to receive feedback for this identity’s sends. To disable email feedback for bounces and complaints, under the **Notifications** tab, in the **Email Feedback Forwarding** container, choose **Edit**, uncheck the **Enabled** box, and choose **Save changes**. Delivery status notifications will now only be sent to the SNS topics owned by your delegate sender. ## Creating a custom sending authorization policy Creating a custom policy for sending authorization If you want to create a custom sending authorization policy and attach it to an identity, you have the following options: + **Using the Amazon SES API** – Create a policy in a text editor and then attach the policy to the identity by using the `PutIdentityPolicy` API described in the [Amazon Simple Email Service API Reference](https://docs.aws.amazon.com/ses/latest/APIReference/). + **Using the Amazon SES console** – Create a policy in a text editor and attach it to an identity by pasting it into the custom policy editor in the Amazon SES console. The following procedure describes this method. **To create a custom sending authorization policy by using the custom policy editor** 1. Sign in to the AWS Management Console and open the Amazon SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the navigation pane, under **Configuration**, choose **Identities**. 1. In the **Identities** container on the **Verified identities** screen, select the verified identity you wish to authorize for the delegate sender to send on your behalf. 1. In the details screen of the verified identity you selected in the previous step, choose the **Authorization** tab. 1. In the **Authorization policies** pane, choose **Create policy** and select **Create custom policy** from the dropdown. 1. In the **Policy document** pane, type or paste the text of your policy in JSON format. You can also use the policy generator to quickly create the basic structure of a policy and then customize it here. 1. Choose **Apply Policy**. (If you ever need to modify your custom policy, just select its check box under the **Authorization** tab, choose **Edit**, and make your changes in the **Policy document** pane followed by **Save changes**). 1. (Optional) If your delegate sender also wants to use an SNS topic that they own, to receive feedback notifications when they receive bounces or complaints, or when emails are delivered, you’ll need to configure their SNS topic in this verified identity. (Your delegate sender will need to share with you their SNS topic ARN.) Select the **Notifications** tab and select **Edit** in the **Feedback notifications** container: 1. On the **Configure SNS topics** pane, in any of the feedback fields, (Bounce, Complaint, or Delivery), select **SNS topic you don’t own** and enter the **SNS topic ARN** owned and shared with you by your delegate sender. (Only your delegate sender will get these notifications because they own the SNS topic - you, as the identity owner, will not.) 1. (Optional) If you want your topic notification to include the headers from the original email, check the **Include original email headers** box directly underneath the SNS topic name of each feedback type. This option is only available if you've assigned an Amazon SNS topic to the associated notification type. For information about the contents of the original email headers, see the `mail` object in [Notification contents](notification-contents.md). 1. Choose **Save changes**. The changes you made to your notification settings might take a few minutes to take effect. 1. (Optional) Since your delegate sender will be getting Amazon SNS topic notifications for bounces and complaints, you can disable email notifications entirely if you don’t want to receive feedback for this identity’s sends. To disable email feedback for bounces and complaints, under the **Notifications** tab, in the **Email Feedback Forwarding** container, choose **Edit**, uncheck the **Enabled** box, and choose **Save changes**. Delivery status notifications will now only be sent to the SNS topics owned by your delegate sender. # Sending policy examples Sending policy examples Sending authorization enables you to specify the fine-grained conditions under which you allow delegate senders to send on your behalf. **Topics** + [ ## Conditions specific to sending authorization ](#sending-authorization-policy-conditions) + [ ## Specifying the delegate sender ](#sending-authorization-policy-example-sender) + [ ## Restricting the "From" address ](#sending-authorization-policy-example-from) + [ ## Restricting the time at which the delegate can send email ](#sending-authorization-policy-example-time) + [ ## Restricting the email sending action ](#sending-authorization-policy-example-action) + [ ## Restricting the display name of the email sender ](#sending-authorization-policy-example-display-name) + [ ## Using multiple statements ](#sending-authorization-policy-example-multiple-statements) ## Conditions specific to sending authorization A *condition* is any restriction about the permission in the statement. The part of the statement that specifies the conditions can be the most detailed of all the parts. A *key* is the specific characteristic that's the basis for access restriction, such as the date and time of the request. You use both conditions and keys together to express the restriction. For example, if you want to restrict the delegate sender from making requests to Amazon SES on your behalf after July 30, 2019, you use the condition called `DateLessThan`. You use the key called `aws:CurrentTime` and set it to the value `2019-07-30T00:00:00Z`. You can use any of the AWS-wide keys listed at [Available Keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/AccessPolicyLanguage_ElementDescriptions.html#AvailableKeys) in the *IAM User Guide*, or you can use one of the following keys specific to SES that are useful in sending authorization policies: **** | Condition key | Description | | --- | --- | | `ses:Recipients` | Restricts the recipient addresses, which include the To:, "CC", and "BCC" addresses. | | `ses:FromAddress` | Restricts the "From" address. | | `ses:FromDisplayName` | Restricts the contents of the string that is used as the "From" display name (sometimes called "friendly from"). For example, the display name of "John Doe " is John Doe. | | `ses:FeedbackAddress` | Restricts the "Return Path" address, which is the address where bounce and complaints can be sent to you by email feedback forwarding. For information about email feedback forwarding, see [Receiving Amazon SES notifications through email](monitor-sending-activity-using-notifications-email.md). | You can use the `StringEquals` and `StringLike` conditions with Amazon SES keys. These conditions are for case-sensitive string matching. For `StringLike`, the values can include a multi-character match wildcard (\$1) or a single-character match wildcard (?) anywhere in the string. For example, the following condition specifies that the delegate sender can only send from a "From" address that starts with *invoicing* and ends with *@example.com*: ``` 1. "Condition": { 2. "StringLike": { 3. "ses:FromAddress": "invoicing*@example.com" 4. } 5. } ``` You can also use the `StringNotLike` condition to prevent delegate senders from sending email from certain email addresses. For example, you can disallow sending from *admin@example.com*, and also similar addresses such as *"admin"@example.com*, *admin\$11@example.com*, or *sender@admin.example.com*, by including the following condition in your policy statement: ``` 1. "Condition": { 2. "StringNotLike": { 3. "ses:FromAddress": "*admin*example.com" 4. } 5. } ``` For more information about how to specify conditions, see [IAM JSON Policy Elements: Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) in the *IAM User Guide*. ## Specifying the delegate sender The *principal*, which is the entity to which you are granting permission, can be an AWS account, an AWS Identity and Access Management (IAM) user, or an AWS service. The following example shows a simple policy that allows AWS ID *123456789012* to send email from the verified identity *example.com* (which is owned by AWS account *888888888888*). The `Condition` statement in this policy only allows the delegate (that is, AWS ID *123456789012*) to send email from the address *marketing\$1.\$1@example.com*, where *\$1* is any string that the sender wants to add after *marketing\$1.*. ------ #### [ JSON ] **** ``` { "Id":"SampleAuthorizationPolicy", "Version":"2012-10-17", "Statement":[ { "Sid":"AuthorizeMarketer", "Effect":"Allow", "Resource":"arn:aws:ses:us-east-1:888888888888:identity/example.com", "Principal":{ "AWS":[ "123456789012" ] }, "Action":[ "ses:SendEmail", "ses:SendRawEmail" ], "Condition":{ "StringLike":{ "ses:FromAddress":"marketing+.*@example.com" } } } ] } ``` ------ The following example policy grants permission to two IAM users to send from identity *example.com*. IAM users are specified by their Amazon Resource Name (ARN). ------ #### [ JSON ] **** ``` { "Id":"ExampleAuthorizationPolicy", "Version":"2012-10-17", "Statement":[ { "Sid":"AuthorizeIAMUser", "Effect":"Allow", "Resource":"arn:aws:ses:us-east-1:888888888888:identity/example.com", "Principal":{ "AWS":[ "arn:aws:iam::111122223333:user/John", "arn:aws:iam::444455556666:user/Jane" ] }, "Action":[ "ses:SendEmail", "ses:SendRawEmail" ] } ] } ``` ------ The following example policy grants permission to Amazon Cognito to send from identity *example.com*. ------ #### [ JSON ] **** ``` { "Id":"ExampleAuthorizationPolicy", "Version":"2012-10-17", "Statement":[ { "Sid":"AuthorizeService", "Effect":"Allow", "Resource":"arn:aws:ses:us-east-1:888888888888:identity/example.com", "Principal":{ "Service":[ "cognito-idp.amazonaws.com" ] }, "Action":[ "ses:SendEmail", "ses:SendRawEmail" ], "Condition": { "StringEquals": { "aws:SourceAccount": "888888888888", "aws:SourceArn": "arn:aws:cognito-idp:us-east-1:888888888888:userpool/your-user-pool-id-goes-here" } } } ] } ``` ------ The following example policy grants permission to all accounts within an AWS Organization to send from identity example.com. The AWS Organization is specified using the [PrincipalOrgID](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalorgid) global condition key. ------ #### [ JSON ] **** ``` { "Id":"ExampleAuthorizationPolicy", "Version":"2012-10-17", "Statement":[ { "Sid":"AuthorizeOrg", "Effect":"Allow", "Resource":"arn:aws:ses:us-east-1:888888888888:identity/example.com", "Principal":"*", "Action":[ "ses:SendEmail", "ses:SendRawEmail" ], "Condition":{ "StringEquals":{ "aws:PrincipalOrgID":"o-xxxxxxxxxxx" } } } ] } ``` ------ ## Restricting the "From" address If you use a verified domain, you may want to create a policy that allows only the delegate sender to send from a specified email address. To restrict the "From" address, you set a condition on the key called *ses:FromAddress*. The following policy enables AWS account ID *123456789012* to send from the identity *example.com*, but only from the email address *sender@example.com*. ------ #### [ JSON ] **** ``` { "Id":"ExamplePolicy", "Version":"2012-10-17", "Statement":[ { "Sid":"AuthorizeFromAddress", "Effect":"Allow", "Resource":"arn:aws:ses:us-east-1:888888888888:identity/example.com", "Principal":{ "AWS":[ "123456789012" ] }, "Action":[ "ses:SendEmail", "ses:SendRawEmail" ], "Condition":{ "StringEquals":{ "ses:FromAddress":"sender@example.com" } } } ] } ``` ------ ## Restricting the time at which the delegate can send email You can also configure your sender authorization policy so that a delegate sender can send email only at a certain time of day, or within a certain date range. For example, if you plan to send an email campaign during the month of September 2021, you can use the following policy to restrict the delegate's ability to send email to that month only. ------ #### [ JSON ] **** ``` { "Id":"ExamplePolicy", "Version":"2012-10-17", "Statement":[ { "Sid":"ControlTimePeriod", "Effect":"Allow", "Resource":"arn:aws:ses:us-east-1:888888888888:identity/example.com", "Principal":{ "AWS":[ "123456789012" ] }, "Action":[ "ses:SendEmail", "ses:SendRawEmail" ], "Condition":{ "DateGreaterThan":{ "aws:CurrentTime":"2021-08-31T12:00Z" }, "DateLessThan":{ "aws:CurrentTime":"2021-10-01T12:00Z" } } } ] } ``` ------ ## Restricting the email sending action There are two actions that senders can use to send an email with Amazon SES: `SendEmail` and `SendRawEmail`, depending on how much control the sender wants over the format of the email. Sending authorization policies enable you to restrict the delegate sender to one of those two actions. However, many identity owners leave the details of the email sending calls up to the delegate sender by enabling both actions in their policies. **Note** If you want to enable the delegate sender to access Amazon SES through the SMTP interface, you must choose `SendRawEmail` at a minimum. If your use case is such that you want to restrict the action, you can do so by including only one of the actions in your sending authorization policy. The following example shows you how to restrict the action to `SendRawEmail`. ------ #### [ JSON ] **** ``` { "Id":"ExamplePolicy", "Version":"2012-10-17", "Statement":[ { "Sid":"ControlAction", "Effect":"Allow", "Resource":"arn:aws:ses:us-east-1:888888888888:identity/example.com", "Principal":{ "AWS":[ "123456789012" ] }, "Action":[ "ses:SendRawEmail" ] } ] } ``` ------ ## Restricting the display name of the email sender Some email clients display the "friendly" name of the email sender (if the email header provides it), rather than the actual "From" address. For example, the display name of "John Doe " is John Doe. For instance, you might send emails from *user@example.com*, but you prefer that recipients see that the email is from *Marketing* rather than from *user@example.com*. The following policy enables AWS account ID 123456789012 to send from identity *example.com*, but only if the display name of the "From" address includes *Marketing*. ------ #### [ JSON ] **** ``` { "Id":"ExamplePolicy", "Version":"2012-10-17", "Statement":[ { "Sid":"AuthorizeFromAddress", "Effect":"Allow", "Resource":"arn:aws:ses:us-east-1:888888888888:identity/example.com", "Principal":{ "AWS":[ "123456789012" ] }, "Action":[ "ses:SendEmail", "ses:SendRawEmail" ], "Condition":{ "StringLike":{ "ses:FromDisplayName":"Marketing" } } } ] } ``` ------ ## Using multiple statements Your sending authorization policy can include multiple statements. The following example policy has two statements. The first statement authorizes two AWS accounts to send from *sender@example.com* as long as the "From" address and the feedback address both use the domain *example.com*. The second statement authorizes an IAM user to send email from *sender@example.com* as long as the recipient's email address is under the *example.com* domain. # Providing the delegate sender with the identity information for Amazon SES sending authorization Providing the delegate sender with the identity information After you create your sending authorization policy and attach it to your identity, you can provide the delegate sender with the Amazon Resource Name (ARN) of the identity. The delegate sender will pass that ARN to Amazon SES in the email-sending operation or in the header of the email. To find your identity's ARN, follow these steps. **To find the ARN of an identity** 1. Sign in to the AWS Management Console and open the Amazon SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the navigation pane, under **Configuration**, choose **Verified identities**. 1. In the list of identities, choose the identity to which you attached the sending authorization policy. 1. In the **Summary** pane, the second column, **Amazon Resource Name (ARN)**, will contain the identity's ARN. It will look similar to *arn:aws:ses:us-east-1:123456789012:identity/user@example.com*. Copy the entire ARN and give it to your delegate sender. **Important** If the identity you're authorizing is duplicated in a secondary region as part of the [Global endpoints](global-endpoints.md) feature, replace the region parameter, such as, `us-east-1`, with an asterisk `*` as in the following example, `arn:aws:ses:*:123456789012:identity/user@example.com`. # Delegate sender tasks for Amazon SES sending authorization Delegate sender tasks As a delegate sender, you're sending emails on behalf of an identity that you don't own, but are authorized to use. Even though you're sending on the identity owner's behalf, bounces and complaints count toward the bounce and complaint metrics for your AWS account, and the number of messages you send counts toward your sending quota. You're also responsible for requesting any sending quota increases that you might need in order to send the identity owner's emails. As a delegate sender, you must complete the following tasks: + [Providing information to the identity owner](sending-authorization-delegate-sender-tasks-information.md) + [Using delegate sender notifications](sending-authorization-delegate-sender-tasks-notifications.md) + [Sending emails for the identity owner](sending-authorization-delegate-sender-tasks-email.md) # Providing information to the identity owner for Amazon SES sending authorization Providing information to the identity owner As a delegate sender, you must provide the identity owner with either your AWS account ID or your IAM user Amazon Resource Name (ARN) since you will be sending email on behalf of the identity owner. The identity owner needs your account information so they can create a policy that grants you permission to send from one of their verified identities. If you want to use your own SNS topics, you can request that your identity owner configure feedback notifications for bounces, complaints, or deliveries to be sent to one or more of your SNS topics. To do this, you’ll need to share your SNS topic ARN with your identity owner so that they can configure your SNS topic in the verified identity they're authorizing you to send from. The following procedures explain how to find your account information and SNS topic ARNs to share with your identity owner. **To find your AWS account ID** 1. Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com). 1. In the upper right-hand corner of the console, expand your name/account number, and choose **My Account** in the dropdown. 1. The Account settings page will open and display all of your account information including your AWS account ID. **To find your IAM user ARN** 1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. In the navigation pane, choose **Users**. 1. In the list of users, choose the user name. The **Summary** section displays the IAM user ARN. The ARN resembles the following example: *arn:aws:iam::123456789012:user/John*. **To find your SNS topic ARN** 1. Open the Amazon SNS console at [https://console.aws.amazon.com/sns/v3/home](https://console.aws.amazon.com/sns/v3/home). 1. In the navigation pane, choose **Topics**. 1. In the list of topics, the SNS topic ARNs are displayed in the **ARN** column. The ARN resembles the following example: *arn:aws:sns:us-east-1:444455556666:my-sns-topic*. # Using delegate sender notifications for Amazon SES sending authorization Using delegate sender notifications As a delegate sender, you're sending emails on behalf of an identity that you don't own, but are authorized to use; however, bounces and complaints still count toward *your* bounce and complaint metrics, not those of the identity owner. If the bounce or complaint rates for your account gets too high, your account is at risk of being placed under review or have its ability to send email paused. For this reason, it's important that you set up notifications and have a process in place to monitor them. You also need to have a process in place for removing addresses that have bounced or complained from your mailing lists. Therefore, as a delegate sender, you can configure Amazon SES to send notifications when bounce and complaint events occur for the emails you send on behalf of any identities that you don't own, but have been authorized to use by the identity owner. You can also set up [event publishing](monitor-using-event-publishing.md) to publish bounce and complaint notifications to Amazon SNS or Firehose. **Note** If you set up Amazon SES to send notifications by using Amazon SNS, you're charged standard Amazon SNS rates for the notifications you receive. For more information, see the [Amazon SNS pricing page](https://aws.amazon.com/sns/pricing). ## Create a new delegate sender notification Create a new delegate sender notification You can set up delegate sending notifications with either configuration sets using [event publishing](event-destinations-manage.md), or with verified identities [configured with your own SNS topics](sending-authorization-identity-owner-tasks-policy.md#configure-sns-topic-you-dont-own). Procedures are given below for setting up new delegate sending notifications using either method: + Event publishing through a configuration set + Feedback notifications to SNS topics you own **To set up event publishing through a configuration set for your delegate sending** 1. Sign in to the AWS Management Console and open the Amazon SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. Follow the procedures in [Create event destinations](event-destinations-manage.md). 1. After you've set up event publishing in your configuration set, specify the name of the configuration set when you send email as a delegate sender using the verified identity the identity owner authorized you to send from. See [Sending emails for the identity owner](sending-authorization-delegate-sender-tasks-email.md). **To set up feedback notifications to SNS topics you own for your delegate sending** 1. After you've decided which of your SNS topics you'd like to use for feedback notifications, follow the procedures [to find your SNS topic ARN](sending-authorization-delegate-sender-tasks-information.md#find-sns-topic-arn) and copy the full ARN and share it with your identity owner. 1. Ask your identity owner to configure your SNS topics for feedback notifications on the shared identity he's authorized you to send from. (Your identity owner will need to follow the procedures given for [configuring SNS topics](sending-authorization-identity-owner-tasks-policy.md#configure-sns-topic-you-dont-own) in the authorization policy procedures.) # Sending emails for the identity owner for Amazon SES sending authorization Sending emails for the identity owner As a delegate sender, you send emails the same way that other Amazon SES senders do, except that you provide the Amazon Resource Name (ARN) of the identity that the identity owner has authorized you to use. When you call Amazon SES to send the email, Amazon SES checks to see if the identity that you specified has a policy that authorizes you to send for it. There are different ways that you can specify the identity's ARN when you send an email. The method that you use depends on whether you send the email by using the Amazon SES API operations or the Amazon SES SMTP interface. **Important** To successfully send an email, you have to connect to the Amazon SES endpoint in the AWS Region that the identity owner verified the identity in. Additionally, the AWS accounts of **both** the identity owner and the delegate sender have to be removed from the sandbox before either account can send email to non-verified addresses. For more information, see [Request production access (Moving out of the Amazon SES sandbox)](request-production-access.md). If the identity you've been authorized to use is duplicated in a secondary region as part of the [Global endpoints](global-endpoints.md) feature: The identity owner should have supplied you with an identity ARN that had the region parameter, such as, `us-east-1`, replaced with an asterisk `*` as in the following example, `arn:aws:ses:*:123456789012:identity/user@example.com`. The identity owner should have created sending authorization policies for you in both the primary and secondary regions. ## Using the Amazon SES API Using the Amazon SES API As with any Amazon SES email sender, if you access Amazon SES through the Amazon SES API (either directly through HTTPS or indirectly through an AWS SDK), you can choose between one of three email-sending actions: `SendEmail`, `SendTemplatedEmail`, and `SendRawEmail`. The [Amazon Simple Email Service API Reference](https://docs.aws.amazon.com/ses/latest/APIReference/) describes the details of these APIs, but we provide an overview of the sending authorization parameters here. ### SendRawEmail If you want to use `SendRawEmail` so that you can control the format of your emails, you can specify the delegated authorized identity in one of two ways: + **Pass optional parameters to the `SendRawEmail` API**. The required parameters are described in the following table: **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ses/latest/dg/sending-authorization-delegate-sender-tasks-email.html) + **Include X-headers in the email**. X-headers are custom headers that you can use in addition to standard email headers (such as the From, Reply-To, or Subject headers). Amazon SES recognizes three X-headers that you can use to specify sending authorization parameters: **Important** Do not include these X-headers in the DKIM signature, because they are removed by Amazon SES before sending the email. **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ses/latest/dg/sending-authorization-delegate-sender-tasks-email.html) Amazon SES removes all X-headers from the email before sending it. If you include multiple instances of an X-header, Amazon SES uses only the first instance. The following example shows an email that includes sending authorization X-headers: ``` 1. X-SES-SOURCE-ARN: arn:aws:ses:us-east-1:123456789012:identity/example.com 2. X-SES-FROM-ARN: arn:aws:ses:us-east-1:123456789012:identity/example.com 3. X-SES-RETURN-PATH-ARN: arn:aws:ses:us-east-1:123456789012:identity/example.com 4. 5. From: sender@example.com 6. To: recipient@example.com 7. Return-Path: feedback@example.com 8. Subject: subject 9. Content-Type: multipart/alternative; 10. boundary="----=_boundary" 11. 12. ------=_boundary 13. Content-Type: text/plain; charset=UTF-8 14. Content-Transfer-Encoding: 7bit 15. 16. body 17. ------=_boundary 18. Content-Type: text/html; charset=UTF-8 19. Content-Transfer-Encoding: 7bit 20. 21. body 22. ------=_boundary-- ``` ### SendEmail and SendTemplatedEmail If you use the `SendEmail` or `SendTemplatedEmail` operation, you can specify the delegated authorized identity by passing in the optional parameters below. You can't use the X-header method when you use the `SendEmail` or `SendTemplatedEmail` operation. **** | Parameter | Description | | --- | --- | | `SourceArn` | The ARN of the identity that is associated with the sending authorization policy that permits you to send for the email address specified in the `Source` parameter of either `SendEmail` or `SendTemplatedEmail`. | | `ReturnPathArn` | The ARN of the identity that is associated with the sending authorization policy that permits you to use the email address specified in the `ReturnPath` parameter of either `SendEmail` or `SendTemplatedEmail`. | The following example shows how to send an email that includes the `SourceArn` and `ReturnPathArn` attributes using either the `SendEmail` or `SendTemplatedEmail` operation and the [SDK for Python](https://aws.amazon.com/sdk-for-python). ``` import boto3 from botocore.exceptions import ClientError # Create a new SES resource and specify a region. client = boto3.client('ses',region_name="us-east-1") # Try to send the email. try: #Provide the contents of the email. response = client.send_email( Destination={ 'ToAddresses': [ 'recipient@example.com', ], }, Message={ 'Body': { 'Html': { 'Charset': 'UTF-8', 'Data': 'This email was sent with Amazon SES.', }, }, 'Subject': { 'Charset': 'UTF-8', 'Data': 'Amazon SES Test', }, }, SourceArn='arn:aws:ses:us-east-1:123456789012:identity/example.com', ReturnPathArn='arn:aws:ses:us-east-1:123456789012:identity/example.com', Source='sender@example.com', ReturnPath='feedback@example.com' ) # Display an error if something goes wrong. except ClientError as e: print(e.response['Error']['Message']) else: print("Email sent! Message ID:"), print(response['ResponseMetadata']['RequestId']) ``` ## Using the Amazon SES SMTP interface When you use the Amazon SES SMTP interface for delegate sending, you have to include the `X-SES-SOURCE-ARN`, `X-SES-FROM-ARN`, and `X-SES-RETURN-PATH-ARN` headers in your message. Pass these headers after you issue the `DATA` command in the SMTP conversation. # Sending test emails in Amazon SES with the simulator Sending test emails with the simulator We recommend using the Amazon SES console to send a test email with Amazon SES. Because the console requires you to manually enter information, you typically only use it to send test emails. After you get started with Amazon SES, you will most likely send your emails by using either the Amazon SES SMTP interface or API. However,the console is useful for monitoring your sending activity. **Topics** + [ ## Using the mailbox simulator from the console ](#send-test-email) + [ ## Using the mailbox simulator manually ](#send-email-simulator) ## Using the mailbox simulator from the console Using the mailbox simulator from the console **Important** In this tutorial, you send an email to yourself from the console so that you can check to see if you received it. For further experimentation or load testing, see [Using the mailbox simulator manually](#send-email-simulator). Emails that you send to the mailbox simulator do not count toward your sending quota or your bounce and complaint rates, nor do they affect Virtual Deliverability Manager metrics. Before you follow these steps, complete the tasks in [Setting up Amazon Simple Email Service](setting-up.md). **To send a test email message from the Amazon SES console** 1. Sign in to the AWS Management Console and open the Amazon SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the navigation pane under **Configuration** choose **Identities**. 1. From the **Identities** table, select a verified email identity (by clicking directly on the identity name as opposed to selecting its checkbox). *If you don't have a verified email identity, see [Creating an email address identity](creating-identities.md#verify-email-addresses-procedure).* 1. On the selected email identity's detail page, choose **Send test email**. 1. For **Message details**, choose the **Email Format**. The two choices are as follows: + ****Formatted****—This is the simplest option. Choose this option if you simply want to type the text of your message into the **Body** text box. When you send the email, Amazon SES puts the text into email format for you. + ****Raw****—Choose this option if you want to send a more complex message, such as a message that includes HTML or an attachment. Because of this flexibility, you need to format the message, as described in [Sending raw email using the Amazon SES API v2](send-email-raw.md), yourself, and then paste the entire formatted message, including the headers, into the **Body** text box. You can use the following example, which contains HTML, to send a test email using the **Raw** email format. Copy and paste this message in its entirety into the **Body** text box. Ensure that there is not a blank line between the `MIME-Version` header and the `Content-Type` header; a blank line between these two lines causes the email to be formatted as plain text instead of HTML. ``` 1. Subject: Amazon SES Raw Email Test 2. MIME-Version: 1.0 3. Content-Type: text/html 4. 5. 6. 7. 8.

This text should be large, because it is formatted as a header in HTML.

9.

Here is a formatted link: Amazon Simple Email Service Developer Guide.

10. 11. ``` 1. Choose the type of simulated email scenario you want to test by expanding the **Scenario** list box. 1. If you choose **Custom** and you're still in the Amazon SES sandbox, make sure that the address in the **Custom recipient** field is a verified email address. For more information, see [Creating an email address identity](creating-identities.md#verify-email-addresses-procedure). 1. Fill out the remaining fields as desired. 1. Choose **Send test email**. 1. Sign in to the email client of the address you sent the email to. You will find the message that you sent. ## Using the mailbox simulator manually Using the mailbox simulator manually Amazon SES includes a mailbox simulator that you can use to test how your application handles different email sending scenarios. The mailbox simulator is useful when, for example, you want to test an email sending application without creating fictitious email addresses, or when you want to find your system's maximum throughput without impacting your daily sending quota. ### Important considerations Consider the following features and limitations when you use the Amazon SES mailbox simulator: + You can use the mailbox simulator even if your account is in the Amazon SES sandbox. + Emails that you send to the mailbox simulator are limited by your account's maximum sending rate, but they don't affect your daily sending quota. For example, if your account is authorized to send 10,000 messages per 24-hour period, and you send 100 messages to the mailbox simulator, you can still send up to 10,000 messages to regular recipients without reaching your sending quota. + Emails that you send to the mailbox simulator don't impact your email deliverability or reputation metrics. For example, if you send a large number of messages to the bounce address of the email simulator, it doesn't display a message warning you that your bounce rate is too high on the [reputation metrics console page](reputation-dashboard-dg.md). + For billing purposes, emails that you send to the Amazon SES mailbox simulator are the same as any other email you send using Amazon SES. In other words, we bill you the same amount for messages that you send to the mailbox simulator as for those that you send to regular recipients. + The mailbox simulator supports labeling, which enables you to send emails to the same mailbox simulator address in multiple ways, or to see how your application handles Variable Envelope Return Path (VERP). For example, you can send an email to *bounce\$1label1@simulator.amazonses.com* and *bounce\$1label2@simulator.amazonses.com* to see if your application can match a bounce message with the email address that caused the bounce. + If you use the mailbox simulator to simulate multiple bounces from the same sending request, Amazon SES combines the bounce responses into a single response. ### Using the mailbox simulator To use the email simulator, find the scenario in the following table, and then send an email to the corresponding email address. **Note** When you send an email to a mailbox simulator address, you must send it through Amazon SES, by using the AWS CLI, an AWS SDK, the Amazon SES console, the Amazon SES SMTP interface, or the Amazon SES API. The mailbox simulator doesn't respond to emails that it receives from external sources. | Simulated scenario | Email address | | --- | --- | | Successful delivery—The recipient's email provider accepts your email. If you set up delivery notifications as described in [Setting up event notifications for Amazon SES](monitor-sending-activity-using-notifications.md), Amazon SES sends you a delivery notification through Amazon Simple Notification Service (Amazon SNS). | success@simulator.amazonses.com | | Bounce—The recipient's email provider rejects your email with an SMTP 550 5.1.1 ("Unknown User") response code. Amazon SES generates a bounce notification and, depending on how you set up your account, sends it to you in an email or sends a notification to an Amazon SNS topic. The mailbox simulator email address isn't placed on the Amazon SES suppression list, which would normally happen when a hard bounce occurs. The bounce response that you receive from the mailbox simulator is compliant with [RFC 3464](https://tools.ietf.org/html/rfc3464). For information about how to receive bounce feedback, see [Setting up event notifications for Amazon SES](monitor-sending-activity-using-notifications.md). | bounce@simulator.amazonses.com | | Automatic responses—The recipient's email provider accepts your email and delivers it to the recipient’s inbox. The email provider sends an automatic response, such as an "out of the office" (OOTO) message, to the address in the Return-Path header of the email, or the envelope sender ("MAIL FROM") address if the Return-Path header isn't present. The automatic response that you receive from the mailbox simulator is compliant with [RFC 3834](https://tools.ietf.org/html/rfc3834). | ooto@simulator.amazonses.com | | Complaint—The recipient's email provider accepts your email and delivers it to the recipient’s inbox. The recipient decides that your message is unsolicited and clicks "Mark as Spam" in his or her email client. Amazon SES then forwards the complaint notification to you by email or by notifying an Amazon SNS topic, depending on how you set up your account. The complaint response that you receive from the mailbox simulator is compliant with [RFC 5965](https://tools.ietf.org/html/rfc5965). For information about how to receive complaint feedback, see [Setting up event notifications for Amazon SES](monitor-sending-activity-using-notifications.md). | complaint@simulator.amazonses.com | | Recipient address on suppression list—Amazon SES generates a hard bounce as if the recipient's address is on the global suppression list. | suppressionlist@simulator.amazonses.com | ### Testing Reject events Every message that you send through Amazon SES is scanned for viruses. If you send a message that contains a virus, Amazon SES accepts the message, detects the virus, and rejects the entire message. When Amazon SES rejects the message, it stops processing the message, and doesn't attempt to deliver it to the recipient's mail server. It then generates a Reject event. The Amazon SES mailbox simulator doesn't include an address for testing Reject events. However, you can test Reject events by using a European Institute for Computer Antivirus Research (EICAR) test file. This file is an industry-standard method of testing antivirus software in a safe manner. To create an EICAR test file, paste the following text into a file: ``` X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H* ``` Save the file as `sample.txt`, attach it to an email, and then send the email to a verified address. If there are no other issues with the email, Amazon SES accepts the message, but then rejects it as it would if it contained an actual virus. **Note** Rejected emails—including those that you send by using the procedure above—count against your daily sending quota. We bill you for each message that you send, including rejected messages. To learn more about EICAR test files, see the [EICAR test file page on Wikipedia](https://en.wikipedia.org/wiki/EICAR_test_file).