# The recipient is suppressed

A refusal here means the address carries a compliance entry: an unsubscribe, a complaint, a bounce, or a do-not-contact record. The entry shows its origin on the person's record, and a workspace member may clear the ones that are clearable. Do-not-contact is the one that is not cleared casually, and the Assistant cannot clear it at all.

- **Status:** Available
- **Audience:** both
- **Channels:** email
- **In the app:** #/inbox, #/relationships, #/needs-you, #/autonomy-audit
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/troubleshooting/suppressed-recipient/

## What the symptom looks like

- A reply or an outreach message is refused before anything is handed to a provider.
- The refusal names compliance rather than a delivery problem, and it appears in Needs You.
- Other recipients on the same thread may be reachable — entries attach to an address, not to a conversation.
- The refusal is on the record afterwards, because a refusal is a decision and is logged as one.

This is not a failed send. Nothing was handed to a provider, so there is no rejection to read and nothing to retry. [The reply would not send](/docs/troubleshooting/send-failed/) is the page for a provider refusing a message that did leave.

## Four origins, and what each one means

| Origin | What it means | Who may clear it | What can fail |
|---|---|---|---|
| Unsubscribe | The person asked not to be contacted at this address | A workspace member, deliberately | Clearing it because a colleague wants one more attempt — the request came from the recipient |
| Complaint | The recipient reported a message rather than ignoring it | A workspace member, rarely and with a reason | Treating it as an ordinary opt-out; it is a stronger signal about the sending domain |
| Bounce | The address itself failed, repeatedly or permanently | A workspace member, once the address is known to be good again | Suppressing the person when only the address is dead — a new address is a new identity |
| Do not contact | A standing instruction never to approach this person | A workspace member with the rights, and never the Assistant | Clearing it without knowing who set it or why; the origin is shown for exactly this reason |

> **Note** The Assistant's rights are deliberately narrower than a person's here. It can find the entry, explain it and tell you what it blocks; it cannot clear a do-not-contact record. That boundary is a design decision rather than a permissions oversight.

## The check, stage by stage

1. Trigger — an outbound message is prepared for an address that carries an entry.
2. User or external event — the entry itself came from an earlier event: a request to stop, a complaint, a bounce, or a person's instruction.
3. Authentication and workspace resolution — compliance data belongs to the workspace, so the check runs inside it and never across workspaces.
4. Ingest — the address is resolved to an identity and to the person behind it.
5. Canonical record — the message may exist as a written record; what it does not get is a provider.
6. Classification — suppression, unsubscribe, complaint and do-not-contact are checked together, in one place, before any outreach is written.
7. Knowledge, memory and rules — a `block:email` directive on the contact is a separate mechanism with a similar effect, and it travels with the person across channels.
8. Autonomy and approval — no autonomy mode overrides a compliance entry; `autonomous` does not mean unconditional.
9. Action — nothing is sent, and the reason is attached to the attempt.
10. Result — a recorded refusal that names the origin rather than a generic error.
11. Relationship, timeline and memory — the person's record shows the entry, so the next colleague sees it before writing.
12. Audit, usage and Needs You — the refusal appears in the Decision Log and, where somebody should know, in Needs You.

## What Connect did complete

- The address was resolved to a person, and the entry against it was found before any message left.
- The refusal was recorded with its reason, which is what makes it explainable later.
- Everything else on the thread is intact: the conversation, the history, and any reply to a different recipient.
- The entry itself was not changed. A refusal neither strengthens nor weakens the record that caused it.

## What Connect did not complete

- Nothing was sent to that address, and no provider was asked to try.
- No allowance was spent on a message that was never handed over.
- The thread was not answered, so if a person still needs a response, that need is unmet.
- The entry was not cleared, softened or aged out — clearing is always a person's deliberate act.

## What you can do, and when to escalate

1. Open the person's record and read the entry's origin.
   - Result: You learn which of the four it is, which decides whether clearing it is even reasonable.
2. Check whether the person has another identity you may legitimately use.
   - Result: A bounced work address and a live one are two identities on one person; an unsubscribe on one is not consent on the other.
3. For an unsubscribe or a complaint, leave it alone.
   - Result: The recipient asked. Clearing it to send one more message is the behaviour the entry exists to prevent.
4. For a stale bounce on an address you know now works, clear it and send once.
   - Result: A successful send proves the address; a second bounce restores the entry.

An administrator can see who set a do-not-contact record and when, review whether an entry was created by a sequence rather than by a person, and confirm whether the same human is reachable at another identity. Escalate when a business-critical recipient is blocked by an entry nobody in the workspace recognises — that is a question about provenance, and the Decision Log is where it is answered.

## Questions

### Does an entry stop a customer's own conversation as well?

Compliance is checked before any outreach. A person who opted out of a mailing list and then writes in has asked for two different things; where the intent really is 'never contact me', the block directive on the contact is the tool that expresses it across every channel.

### Can I clear it for one message only?

No, and that is deliberate. Clearing is a change to the record, not a one-message exception, so the decision is visible rather than hidden inside a single send.

### Why can the Assistant not clear a do-not-contact entry?

Because the entry represents a commitment the business made to a person. Reversing it is a human decision, and keeping the Assistant's authority narrower than a person's is what makes that commitment worth anything.

## Related

- [The suppression list](https://connectbyjbrh.com/docs/email/suppression-list/)
- [Do not contact](https://connectbyjbrh.com/docs/email/dnc/)
- [Unsubscribe](https://connectbyjbrh.com/docs/email/unsubscribe/)
- [An unsubscribe request, end to end](https://connectbyjbrh.com/docs/workflows/unsubscribe-workflow/)
- [Applying a suppression, end to end](https://connectbyjbrh.com/docs/workflows/suppression-application/)
- [Spam complaints](https://connectbyjbrh.com/docs/email/complaints/)
- [Connect Assistant](https://connectbyjbrh.com/docs/assistant/)

## What this page is based on

- Connect source pack — channels, §1 compliance: one place for suppression, unsubscribe, complaints and do-not-contact; the Assistant cannot clear a do-not-contact entry (`docs-source/sources/CHANNELS.md`)
- Connect source pack — the Assistant's narrower rights and the audit trail (`docs-source/sources/GENERAL.md` §5, §8)
- Connect capability registry (`docs-source/facts.py`) — `suppression_dnc`, `block_directive`, `audit_trail`