What the CloudFormation stack creates
The stack creates one IAM role and nothing else. Here's what that role may do in your AWS account, and what EmailFig builds with it.
The emailfig-connect stack creates one IAM role, named EmailfigConnectRole, and nothing else that outlives the stack. Every permission on it is scoped to Amazon SES and to SNS topics EmailFig itself creates, and limited to the us-east-1 region. The stack also sends EmailFig a one-time signal that the role exists.
Who can use the role
Two conditions, and both must hold:
- The role trusts only EmailFig’s AWS account as a principal.
- The trust policy also requires an External ID that EmailFig generates for your connection. Knowing our account number isn’t enough on its own.
Sessions assumed through the role last at most one hour. When your stack registers, EmailFig deliberately tries to assume the role with a wrong External ID first; if that succeeds, we refuse to use the role rather than send anything through it.
What the role may do
| Area | Actions granted | Why |
|---|---|---|
| Sending | ses:SendEmail, ses:GetAccount |
Send your campaigns; read your sending quota, send rate, sandbox status and whether AWS has paused sending |
| Isolation and configuration | Create, read, list and delete SES tenants and configuration sets, their event destinations, the tenant-to-configuration-set association, and tag them | Give your account its own SES tenant and configuration set, and route delivery events out of them |
| Domain verification | Create, read and delete SES email identities, set their MAIL FROM attributes and their DKIM signing attributes | Verify your sending domains in your own account |
| Notifications | Create, read, configure and delete SNS topics whose names begin emailfig-lifecycle- in your account |
Receive delivery, bounce, complaint, open and click notifications |
Every statement pins the region to us-east-1.
What the role may not do
It has no access to anything outside SES and those SNS topics. It can’t read or write S3, touch EC2 or Lambda, create IAM users or roles, read your billing data, act in any other region, or see any SNS topic that isn’t one of ours. It can only use identities in your own account, so it can’t send from one you haven’t verified through EmailFig.
What EmailFig builds with it
Once the role is usable, EmailFig creates, in your AWS account:
- an SNS topic named
emailfig-lifecycle-<your EmailFig account id>, with a policy allowing only your own SES configuration set to publish to it, and EmailFig to subscribe; - an SES tenant, so your sending reputation stands on its own;
- a configuration set, and an event destination on it pointing at that topic;
- the association between the tenant and the configuration set, which SES requires before it will accept a send.
On our side we subscribe our own queue to your topic, using EmailFig’s credentials, which is why re-creating it is something only we can do. See AWS connection health errors. When you add a sending domain, the role also creates its SES identity, DKIM signing key and custom MAIL FROM.
What leaves your AWS account
Delivery, bounce, complaint, reject, delivery-delay, open and click notifications for the email EmailFig sent: that’s all. They travel from your SNS topic to a queue of ours, and they’re what makes bounce suppression, unsubscribe handling and your campaign reports work.
The two parameters
Both are pre-filled and masked in the console:
- External ID: the value the trust policy requires, generated per connection. Assuming the role also needs EmailFig’s own AWS credentials, so it isn’t a password.
- Callback token: single-use, and how the stack proves it’s the one we issued the link for. It’s spent the moment registration succeeds.
Change either and the stack builds a role EmailFig won’t use.
Deleting the stack deletes the role. EmailFig can then no longer send, verify domains, or receive your bounces and complaints, and new sends are blocked until it’s fixed.
If EmailFig ever needs more permission
Existing stacks keep the permissions they were created with. If a future feature needs a wider policy, we’ll contact you with the specific step to take. Re-running the quick-create link can’t do it, because the role already exists under a fixed name.