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.
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 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 |
The check, stage by stage#
- Trigger — an outbound message is prepared for an address that carries an entry.
- 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.
- Authentication and workspace resolution — compliance data belongs to the workspace, so the check runs inside it and never across workspaces.
- Ingest — the address is resolved to an identity and to the person behind it.
- Canonical record — the message may exist as a written record; what it does not get is a provider.
- Classification — suppression, unsubscribe, complaint and do-not-contact are checked together, in one place, before any outreach is written.
- Knowledge, memory and rules — a
block:emaildirective on the contact is a separate mechanism with a similar effect, and it travels with the person across channels. - Autonomy and approval — no autonomy mode overrides a compliance entry;
autonomousdoes not mean unconditional. - Action — nothing is sent, and the reason is attached to the attempt.
- Result — a recorded refusal that names the origin rather than a generic error.
- Relationship, timeline and memory — the person's record shows the entry, so the next colleague sees it before writing.
- 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#
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.
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.
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.
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.