SendOps already runs your **outbound** mail through SES in your own AWS account. Inbound Receiving adds the other direction: mail addressed to a subdomain you own — `in.acme.com`, `support.acme.com` — is received by SES in your account, stored in an S3 bucket you own, and delivered to an HTTPS endpoint you choose as a parsed, signed JSON payload. Replies to your broadcasts are matched back to the contact who wrote them.


  Inbound Receiving is being enabled workspace by workspace. If you do not see **Inbound** under Infrastructure yet, it has not reached yours.


## How it works

Four pieces, and the order below is the order you set them up:

1. **The Inbound capability is added to your SendOps stack.** A CloudFormation update you apply from **Settings → Infrastructure** creates an S3 bucket, an intake function, an SES receipt rule and a dead-letter queue in your AWS account. See [Enabling Inbound](/inbound/enabling-inbound).
2. **You add a receiving domain and publish its DNS.** SendOps shows you an MX record and the identity records; you publish them at your DNS provider. SendOps holds no DNS credentials and never writes a record for you. See [Receiving Domains](/inbound/receiving-domains).
3. **You point the domain at a webhook.** An HTTPS URL, an optional list of which addresses to deliver, and what to do with spam and viruses. See [Delivery Webhooks](/inbound/delivery-webhooks).
4. **Mail arrives.** SES stores the raw message in your bucket, the intake function parses it and POSTs it to your endpoint, and what happened is recorded in the [Message Log](/inbound/message-log).

Everything after step 3 runs inside your AWS account. The intake function reads the message out of your bucket and calls your endpoint directly. SendOps is told the **outcome** — delivered, rejected, parked — and nothing else.

## What SendOps never sees

The role SendOps holds in your account can list the objects in the inbound bucket and delete a delivery claim. It **cannot read a message**: there is no `GetObject` on the raw mail, for SendOps or for anyone at SendOps. Three things follow from that:

- **The message log links to your AWS console**, not to a download. Opening the raw message is a thing you do in your own account.
- **Support cannot read a message back for you.** If an endpoint mishandled a message, the raw copy is in your bucket, and a **Redeliver** sends it again.
- **The outcome event carries identifiers, not content.** SendOps records the sender's address, the recipient, the subject line and SES's verdicts, so the log can answer *what arrived and what happened to it*. Bodies and attachments never leave your account.

Because the delivery originates in your account, **there is no SendOps IP range to allow-list**. Verify the signature on every request instead — the payload and the signature are documented for your developers at [developers.sendops.dev](https://developers.sendops.dev/api-reference/inbound-webhook).

## What it costs

AWS bills you directly for receiving — roughly **$0.10 per 1,000 messages**, plus S3 storage for the raw mail. SendOps adds nothing. Raw messages move to Glacier Instant Retrieval after 30 days and expire after 400; parsed attachments served to your endpoint expire after 30.

## Who can set it up

| Role | Can |
|---|---|
| Owner, Org Admin, Infra Admin, Developer | Add the capability, add and remove receiving domains, configure webhooks, redeliver messages, change the reply settings |
| Marketer, Support, Viewer | See receiving domains and the message log |
| Financial | Nothing on this page |

Merging the SendOps receipt rule into a receipt rule set your AWS account **already has active** is a separate permission, **Adopt inbound receiving**, held by the same four roles. See [Enabling Inbound](/inbound/enabling-inbound#an-account-that-already-receives-mail).

## Where it lives

**Infrastructure → Inbound**, with two tabs: **Messages** is the log of what arrived and what happened to it; **Settings** is where domains, DNS and webhooks live. Adding or removing the capability itself is done from **Settings → Infrastructure**, like every other capability.

## Related pages

- [Enabling Inbound](/inbound/enabling-inbound) — the capability, regions, what is provisioned, adoption and removal
- [Receiving Domains](/inbound/receiving-domains) — the DNS records and verification
- [Delivery Webhooks](/inbound/delivery-webhooks) — where mail goes, allow lists, postures, the signing secret
- [Message Log](/inbound/message-log) — outcomes, parked mail, Redeliver
- [Reply Intelligence](/inbound/reply-intelligence) — replies matched to broadcasts, STOP handling
- [Inbound as Code](/inbound/inbound-as-code) — declaring receiving domains in `sendops.json`
- [Webhook payload and signature](https://developers.sendops.dev/api-reference/inbound-webhook) — for whoever writes the endpoint