Amazon SES
Amazon Simple Email Service (SES) is Amazon's Web Services (AWS) cloud-based email service. With it you can send transactional email, marketing messages, or any other type of high-quality content to your customers.
In order to integrate Amazon SES with Relyance AI you will need create a custom SES role, and establish a trust relationship with Relyance's service account, and provide the Role ARN, External ID, and Region to Relyance.
In Amazon SES:
Login to your Amazon account.
To to the IAM console and select Roles from the left-hand navigation menu.
Click the Create role button.
Select AWS account for the Trusted entity type.
Click Next.
In the Add permissions screen you'll want to find the appropriate policy:
Click Next.
In the final step, provide a meaningful Role name (eg. RelyanceSESReadOnly) and click the Create role button.
Create an External ID - this can be anything. (e.g. '9599ec49-abb3-47bb-a5b6-86c79fc10d32') The external ID is a secret that you will use and enter in the Relyance platform for additional security. While it could be anything, we recommend using a secret generator such as https://www.uuidgenerator.net/version4 to generate.
Once created, edit the new role and select the Trust relationships tab.
Update the trust policy to use the Relyance service account. Click the Edit trust policy button and update the policy accordingly:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::580082088342:user/tenant-prod-access"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "<< external ID >>"
}
}
}
]
}Ensure you replace '<< external ID >>' with the external ID you created previously. The line with "AWS": "arn:aws:iam::580082088342:user/tenant-prod-access" grants permission to the Relyance Service Account access to the resources associated with this role. 12. Copy this Role ARN to to be used in Relyance.
In the Relyance AI application:
- Login to your Relyance account.
- Navigate to the Settings (bottom-left corner).
- Select Integrations.
- Search and locate the Amazon SES integration card and click on it.
- Click on the Add Connection button on the top right
- Provide a meaningful name for the integration and click on the Add button
- In the Overview section, select the integration features you wish to enable for the integration, review the Scope and Permission, and Endpoint details and click on Continue. For more details, see Integration Features
- In the Connection section, provide the appropriate values and click on Continue,


- In the Authentication section, Choose SES Assume-Role under Authentication Method., then provide the SES Role ARN, External ID, and Region (defaults to
us-east-1) into their respective fields - If the Data Inspection check box is checked from step 7, In the Data Inspection section, provide the appropriate values and click on Continue Minimum Confidence Level: This property adjusts the sensitivity of the Data Inspection feature. Lower likelihoods (e.g., unlikely) offer more coverage but may produce false positives, while higher sensitivity (e.g., very likely) provides greater accuracy but less coverage.

- Review the configuration summary from the Completion section and click on Finish.
- Confirm the integration Status reflects Connected

Verify the connection is really working
Discovery reads the account's identities and templates:
ses:ListIdentities, ses:ListVerifiedEmailAddresses and
ses:ListCustomVerificationEmailTemplates. AmazonSESReadOnlyAccess covers
them, and the Terraform module at the end of this page grants the three explicitly.
- A failure at Authenticate is the trust policy or the external ID.
- Connected but nothing discovered. SES is regional and the sandbox is per region: an account whose identities live in a different region from the one on the connection returns an empty list rather than an error.
- Data subject requests need more than read access. The DSR feature reads and
deletes contacts in contact lists, so it requires write access
(
AmazonSESFullAccesscovers it) — the read-only policy above is enough for discovery only. Grant the wider policy only if you enable that feature.
Manage this integration with Terraform
Connections for this integration can be managed as code with the Relyance Terraform provider. Non-secret fields go in auth.params; secret fields go in auth.secrets_wo, which is write-only — never stored in Terraform state. Rotate secrets by bumping auth.secrets_wo_version.
resource "relyance_integration_connection" "aws_ses" {
vendor = "aws_ses"
name = "<your connection name>"
auth = {
method = "iam-role"
params = {
vendor_role_arn = "<vendor_role_arn>"
region = "us-east-1"
}
# Secret fields are write-only: sent to Relyance, never stored in state.
secrets_wo = {
external_id = var.aws_ses_external_id
}
secrets_wo_version = 1
}
scans = { "data-inspection" = { enabled = true } }
}