SendForever

How SendForever reaches your AWS account

SendForever runs Amazon SES in your own AWS account. It reaches it through an IAM role your account creates and can delete at any time, and it holds no access keys to it. This page is for whoever approves that access.

Access

  • A CloudFormation stack you create in your account makes the role. Only SendForever's AWS account can assume it, and only with an external ID unique to your team, so no other SendForever customer can use it.
  • SendForever keeps the role's ARN, never access keys to your account. Each session it opens with the role lasts at most an hour.
  • Delete the stack and the access ends at once. The bucket with your activity log is kept, since it is your data.
  • Every role the stack makes has a ceiling, a permissions boundary that is the most it can ever do. From version 17, SendForever applies new versions of the stack itself, from its own template, which it checks first; a version that needs more than the ceiling allows is one you apply, in the AWS console.
  • Read the template before you create the stack. AWS also lists everything it creates before you confirm. Read the CloudFormation template

What the role can do

Area
What it can do
Amazon SES Set up and check domains, configuration sets, templates, the suppression list and tenants; change the account settings you turn on in SendForever; and send email, for your tests and campaigns.
Activity log Query the events of your email in the S3 bucket the stack creates, with Athena.
Campaigns Run the Step Functions state machines and EventBridge Scheduler schedules named sendforever that send your campaigns, from your account.
Contacts Create and use one DynamoDB table, sendforever-contacts, for your contacts and audiences, and run the workflows that change subscriptions. It can empty the table, as managing contacts needs, but never delete the table itself.
The stack Read the stack that made the role, and apply the new versions SendForever publishes of it: only from SendForever's own template, which it checks first, and only within the ceiling the stack puts on every role it makes.
Images and links Create CloudFront distributions and ACM certificates for the images in your email, your BIMI logo and your links hosts.
Alerts Manage the SNS topics and CloudWatch alarms named sendforever.
Sending credentials Create IAM users under the path /sendforever/, each held by a permissions boundary to sending email and adding contacts.

What it cannot do

  • Reach any other AWS service, such as EC2 or RDS, any DynamoDB table but sendforever-contacts, any stack but its own, any S3 bucket but the one the stack creates, or anything in another AWS account.
  • Create IAM roles, change who may assume them or their permissions boundaries, or create IAM users outside /sendforever/ or with more than their boundary allows.
  • Go beyond its ceiling, or change it: a new version of the stack that needs more is one you apply yourself, in the AWS console.
  • Let another AWS account send as your domains, receive your email, or reach your bucket, your table or the alerts topic.

Two limits AWS does not let a role draw: its Amazon SES permissions cover the whole account in the region, the domains your app sends from included, and its CloudFront and ACM permissions reach every distribution and certificate in the account. SendForever only touches the domains you add to it and the distributions and certificates it creates.

What the ceiling cannot stop: within it, a version SendForever publishes can do anything the role could already do, such as send what SendForever can read to an address of its choosing. And the role ends with the stack only because the template does not keep it: SendForever's templates never do, and after deleting the stack you can check that no role named sendforever-AccessRole-… is left.

What SendForever can read

  • Who you sent email to, and its subject line, from the activity log in your account.
  • The content of your email only in your templates, and in the copies Mail Manager keeps for a domain where you turn kept copies on.
  • It reads them when someone in your team opens a page that shows them, and does not keep them. Only totals, such as how many people an audience has, are kept for a few minutes.

Where your data is

In your AWS account
  • Your contacts and audiences
  • Your templates
  • The activity log of every email you send
  • Copies of messages, for domains where you turn them on
  • The images in your email and your BIMI logo
Kept by SendForever
  • Your AWS account ID, the role's ARN and the region
  • Each domain's settings and its last check: its DNS records and what was found
  • Campaign settings: template, audience and schedule
  • Audience settings: the name, the name people see, the description and the last counts
  • A record of each import: file name, how many contacts, who agreed to the consent and when
  • The DMARC aggregate reports for your domains
  • The access key ID of sending users, never their secret
  • A fingerprint of each subscription key, never the key
  • A Cloudflare authorization, encrypted, until it expires within the hour
  • Your team's members

If you already send with Amazon SES

What stays as it is
  • Your app keeps sending as it does today, with the same domains and credentials. SendForever stops nothing you already send.
  • Connecting changes nothing in Amazon SES. A domain only changes once you add it to SendForever, and only that domain.
  • The stack adds its own resources beside yours, all named sendforever.
What changes, and when
  • A domain you add that is already in Amazon SES keeps its configuration set, and also sends its events to your activity log. Its MAIL FROM domain is only set if it has none.
  • Applying the recommended configuration set, from the domain's page, gives the domain a set of its own as its default. The set it had stays as it was, and its open and click tracking, webhook and kept copies carry over. Calls from your app that name a configuration set keep using that set.
  • Your Amazon SES contact list, if you have one, stays as it is: audiences keep their people in a table of their own in your account, sendforever-contacts.
  • Templates share one list in Amazon SES, so the ones your app sends show in SendForever too, and saving one here changes what your app sends.
  • The suppression list, Deliverability insights and the request for production access only change when you choose them here.