Most of what arrives at a receiving domain is new mail. Some of it is people **replying to you** — to a broadcast, or to a message a Drip Workflow sent. SendOps recognises those, connects them to the contact and the send, and lets a workflow or a segment act on them.

## Where replies have to land

A reply goes wherever the recipient's mail client sends it: the message's **Reply-To** address if it has one, otherwise its **From** address. For SendOps to see it, that address has to be at a domain whose MX points at SES — a [receiving domain](/inbound/receiving-domains).

For a **broadcast**, set the **Reply-To** field in the form's From section (or `reply_to` over the API) to an address at a receiving domain — `replies@in.acme.com`, say — and keep sending from whatever From address you like. The Reply-To does not have to be a verified sending identity, and a receiving domain usually isn't one; see [who the email comes from](/sending-email/broadcasts#who-the-email-comes-from). Leave it blank and replies go to the From address, so they reach SendOps only if *that* domain is a receiving domain.

A **Drip Workflow** send has no Reply-To yet, so its replies go to its From address. To capture them, send it from an address at a receiving domain (`send "…" from "hello@in.acme.com"`). Pointing a whole primary domain's MX at SES just to get replies is a bigger decision than it sounds; see [the warning on that page](/inbound/receiving-domains#what-you-can-add).

## How a reply is matched

Every message SES sends carries a message id, and a reply quotes it in its `In-Reply-To` and `References` headers. SendOps reads those, in that order, and looks the ids up against the broadcast send log and the workflow run log. The first one that matches wins.

A matched message shows a banner on its row in the [message log](/inbound/message-log): **A reply to the broadcast …**, or **A reply to a message from the workflow …**, linking to it, with the contact identified. The **Replies** tile above the log counts them for the window.

Matching happens only for **delivered** messages. A reply your endpoint rejected, or one that parked, is still a reply in the mail sense, but SendOps records nothing about it beyond the log row.

## Auto-replies

Out-of-office notices and bounce-style auto-responses quote your message id too. SendOps detects them from the standard headers — `Auto-Submitted`, `Precedence: bulk` or `auto-reply`, `X-Autoreply`, `X-Auto-Response-Suppress` — and marks the message **Auto-reply** in the log. An auto-reply is still matched and still shown, but it **never** produces an activity and **never** changes consent. The detection is a hint from headers the sender controls, not a verdict.

## The `reply` activity

A matched, non-automatic reply is recorded on the contact as an activity named **`reply`**, source `inbound`, dated when the message was received. It carries the message id, the receiving domain, the subject, and the broadcast or workflow it replied to. One activity per message and domain, however many times the message is redelivered.

From there it is ordinary workflow and segment material with no new vocabulary:

```sendflow
enter on activity.reply
```

Its properties become queryable once you [promote them](/audience/activities) like any other activity's.

## Unsubscribe on STOP replies


  Nothing on this page changes a contact's consent until you switch it on, under **Reply intelligence** at the bottom of **Infrastructure → Inbound → Settings**. The switch needs the manage permission.


With **Unsubscribe on STOP replies** on, a reply whose **first line** is `STOP`, `STOP ALL`, `UNSUBSCRIBE` or `UNSUBSCRIBE ME` opts the contact out. The comparison ignores case and punctuation; it is the first line that is not blank, not quoted, and not below a signature separator. "Please stop sending me these" does not count — a sentence is not a command.

The keyword is detected inside the intake function in your account, and only the fact that it matched travels to SendOps. The reply's text never does.

Every one of these must hold, and each is checked deliberately:

- the message was **delivered**;
- it is **not an auto-reply**;
- it is a reply to a **broadcast** — a reply to a workflow send does not opt anyone out;
- the broadcast is **not transactional**;
- the switch is on.

What is written is what the [unsubscribe page](/sending-email/unsubscribe-page) writes: if the broadcast was sent under a topic, the contact is opted out of **that topic**; otherwise they are unsubscribed from **all** marketing mail. Both go through the same consent path, so the contact's timeline and your consent reporting see it the same way.

## Related pages

- [Message Log](/inbound/message-log) — where matched replies appear
- [Activities](/audience/activities) — promoting the `reply` activity's properties
- [Consent & lifecycle mail](/sending-email/consent-and-lifecycle) — what an opt-out means for what you can send