# Do not contact A do-not-contact instruction is the strongest thing in the compliance record. It is checked with every other compliance entry in the one place asked before outreach goes anywhere, it refuses a held draft at the moment somebody approves it, and it is not lifted casually. The Connect Assistant cannot lift one at all — that path does not exist for it, on purpose. - **Status:** Available - **Audience:** both - **Channels:** email - **In the app:** #/needs-you, #/inbox - **Last verified:** 2026-09-10 - **Canonical:** https://connectbyjbrh.com/docs/email/dnc/ ## What it is, and what it is not It is a recorded decision that a particular person or organisation is not to be approached. Unlike a bounce, it says nothing about whether a mailbox works. Unlike an unsubscribe, it does not have to come from the recipient using a link — it can be set because somebody asked in a phone call, because a relationship ended badly, or because a lawyer wrote. It is also not [blocking](/docs/email/blocking/), which is a durable direction held as a memory row tagged for the channel and answers a broader question about how Connect should behave towards somebody. The two are often wanted together and are worth setting together, because one governs what may be sent and the other governs what Connect thinks it should do. **Bounce** — A fact about a mailbox. Correctable. **Unsubscribe** — A recipient's preference about a kind of mail. Reversible, usually only at their request. **Complaint** — A recipient's judgement that your mail was unwanted. Rarely reversed. **Do not contact** — A standing decision that this party is left alone. Deliberately hard to reverse, and never by an automated actor. ## What it stops - Every outreach path. The compliance question is asked once, at the boundary, so there is no second route that composes a message without asking it. - The approval of a held reply. Approving fails immediately rather than quietly queuing, and the entry is shown with its origin so the person approving sees the reason. - Prospecting before a message is written. The check is a step in that flow, not a filter over its output, so nothing is drafted for a party that is not to be approached. What it does not do is erase anything. The person, the company, the threads, the calls and the history all remain readable, because a record of a relationship is often the reason somebody needs to know the instruction exists. Removing history to enforce silence would make the instruction impossible to honour by hand. ## Why the Assistant cannot lift one The Connect Assistant works over the same domain services a person does, and this is one of the few places where its authority deliberately stops short of a person's. The reasoning is not that an agent is untrustworthy in general; it is that the input reaching an agent is untrusted in particular. Mail arrives from outside, it contains instructions written by strangers, and a capability that can be talked into re-opening contact with somebody who asked to be left alone is a capability worth not having. > **Careful** Asking the Assistant to clear one, in any wording, will not work. It is not a permission that can be granted for a single request, and it does not become available because the person asking is the workspace owner. This is the same separation that keeps an approval a person's act rather than a step the engine can perform for itself, and it is written up in [separating authority](/research/authority-separation/). It is also why [prompt injection arriving as ordinary business mail](/research/prompt-injection-in-business-mail/) is treated as an expected condition rather than an attack scenario: the defence is that the dangerous action is not reachable, not that the text will be spotted. ## Setting one 1. Record it against the party it applies to, with the origin — who asked, when, and in what words. - Result: The entry can be defended later. An instruction with no origin is impossible to review honestly, because nobody can tell what it was meant to cover. 2. Say what it covers if that is narrower than everything: one company, one person, one channel. - Result: A person who does not want mail may still want the call they asked for, and an instruction that oversteps is as much a failure as one that under-reaches. 3. Set the matching block if the wish is broader than mail. - Result: The block holds across channels and across conversations that do not exist yet, because the directive reader works from the tag rather than from the wording. 4. Tell the people who deal with that account. - Result: The compliance record stops Connect. It does not stop a colleague picking up the phone, and that is the part a system cannot do for you. ## Lifting one It is a person's decision, taken in the workspace, with a reason that goes on the record beside the original. The bar is deliberately higher than for any other compliance entry, and the only comfortable case is the one where the party themselves has come back and asked to be contacted again — in which case their own message is the evidence. Two situations are worth naming because they come up and neither is a good reason on its own: a change of ownership at the other end, and the passage of time. Somebody new holding the same job does not withdraw the instruction, and an old entry is not a stale one. If the record is wrong, the answer is to establish that with the party, not to age it out. ## Questions ### Can I give the Assistant permission to clear one just this once? No. It is not a permission that is switched on for a request; the capability is absent by design. The action is available to a person in the workspace, with a reason recorded, and that is the only route. ### Does it stop replies to somebody who writes to us anyway? Outreach and reply are separate paths with separate gates that are never merged, so the mechanics of the two differ. In practice, an instruction to be left alone should be honoured by a person deciding how to respond, not routed around — the record exists so that decision is informed. ### What is the difference between this and an unsubscribe? Scope and reversibility. An unsubscribe is a preference about a kind of mail and can be reversed at the recipient's request. This is a standing decision about the party, is meant to be hard to undo, and is never undone by an automated actor. ## Related - [The suppression list](https://connectbyjbrh.com/docs/email/suppression-list/) - [Unsubscribe](https://connectbyjbrh.com/docs/email/unsubscribe/) - [Blocking a sender](https://connectbyjbrh.com/docs/email/blocking/) - [The compliance check before outreach](https://connectbyjbrh.com/docs/prospects/compliance-check/) - [Separating the agent's authority from the person's](https://connectbyjbrh.com/research/authority-separation/) - [Prompt injection arrives as ordinary business mail](https://connectbyjbrh.com/research/prompt-injection-in-business-mail/) ## What this page is based on - `docs-source/sources/CHANNELS.md` §1 — compliance and blocking - `docs-source/STYLE-EXAMPLE.py` — a suppressed recipient at approval time - Connect capability registry (docs-source/facts.py) — suppression_dnc, assistant