Browse the documentation

Using your own Amazon SES account

Applies when your sending is: Your own Amazon SES

Connecting your own Amazon SES account moves the sending itself onto your AWS account, along with the sender reputation, the delivery bill and the daily ceilings. None of the fair-use boundaries on the limits on hosted sending apply once you are on it.

Saving credentials is the whole of the decision. Issue Mint has no separate switch for which way a newsletter sends, so pasting a working access key into Settings, then the Sending tab, is what moves you.

What Issue Mint asks for

Issue Mint asks for three things: an access key ID, its secret access key, and the region your SES account lives in.

Create an IAM user in AWS with SES and SNS permissions and use its key. The secret is encrypted and never shown back to you, so the field displays the last four characters of what is stored and nothing else. Leaving it blank when you re-save keeps the stored secret rather than clearing it, which means you can correct a region without pasting your key again. The region is a dropdown rather than a free-text box on purpose: a mistyped region is the single most common reason a first setup fails.

The five steps that run when you save

Issue Mint works through your SES account immediately and reports each step with what it found. A failure stops the run rather than pressing on, because every later step depends on the ones above it.

  1. Check credentials. Confirms the key works and reads back what AWS allows the account, which is the daily quota and the maximum send rate. Both figures appear on the tab so you can see what your own account is good for.
  2. Production access. Reports whether the account is out of the sandbox. This one warns rather than fails, and the warning matters more than it looks.
  3. Create domain identity. Adds your connected domain to your SES account and puts its DKIM records on the Domain tab for you to add. With no domain connected there is nothing to sign, so the step warns and setup continues.
  4. Create configuration set. Creates the grouping your issues are sent through, which is what lets SES report delivery events back against them.
  5. Wire up bounce notifications. Creates a notification topic in your account and points it at Issue Mint, so bounces and complaints come back to us automatically and an address that has stopped working leaves your list on its own.

Why a test send is what verifies the setup

Setup finishing proves the plumbing exists. It does not prove that a message can get through, so Issue Mint will not let you publish on the strength of it.

The Sending tab has a test button, which sends a short message to your own account address through the SES account you have connected. A message that arrives moves the configuration to verified and allows publishing. A message that is refused marks it as not working and records the reason AWS gave. The same reasoning is behind test sends from the composer, which push a real rendered issue through the real send path rather than a simplified one.

What changes once you are on your own account

The reputation becomes yours, the quota becomes AWS’s answer rather than ours, the bill comes from Amazon, and none of the hosted boundaries apply.

Issue Mint reads the send rate AWS allows your account and stays under it rather than sending flat out, so a generous quota sends faster and a fresh account sends slower. The subscriber cap stops applying, the monthly allowance stops applying, and the warm-up ramp on a new account stops applying, because none of them were ever about you and all of them were about a shared reputation. Bounces and complaints still reach Issue Mint through the notification topic the setup created, so bounces and complaints go on working exactly as they did.

If the credentials stop working

Issue Mint revalidates your credentials once a week without sending anything, and emails you if they have stopped working.

The usual causes are an access key that was rotated or deleted, or permissions tightened on the IAM user. Until it is fixed, publishing is locked, and an issue you had scheduled will not go out: it goes back to draft with a note on it and needs rescheduling once sending is working again. That is the part worth knowing, because waiting for a scheduled issue to catch up on its own is waiting for something that does not happen.

Removing the credentials

Deleting your credentials locks publishing rather than returning you to Issue Mint sending.

This is deliberate, in that Issue Mint will not quietly start delivering your mail again under our reputation, but it does mean the Sending tab’s remove button is not an undo button. Set up the arrangement you want before you remove a working key. The reasoning in either direction is in choosing how you send, and the commercial side of the same question is on what sending gives you.

Questions

What permissions does the AWS user need?

SES and SNS. Issue Mint creates a domain identity, a configuration set, a notification topic and an event destination on your behalf, so an access key restricted to sending alone will get part of the way through setup and then stop.

Can I go back to Issue Mint sending afterwards?

Not by deleting the credentials. Removing them locks publishing until sending is set up again rather than handing delivery back to us, which is worth knowing before you remove a working key.

Which region should I choose?

Whichever region your SES account is actually set up in, which is not necessarily the one nearest you or the one your other AWS resources use. A region that does not match is the most common reason setup fails, and the error AWS returns for it is not obvious.

On the product side: how sending works.

Last updated 21 August 2026.

Try it on your own list.

14 days, every feature, no card. Sending works from the moment you sign up.

Start your trial