# Identity owner tasks for Amazon SES sending authorization 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 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 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 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 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 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 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 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 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`.