Inbound is a **capability** of your SendOps stack, added and removed from **Settings → Infrastructure** the same way as Edge. Adding it is a CloudFormation update you apply yourself; SendOps prepares the change and never modifies your account directly.


  Inbound needs the composable stack layout. An AWS account connected on the original layout sees **"This AWS account uses the original SendOps stack layout"** when it tries to add a capability. Moving an account to the new layout is done by SendOps on request and leaves you a pending stack update to apply — contact support.


## Which region receives

SES receives mail in 22 AWS regions, and your sending region may not be one of them. SendOps offers receiving in:

`af-south-1`, `ap-northeast-1`, `ap-northeast-2`, `ap-northeast-3`, `ap-south-1`, `ap-southeast-1`, `ap-southeast-2`, `ap-southeast-3`, `ca-central-1`, `eu-central-1`, `eu-north-1`, `eu-south-1`, `eu-west-1`, `eu-west-2`, `eu-west-3`, `il-central-1`, `sa-east-1`, `us-east-1`, `us-east-2`, `us-west-1`, `us-west-2`.

`me-south-1` receives mail but is not offered yet.

**If your stack's region is on that list**, Inbound goes on it. **If it is not**, SendOps tells you Inbound is not available in that region and suggests one, and you add a **second SendOps stack** in the suggested region from Settings → Infrastructure, carrying Inbound alone. SendOps never creates a second stack on its own.

| Your sending region | Suggested receiving region |
|---|---|
| `ap-south-2` | `ap-south-1` |
| `ap-southeast-5` | `ap-southeast-1` |
| `ca-west-1` | `ca-central-1` |
| `eu-central-2` | `eu-central-1` |
| `me-central-1`, `me-south-1` | `ap-south-1` |

A receiving region that differs from your sending region is ordinary. The only thing it changes is the SES endpoint your MX record names.

## Adding the capability


  <Step title="Choose Inbound">
    On **Settings → Infrastructure**, open the stack's capabilities and add **Inbound receiving**. On an existing stack this prepares a stack update; for a region with no stack yet, it prepares a new stack.
  </Step>
  <Step title="Apply the change in AWS">
    The change card gives three ways to apply it — the AWS Console, the AWS CLI, and a Terraform snippet. Two parameters are new with Inbound, an ingest endpoint and an API key that lets your account report outcomes to SendOps; the card supplies both values, because they are not something you can look up. Deployment takes three to five minutes.
  </Step>
  <Step title="Tell SendOps you started">
    Press **I've started the update**. SendOps watches the stack and, when it finishes, activates SES receiving in your account and writes the routing configuration your intake function reads. Cancelling instead discards the prepared change; nothing in your AWS account is touched.
  </Step>


Once the stack reports **active**, add a [receiving domain](/inbound/receiving-domains).

## What the update creates

All of it in the receiving region, in your account, and none of it holding SendOps credentials:

| Resource | Name | Purpose |
|---|---|---|
| S3 bucket | `sendops-inbound-<account>-<region>` | Raw messages under `raw/`, parsed parts under `parts/`, delivery claims under `claims/`, the routing configuration under `config/`. Private, encrypted, public access blocked. |
| Lambda function | `sendops-inbound-intake` | Parses each message and POSTs it to your webhook. 512 MB, 60 s timeout, reserved concurrency of 10 so a mail flood cannot consume your account's Lambda capacity. |
| SNS topic | `sendops-inbound` | SES notifies it when a message has been stored; it triggers the function. |
| SQS queue | `sendops-inbound-dlq` | Dead-letter queue for a notification the function could not process after its retries. 14-day retention. |
| SES receipt rule set | `sendops-inbound` | One catch-all rule, `sendops-inbound-catch-all`, that stores every message SES receives at your MX. Virus and spam scanning on. |
| EventBridge rule and API destination | `sendops-inbound-events` | Reports each message's outcome to SendOps, so the message log exists. |

The bucket has a **retain** policy: removing the capability, or deleting the stack, leaves it and its contents in place.

The lifecycle rules are set for you. `raw/` moves to Glacier Instant Retrieval after 30 days and expires after 400; `parts/` expires after 30 days; `claims/` after 400.

### Permissions granted to SendOps

The update adds scoped statements to your `SendOpsRole`, listed on [IAM Permissions](/aws-setup/iam-permissions#inbound-receiving). The shape worth knowing: SendOps can **list** the raw messages and **delete** delivery claims, so it can redeliver a message, but it has **no permission to read** a message.

## An account that already receives mail

SES allows one **active receipt rule set** per account per region. If your account already has one — an existing support pipeline, say — SendOps never replaces it. Instead its catch-all rule is **appended after your last rule**, so nothing of yours is shadowed, and the set is recorded as adopted.

Doing that changes a rule set your organisation did not create through SendOps, so it needs the **Adopt inbound receiving** permission. Without it, adding the capability is refused with the name of the set and the region, and the message asks an administrator of the organisation that set up the AWS account to make the change.

If the account's rule set is `sendops-inbound` already — a second SendOps organisation sharing the AWS account — there is nothing to adopt.

## Health

Two probes appear on the stack's status: **SES receiving is active and routing to SendOps**, and **No received mail is parked by a failed intake**, which watches the dead-letter queue. Neither can fail a stack validation; they inform. If receiving is switched off by hand in the AWS console, or the routing configuration is deleted from the bucket, SendOps restores it on its next reconcile.

## Removing the capability

Removal is refused while any [receiving domain](/inbound/receiving-domains) still routes through the stack — mail addressed to those domains lands through it and would start bouncing. Delete the domains first.

When you press **I've started the update** on a removal, SendOps deactivates its receipt rule set before your update runs, because SES refuses to delete an active set and the whole update would roll back. On an adopted set, only the SendOps rule is removed; your set stays active and untouched. The bucket and everything in it remain.

On a second-region stack that carries Inbound alone, removing the capability deletes the stack.

## Related pages

- [Inbound Receiving](/inbound/inbound-receiving) — overview
- [Receiving Domains](/inbound/receiving-domains) — the next step
- [IAM Permissions](/aws-setup/iam-permissions#inbound-receiving) — every action the capability grants
- [Supported AWS Regions](/aws-setup/supported-regions)