

# Identity and access management in Amazon SES
<a name="control-user-access"></a>

You can use AWS Identity and Access Management (IAM) with Amazon Simple Email Service (Amazon SES) to specify which SES API actions an user, group, or role can perform. (In this topic we refer to these entities collectively as *user*.) You can also control which email addresses the user can use for the "From", recipient, and "Return-Path" addresses of emails.

For example, you can create an IAM policy that allows users in your organization to send email, but not perform administrative actions such as checking sending statistics. As another example, you can write a policy that allows a user to send emails through SES from your account, but only if they use a specific "From" address.

To use IAM, you define an IAM policy, which is a document that explicitly defines permissions, and attach the policy to a user. To learn how to create IAM policies, see the [IAM User Guide](https://docs.aws.amazon.com/IAM/latest/UserGuide/policies_overview.html). Other than applying the restrictions you set in your policy, there are no changes to how users interact with SES or in how SES carries out requests.

**Note**  
If your account is in the SES sandbox, its restrictions well prevent the implementation of some of these polices - see [Request production access](request-production-access.md).
You can also control access to SES by using sending authorization policies. Whereas IAM policies constrain what individual users can do, sending authorization policies constrain how individual verified identities can be used. Further, only sending authorization policies can grant cross-account access. For more information about sending authorization, see [Using sending authorization with Amazon SES](sending-authorization.md).

If you are looking for information about how to generate SES SMTP credentials for an existing user, see [Obtaining Amazon SES SMTP credentials](smtp-credentials.md).

## Creating IAM Policies for Access to SES
<a name="iam-and-ses"></a>

This section explains how you can use IAM policies specifically with SES. To learn how to create IAM policies in general, see the [IAM User Guide](https://docs.aws.amazon.com/IAM/latest/UserGuide/AccessPolicyLanguage_ElementDescriptions.html).

There are three reasons you might use IAM with SES:
+ To restrict the email-sending action.
+ To restrict the "From", recipient, and "Return-Path" addresses of the emails that the user sends.
+ To control general aspects of API usage such as the time period during which a user is permitted to call the APIs that they are authorized to use.

### Restricting the Action
<a name="iam-and-ses-restrict-action"></a>

To control which SES actions a user can perform, you use the `Action` element of an IAM policy. You can set the `Action` element to any SES API action by prefixing the API name with the lowercase string `ses:`. For example, you can set the `Action` to `ses:SendEmail`, `ses:GetSendStatistics`, or `ses:*` (for all actions).

Then, depending on the `Action`, specify the `Resource` element as follows:

**If the `Action` element only permits access to email-sending APIs (that is, `ses:SendEmail` and/or `ses:SendRawEmail`):**
+ To allow the user to send from any identity in your AWS account, set `Resource` to \$1
+ To restrict the identities that a user is allowed to send from, set `Resource` to the ARNs of the identities that you are permitting the user to use.

**If the `Action` element permits access to all APIs:**
+ If you don't want to restrict the identities that the user can send from, set `Resource` to \$1
+ If you want to restrict the identities that a user is allowed to send from, you need to create two policies (or two statements within one policy):
  + One with `Action` set to an explicit list of the permitted non-email-sending APIs and `Resource` set to \$1
  + One with `Action` set to one of the email-sending APIs (`ses:SendEmail` and/or `ses:SendRawEmail`), and `Resource` set to the ARN(s) of the identities you are permitting the user to use.

For a list of available SES actions, see the [Amazon Simple Email Service API Reference](https://docs.aws.amazon.com/ses/latest/APIReference/). If the user will be using the SMTP interface, you must allow access to `ses:SendRawEmail` at a minimum.

### Restricting Email Addresses
<a name="iam-and-ses-restrict-addresses"></a>

If you want to restrict the user to specific email addresses, you can use a `Condition` block. In the `Condition` block, you specify conditions by using condition keys as described in the [IAM User Guide](https://docs.aws.amazon.com/IAM/latest/UserGuide/AccessPolicyLanguage_ElementDescriptions.html#Condition). By using condition keys, you can control the following email addresses:

**Note**  
These email address condition keys apply only to the APIs noted in the following table.


****  

| Condition Key | Description | API | 
| --- | --- | --- | 
| `ses:Recipients` | Restricts the recipient addresses, which include the To:, "CC", and "BCC" addresses. | `SendEmail`, `SendRawEmail` | 
| `ses:FromAddress` | Restricts the "From" address. | `SendEmail`, `SendRawEmail`, `SendBounce` | 
| `ses:FromDisplayName` | Restricts the "From" address that is used as the display name.  | `SendEmail`, `SendRawEmail` | 
| `ses:FeedbackAddress` | Restricts the "Return-Path" address, which is the address where bounces 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). | `SendEmail`, `SendRawEmail` | 
| `ses:MultiRegionEndpointId` | Allows you to control what endpoint ID is used when sending email | `SendEmail`, `SendBulkEmail` | 

### Restricting by SES API version
<a name="iam-and-ses-restrict-api-version"></a>

By using the `ses:ApiVersion` key in conditions, you can restrict access to SES based on the version of the SES API.

**Note**  
The SES SMTP interface uses SES API version 2 of `ses:SendRawEmail`.

### Restricting General API Usage
<a name="iam-and-ses-restrict-API-usage"></a>

By using AWS-wide keys in conditions, you can restrict access to SES based on aspects such as the date and time that user is permitted access to APIs. 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).

## Example IAM Policies for SES
<a name="iam-and-ses-examples"></a>

This topic provides examples of policies that permit a user access to SES, but only under certain conditions.

**Topics**
+ [Allowing Full Access to All SES Actions](#iam-and-ses-examples-full-access)
+ [Allowing Access to only SES API version 2](#iam-and-ses-examples-access-specific-ses-api-version)
+ [Allowing Access to Email-Sending Actions Only](#iam-and-ses-examples-email-sending-actions)
+ [Restricting the Time Period of Sending](#iam-and-ses-examples-time-period)
+ [Restricting the Recipient Addresses](#iam-and-ses-examples-recipients)
+ [Restricting the "From" Address](#iam-and-ses-examples-from-address)
+ [Restricting the Display Name of the Email Sender](#iam-and-ses-examples-display-name)
+ [Restricting the Destination of Bounce and Complaint Feedback](#iam-and-ses-examples-feedback)

### Allowing Full Access to All SES Actions
<a name="iam-and-ses-examples-full-access"></a>

The following policy allows a user to call any SES action.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement":[
    {
      "Effect":"Allow",
      "Action":[
        "ses:*"
      ],
      "Resource":"*"
    }
  ]
}
```

------

### Allowing Access to only SES API version 2
<a name="iam-and-ses-examples-access-specific-ses-api-version"></a>

The following policy allows a user to call only the SES actions of API version 2.

------
#### [ JSON ]

****  

```
{
  		                 "Version":"2012-10-17",		 	 	 
  		                 "Statement":[
  		                     {
  		                         "Effect":"Allow",
  		                         "Action":[
  		                         "ses:*"
  		                         ],
  		                         "Resource":"*",
  		                         "Condition": {
  		                             "StringEquals" : {
  		                             "ses:ApiVersion" : "2"
  		                             }
  		                         }
  		                     }
  		                 ]
  		             }
```

------

### Allowing Access to Email-Sending Actions Only
<a name="iam-and-ses-examples-email-sending-actions"></a>

The following policy permits a user to send email using SES, but does not permit the user to perform administrative actions such as accessing SES sending statistics.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement":[
    {
      "Effect":"Allow",
      "Action":[
        "ses:SendEmail",
        "ses:SendRawEmail"
      ],
      "Resource":"*"
    }
  ]
}
```

------

### Restricting the Time Period of Sending
<a name="iam-and-ses-examples-time-period"></a>

The following policy permits a user to call SES email-sending APIs only during the month of September 2018.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement":[
    {
      "Effect":"Allow",
      "Action":[
        "ses:SendEmail",
        "ses:SendRawEmail"
      ],
      "Resource":"*",
      "Condition":{
        "DateGreaterThan":{
          "aws:CurrentTime":"2018-08-31T12:00Z"
        },
        "DateLessThan":{
          "aws:CurrentTime":"2018-10-01T12:00Z"
        }
      }
    }
  ]
}
```

------

### Restricting the Recipient Addresses
<a name="iam-and-ses-examples-recipients"></a>

The following policy permits a user to call the SES email-sending APIs, but only to recipient addresses in domain *example.com* (`StringLike` *is case sensitive*).

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement":[
    {
      "Effect":"Allow",
      "Action":[
        "ses:SendEmail",
        "ses:SendRawEmail"
      ],
      "Resource":"*",
      "Condition":{
        "ForAllValues:StringLike":{
          "ses:Recipients":[
            "*@example.com"
          ]
        }
      }
    }
  ]
}
```

------

### Restricting the "From" Address
<a name="iam-and-ses-examples-from-address"></a>

The following policy permits a user to call the SES email-sending APIs, but only if the "From" address is *marketing@example.com*. 

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement":[
    {
      "Effect":"Allow",
      "Action":[
        "ses:SendEmail",
        "ses:SendRawEmail"
      ],
      "Resource":"*",
      "Condition":{
        "StringEquals":{
          "ses:FromAddress":"marketing@example.com"
        }
      }
    }
  ]
}
```

------

The following policy permits a user to call the [SendBounce](https://docs.aws.amazon.com/ses/latest/APIReference/API_SendBounce.html) API, but only if the "From" address is *bounce@example.com*. 

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement":[
    {
      "Effect":"Allow",
      "Action":[
        "ses:SendBounce"
      ],
      "Resource":"*",
      "Condition":{
        "StringEquals":{
          "ses:FromAddress":"bounce@example.com"
        }
      }
    }
  ]
}
```

------

### Restricting the Display Name of the Email Sender
<a name="iam-and-ses-examples-display-name"></a>

The following policy permits a user to call the SES email-sending APIs, but only if the display name of the "From" address includes *Marketing* (`StringLike` *is case sensitive*). 

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement":[
    {
      "Effect":"Allow",
      "Action":[
        "ses:SendEmail",
        "ses:SendRawEmail"
      ],
      "Resource":"*",
      "Condition":{
        "StringLike":{
          "ses:FromDisplayName":"Marketing"
        }
      }
    }
  ]
}
```

------

### Restricting the Destination of Bounce and Complaint Feedback
<a name="iam-and-ses-examples-feedback"></a>

The following policy permits a user to call the SES email-sending APIs, but only if the "Return-Path" of the email is set to *feedback@example.com*.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement":[
    {
      "Effect":"Allow",
      "Action":[
        "ses:SendEmail",
        "ses:SendRawEmail"
      ],
      "Resource":"*",
      "Condition":{
        "StringEquals":{
          "ses:FeedbackAddress":"feedback@example.com"
        }
      }
    }
  ]
}
```

------

# AWS managed policies for Amazon Simple Email Service
<a name="security-iam-awsmanpol"></a>

To add permissions to users, groups, and roles, it is easier to use AWS managed policies than to write policies yourself. It takes time and expertise to [create IAM customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) that provide your team with only the permissions they need. To get started quickly, you can use our AWS managed policies. These policies cover common use cases and are available in your AWS account. For more information about AWS managed policies, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) in the *IAM User Guide*.

AWS services maintain and update AWS managed policies. You can't change the permissions in AWS managed policies. Services occasionally add additional permissions to an AWS managed policy to support new features. This type of update affects all identities (users, groups, and roles) where the policy is attached. Services are most likely to update an AWS managed policy when a new feature is launched or when new operations become available. Services do not remove permissions from an AWS managed policy, so policy updates won't break your existing permissions.

Additionally, AWS supports managed policies for job functions that span multiple services. For example, the **ReadOnlyAccess** AWS managed policy provides read-only access to all AWS services and resources. When a service launches a new feature, AWS adds read-only permissions for new operations and resources. For a list and descriptions of job function policies, see [AWS managed policies for job functions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) in the *IAM User Guide*.

## AWS managed policy: AmazonSESFullAccess
<a name="security-iam-awsmanpol-AmazonSESFullAccess"></a>

You can attach the `AmazonSESFullAccess` policy to your IAM identities. Provides full access to Amazon SES.

To view the permissions for this policy, see [AmazonSESFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSESFullAccess.html) in the *AWS Managed Policy Reference*.

## AWS managed policy: AmazonSESReadOnlyAccess
<a name="security-iam-awsmanpol-AmazonSESReadOnlyAccess"></a>

You can attach the `AmazonSESReadOnlyAccess` policy to your IAM identities. Provides read only access to Amazon SES.

To view the permissions for this policy, see [AmazonSESReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSESReadOnlyAccess.html) in the *AWS Managed Policy Reference*.

## AWS managed policy: AmazonSESServiceRolePolicy
<a name="security-iam-awsmanpol-AmazonSESServiceRolePolicy"></a>

You can't attach the `AmazonSESServiceRolePolicy` policy to your IAM entities. This policy is attached to a service-linked role that allows Amazon SES to perform actions on your behalf. For more information, see [Service-linked role permissions for Amazon SES](using-service-linked-roles.md#service-linked-role-permissions).

To view the permissions for this policy, see [AmazonSESServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSESServiceRolePolicy.html) in the *AWS Managed Policy Reference*.

## Amazon Simple Email Service updates to AWS managed policies
<a name="security-iam-awsmanpol-updates"></a>

View details and about updates to AWS managed policies for Amazon Simple Email Service since this service began tracking these changes.


| Change | Description | Date | 
| --- | --- | --- | 
| Amazon Simple Email Service added a new managed policy | Amazon Simple Email Service added AmazonSESServiceRolePolicy to the service-linked role AWSServiceRoleForAmazonSES that allows SES to perform actions on your behalf | May 13, 2024 | 
| Amazon Simple Email Service updated a policy definition | Amazon Simple Email Service clarified the previous entry in this table (row below) to be: Amazon Simple Email Service added ses:BatchGetMetricData to AmazonSESReadOnlyAccess managed policy—this will give access to the SES API BatchGetMetricData | Apr 30, 2024 | 
| Amazon Simple Email Service updated a policy definition | Amazon Simple Email Service added ses:BatchGet\$1 to AmazonSESReadOnlyAccess managed policy—this will give access to the SES API BatchGetMetricData | Feb 16, 2024 | 
| Amazon Simple Email Service changed two policy definitions | Amazon Simple Email Service removed "via the AWS Management Console" from the end of the AmazonSESFullAccess and AmazonSESReadOnlyAccess definitions | May 3, 2023 | 
| Amazon Simple Email Service started tracking changes | Amazon Simple Email Service started tracking changes to its AWS managed policies | April 5, 2023 | 

# Using service-linked roles for Amazon SES
<a name="using-service-linked-roles"></a>

Amazon Simple Email Service (SES) uses AWS Identity and Access Management (IAM) [service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role). A service-linked role is a unique type of IAM role that is linked directly to Amazon SES. Service-linked roles are predefined by SES and include all the permissions that the service requires to call other AWS services on your behalf.

A service-linked role makes setting up SES easier because you don’t have to manually add the necessary permissions. SES defines the permissions of its service-linked roles, and unless defined otherwise, only SES can assume its roles. The defined permissions include the trust policy and the permissions policy, and that permissions policy cannot be attached to any other IAM entity.

You can delete a service-linked role only after first deleting their related resources. This protects your SES resources because you can't inadvertently remove permission to access the resources.

For information about other services that support service-linked roles, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) and look for the services that have **Yes** in the **Service-linked roles** column. Choose a **Yes** with a link to view the service-linked role documentation for that service.

## Service-linked role permissions for Amazon SES
<a name="service-linked-role-permissions"></a>

SES uses the service-linked role named **AWSServiceRoleForAmazonSES** – Allows SES to publish Amazon CloudWatch basic monitoring metrics on behalf of your SES resources.

The AWSServiceRoleForAmazonSES service-linked role trusts the following service to assume the role:
+  `ses.amazonaws.com` 

The role permissions policy named AmazonSESServiceRolePolicy is an [AWS managed policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) that allows SES to complete the following actions on the specified resources:
+ Action: `cloudwatch:PutMetricData` in the `AWS/SES` CloudWatch namespace. This action grants permission for SES to put metric data into the CloudWatch `AWS/SES` namespace. For more information about SES metrics available in CloudWatch, see [Logging and monitoring in Amazon SES](security-monitoring-overview.md).
+ Action: `cloudwatch:PutMetricData` in the `AWS/SES/MailManager` CloudWatch namespace. This action grants permission for SES to put metric data into the CloudWatch `AWS/SES/MailManager` namespace. For more information about SES metrics available in CloudWatch, see [Logging and monitoring in Amazon SES](security-monitoring-overview.md).
+ Action: `cloudwatch:PutMetricData` in the `AWS/SES/Addons` CloudWatch namespace. This action grants permission for SES to put metric data into the CloudWatch `AWS/SES/Addons` namespace. For more information about SES metrics available in CloudWatch, see [Logging and monitoring in Amazon SES](security-monitoring-overview.md).

You must configure permissions to allow your users, groups, or roles to create, edit, or delete a service-linked role. For more information, see [Service-linked role permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) in the *IAM User Guide*.

## Creating a service-linked role for Amazon SES
<a name="create-service-linked-role"></a>

You don't need to manually create a service-linked role. When you create SES resources in the AWS Management Console, the AWS CLI, or the AWS API, SES creates the service-linked role for you. 

If you delete this service-linked role, and then need to create it again, you can use the same process to recreate the role in your account. When you create SES resources, SES creates the service-linked role for you again. 

## Editing a service-linked role for Amazon SES
<a name="edit-service-linked-role"></a>

SES does not allow you to edit the AWSServiceRoleForAmazonSES service-linked role. After you create a service-linked role, you cannot change the name of the role because various entities might reference the role. However, you can edit the description of the role using IAM.

## Deleting a service-linked role for SES
<a name="delete-service-linked-role"></a>

If you no longer need to use a feature or service that requires a service-linked role, we recommend that you delete that role. That way you don’t have an unused entity that is not actively monitored or maintained. However, you must clean up your service-linked role before you can manually delete it.

### Cleaning Up a service-linked role
<a name="service-linked-role-review-before-delete"></a>

Before you can use IAM to delete a service-linked role, you must first delete all SES resources. 

**Note**  
If the SES service is using the role when you try to delete the resources, then the deletion might fail. If that happens, wait for a few minutes and try the operation again.

### Manually delete the service-linked role
<a name="slr-manual-delete"></a>

Use the IAM console, the AWS CLI, or the AWS API to delete the AWSServiceRoleForAmazonSES service-linked role. For more information, see [Deleting a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) in the *IAM User Guide*.

## Supported Regions for Amazon SES service-linked roles
<a name="slr-regions"></a>

SES does not support using service-linked roles in every Region where the service is available. You can use the AWSServiceRoleForAmazonSES role in the following Regions.


****  

| Region name | Region identity | Support in SES | 
| --- | --- | --- | 
| US East (N. Virginia) | us-east-1 | Yes | 
| US East (Ohio) | us-east-2 | Yes | 
| Asia Pacific (Sydney) | ap-southeast-2 | Yes | 
| Asia Pacific (Tokyo) | ap-northeast-1 | Yes | 
| Europe (Frankfurt) | eu-central-1 | Yes | 
| Europe (Ireland) | eu-west-1 | Yes | 