Your own AWS account

By default, your organization sends through Mailroomly's own sending and needs no AWS account. Sending from your own AWS account is an option the Mailroomly team enables for your organization. Once it is enabled, the Sending card on Plan shows Own AWS accounts Allowed, and Your AWS accounts appears at the bottom of Addresses.

Until then, there is nothing to set up: the accounts page says Own AWS accounts are not enabled. If the option is turned off later, accounts connected before keep working and stay reachable from their domains, but no new account can be connected.

Important

Everything on this page needs an administrator signed in to Mailroomly. An AI agent can't connect an account or add a domain that sends through one (what stays with a signed-in person).

What changes with your own account

• Mail of the domains you connect to the account goes out through Amazon SES in that account, within its own SES quota and send rate.
• Mailroomly's daily cap, send rate and marketing warm-up don't apply to those domains (Plan and limits). Your plan's monthly emails, and the daily limits per person and per API key, still count them.
• Each domain needs three DKIM records instead of one, and a custom tracking domain needs a certificate record too.
• Whoever manages the AWS account keeps it healthy: its SES production access, its quota, and the resources Mailroomly needs in it.

You can have domains of both kinds: each domain chooses how it sends when you add it.

Connecting an account

Open Addresses › Your AWS accounts › Connect account. Connect an AWS account has four steps, and Continue setup, on the account's page, takes you back to the step you left.

1. Account details

Enter a Name you recognize (for example your company's name), the Provider, Amazon SES, and the 12-digit AWS account id, shown in the AWS console menu. Choose Create and continue.

An AWS account can be connected by one organization only, and once to yours.

2. Apply the baseline

The baseline creates, in your AWS account, the access role, the topics and the bucket Mailroomly needs. Under Setup method, choose one:

• One-click (CloudFormation):
  1. Choose Launch stack in AWS, signed in to that AWS account. The stack opens in its region, with the external id and the platform principal already filled in.
  2. Tick the acknowledgment that CloudFormation may create IAM resources.
  3. Create the stack and wait until its status is CREATE_COMPLETE (a few minutes).
• OpenTofu, for an account managed as code: add the module shown to the account's OpenTofu configuration, then run tofu init and tofu apply with credentials for that account.

Values used by the baseline lists the external id, the region and the names it creates, for whoever reviews it. Then choose Mark the baseline as applied.

3. Verify

Choose Run verification. Mailroomly assumes the access role and checks each piece: Assume the access role, SES account, Events topic, Inbound topic, Inbound landing bucket, Receipt rule set and AWS account not connected elsewhere. Fix anything that failed in AWS (or wait for the stack to finish), then Verify again.

A warning about the Receipt rule set is normal before you receive email through the account. If it says another receipt rule set is active, the account already receives email with SES: Mailroomly won't turn on receiving for its domains until that rule set is deactivated or its rules are moved into Mailroomly's set. Talk to whoever manages the account first.

4. Production access

New SES accounts start in the sandbox, where they can only send to verified addresses.

• To test at once, add Sandbox test recipients with Add recipient. Each one receives a confirmation email from AWS and must confirm it.
• To send to anyone, fill in the Production access request: Mail type, Website, How will you send email? (who receives it, how they agreed, how you handle bounces and complaints, the expected volume) and Additional contact emails, then Request production access. AWS usually answers within 24 hours, by email.

Once AWS grants it, the account shows Production access granted.

Sending a domain through the account

When you add a domain (Your own domain), Send through chooses the account instead of The platform (recommended). The domain's page then shows Own AWS account, and Sends through, under Technical details, links to the account.

Its DNS records differ from a domain sent through Mailroomly (DNS records):

• DKIM signature: three CNAME records, each pointing to Amazon SES.
• MAIL FROM (MX) and MAIL FROM (SPF): on bounce.<domain>, pointing to Amazon SES.
• Tracking certificate: with a custom tracking domain, a CNAME that validates its certificate first. Then the Tracking domain record appears, and the tracking status goes Waiting for certificate → Deploying → Active.

The domain is Verified once SES confirms its identity and its three DKIM records, usually within minutes of publishing them and at most 72 hours.

If the domain already exists in SES in that account and Mailroomly didn't create it, adding it is refused, so that your existing setup is never changed. Use another domain or subdomain, or remove that identity in SES first.

Receiving. If another receipt rule set is active in the account, setting a domain to Sends and receives is refused with a Receipt rule set conflict. If someone activates another set later, incoming email stops reaching Mailroomly: the domain shows the same warning and the notice Inbound email stopped is raised until Mailroomly's set is active again.

The account's status

Your AWS accounts lists each account with its Health, Production or Sandbox, and what it sent in 24 hours against its SES quota (Sent in 24 h / quota; unlimited when SES sets no daily limit).

An account's page shows:

• Connection: the verification checks, with Run the verification again.
• Health: Healthy, Degraded (SES has disabled sending) or Failing, with Run health check, when it was last checked, Sending enabled, SES enforcement and the Max send rate.

Mailroomly checks every account each hour, and tries a failed check a second time before acting:

• If it can't send with the account (the access role or the SES account fails, or SES disabled sending), you get the notice Account health check failed and every type of email of the account's domains is paused, so mail waits instead of failing. Once the account is healthy again, those pauses lift by themselves; types you paused yourself stay paused.
• If AWS doesn't answer at all, nothing changes for 10 minutes, and queued email keeps trying: a short network failure pauses nothing. After that, your account counts as failing.
• When SES refuses a send because the account's sending is paused or suspended, the message goes back to the queue instead of failing, and the same pause applies.
• Other failures, such as a missing topic or bucket, raise the notice Account check warning, and sending continues.

When you erase a person's data (Erasing a person's data), emails received through the account are deleted from it too. If the account can't be reached, Mailroomly's copy is erased anyway, the result says how many originals are still in the account, and your next erasure tries again.

Removing an account

Delete account, in Danger zone on the account's page, is possible only after you remove its domains. Mailroomly stops using the account; nothing is removed in AWS.

If an erasure could not yet delete emails received through the account, deleting it is refused until it can: restore Mailroomly's access to the account, then delete it again. 62 days after they arrived, those emails have expired in the account and no longer hold it.

When you delete a domain that sent through the account, Mailroomly removes its SES identity, configuration sets and receipt rule. A custom tracking domain's CloudFront distribution and its certificate stay in the account: whoever manages it disables the distribution, deletes it once it shows Deployed, then deletes its certificate in ACM (us-east-1). Remove the domain's DNS records too.