A **receiving domain** is a domain whose MX record points at SES in your receiving region. Mail sent to any address at it — `support@in.acme.com`, `ticket-4231@in.acme.com` — lands in your inbound bucket. Which of those addresses are delivered to your endpoint is decided later, by the domain's [webhook](/inbound/delivery-webhooks).

They are managed on **Infrastructure → Inbound → Settings**.

## What you can add

The domain must be, or sit under, a domain your organisation **already has in SendOps** as a sending domain. `in.acme.com` qualifies once `acme.com` is one of your domains; `acme.com` itself qualifies too. A domain SendOps only discovered in your SES account, but which you never added, does not.

Two more things must be true, and the error tells you which is missing:

- **Inbound is deployed** on the AWS account — see [Enabling Inbound](/inbound/enabling-inbound).
- **The domain is not already a receiving domain on this AWS account.**


  A receiving domain can equal a sending domain. If you make `acme.com` a receiving domain and publish the MX, **every** message to `@acme.com` goes to SES — your staff mailboxes included, if that is where they live. Use a subdomain unless you mean that.


## Adding a domain


  <Step title="Add the domain">
    On the Settings tab, choose **Add receiving domain** and enter the name. SendOps creates the SES identity for it in the receiving region and shows the records to publish. The domain starts as **Waiting for DNS**.
  </Step>
  <Step title="Publish the records at your DNS provider">
    Two kinds of record, both shown on the domain with copy buttons:

    - **One MX record** at the domain itself, value `10 inbound-smtp.<region>.amazonaws.com`, where `<region>` is your receiving region. This is what routes the mail.
    - **The identity records** — the CNAME records SES uses to verify the domain, `<token>._domainkey.<domain>` pointing at `<token>.dkim.amazonses.com`. These prove you control the domain; the region's SES will not accept mail for an unverified one.

    SendOps never publishes these for you. It holds no DNS credentials.
  </Step>
  <Step title="Wait, or press Verify">
    SendOps checks every two minutes for the first hour, every ten minutes for the first day, then hourly for a week; a half-hourly sweep re-arms the check for anything still waiting. **Verify** checks immediately.
  </Step>


A domain is **Verified** when both are true: the MX record resolves to the SES endpoint for the receiving region, and SES reports the identity as verified. The identity records carry a single verified flag between them, because SES verifies the identity, not each record.

## The states

| State | Meaning |
|---|---|
| **Waiting for DNS** | A record is missing. The message under the state says which: no MX pointing at the receiving region yet, or the identity is not verified yet. |
| **Verified** | Mail is being received. The state is final; SendOps stops checking. |
| **Check failed** | SendOps could not perform a check — a DNS resolver failure, or SES could not be read. It is **not** "the record is missing". Checking continues, so the state clears on its own once the check succeeds. |

**Cross-region** is shown as a note, not a warning: the receiving region is the region of the stack carrying Inbound, and it differs from your sending region whenever that region cannot receive mail. See [which regions receive](/inbound/enabling-inbound#which-region-receives).

## Deleting a domain

Deleting a receiving domain stops SendOps tracking it and re-publishes the routing without it. Within about a minute your intake function stops recognising the domain, and any further mail to it is recorded as parked with the reason **unknown domain**.

Two things deletion does **not** do, deliberately:

- **It does not remove your MX record.** SendOps never wrote it. Mail keeps arriving at SES, and keeps landing in your bucket, until you remove the record yourself.
- **It does not delete the SES identity.** The identity is shared by every use of the domain in that region, including sending, so deleting it could stop your own mail or a sibling organisation's.

Re-adding the domain later is a new row: the webhook and its signing secret have to be set up again.

## Related pages

- [Delivery Webhooks](/inbound/delivery-webhooks) — the next step: where the mail goes
- [Inbound as Code](/inbound/inbound-as-code) — declaring receiving domains in your repository
- [DNS Configuration](/domains/dns-configuration) — publishing records at common providers