> ## Documentation Index > Fetch the complete documentation index at: https://docs.dmly.io/llms.txt > Use this file to discover all available pages before exploring further. # Data, privacy and consent > How opt-out, blocking, export and deletion work in DMLY — and precisely what each one does and does not stop. DMLY has four separate switches that people routinely confuse: **opt-out**, **blocked**, **bot paused**, and deleting the contact outright. They stop different things. Getting them mixed up is how a business keeps messaging someone who told it to stop. Read this first, because it is the one people get wrong: **Opting out stops automated messages. It does not stop an agent replying by hand.** A contact who sends STOP is removed from broadcasts, sequences, automations and booking reminders — but the Inbox composer stays open, and any team member can still type a message and send it. Nothing in DMLY blocks that. If your obligation is "we never contact this person again", opting them out does not achieve it on its own. ## The four switches | Switch | Set from | Stops | | -------------- | ------------------------------------------------ | ----------------------------------------------------------------------------------------- | | **Opted out** | The contact texts a STOP keyword, on any channel | All automated messages, everywhere | | **Blocked** | The conversation in the Inbox | Automated messages **and manual replies** — the composer is disabled; also pauses the bot | | **Bot paused** | **Pause bot reply** on the contact's page | Automations, sequences and booking reminders — a deliberate hand-off to a human | | **Deleted** | **Delete contact** on the contact's page | Everything — the record and its history are erased | Opt-out and blocked are the two that count as suppression. Both appear on **Contacts → Suppressions**. ## How a contact opts out A contact opts out by sending one of these words as their **whole message**: `stop` · `stopall` · `stop all` · `unsubscribe` · `cancel` · `quit` · `end` · `opt out` · `optout` The match is exact. "cancel my appointment tomorrow" does **not** opt anyone out, because the message is not only the word `cancel`. But a contact who replies with just `cancel` — meaning their booking, not your marketing — is opted out immediately and silently. **Telegram is the exception.** It recognises a shorter list — `/stop`, `stop`, `unsubscribe` and `cancel` only. `stopall`, `stop all`, `quit`, `end`, `opt out` and `optout` do **not** opt anyone out on Telegram. The rest of this section describes every other channel. Opt-out lives on the **contact**, not on one channel. A contact who sends STOP on WhatsApp is opted out of automated messages on Instagram, Telegram and SMS too, because it is one person record with several channel identities. See [Contacts overview](/contacts/overview). To opt back in, the contact sends `start`, `unstop`, `subscribe`, `opt in` or `optin`. On Telegram the word is `/start`. These are only honoured while the contact is already opted out — a contact who has never opted out cannot "double opt in" by typing `subscribe`. You can also clear it yourself with **Resubscribe** on **Contacts → Suppressions**. Only do that when you have a record of the contact asking. ## What opting out actually stops At the moment a contact opts out, DMLY immediately: * cancels any Flow they are currently running * stops any Sequence they are enrolled in From then on, automated messages do not reach them: * **Broadcasts** — opted-out contacts are still counted into the audience unless you tick **Reachable contacts only**; the send itself is refused at the channel sender, so they land in the broadcast's failed count rather than receiving the message * **Sequences** — due steps skip them * **Automations** — the send step refuses, and any "can I reach this contact?" check returns no * **Booking reminders** — appointment reminders are not sent DMLY also writes a system message into the conversation so your team can see what happened: *"Contact opted out (STOP) — automated messages suppressed. Agents can still reply manually."* ## What opting out does not stop **Manual replies from the Inbox.** The system message above is literal, not aspirational — there is no opt-out check on the Inbox send path. The composer works, the message sends, and the contact receives it. That is a deliberate design choice, because opt-out and customer service are different things: a contact who unsubscribed from your offers may still be mid-conversation about an order. It also means the discipline has to come from your team, not from the software. If you need certainty that nobody messages a person again, **block the contact** — blocking disables the composer, so it stops manual replies too, and it can be undone. Keep deletion for actual erasure requests. Brief your team on this. The contact's page shows an **Unsubscribed** state and the Suppressions list exists — but neither of them greys out the composer. ## The Unsubscribe tag Every workspace ships with one tag called **Unsubscribe**, and DMLY keeps it in step with opt-out automatically: it is attached when someone opts out and removed when they opt back in — on every channel except **Telegram**, where an opt-out records the date but never attaches the tag. That tag is why you cannot rename or delete it — the UI says so directly: *"This tag is required for opt-out compliance and can't be renamed."* Its practical use is in Segments. Add **Unsubscribe** to **Exclude contacts with tags** and the segment drops those people by tag as well as by timestamp — belt and braces on any audience you reuse. Because Telegram opt-outs never get the tag, treat it as the second belt rather than the thing doing the work. See [Tags and segments](/contacts/tags-and-segments). ## Blocking Blocking is a different axis from opt-out and is done from the conversation in the **Inbox**, not from the contact's page. It sets the contact's status to blocked and pauses their bot in one move, and automations treat a blocked contact as unreachable. Unlike opt-out, blocking also stops **manual replies**. The composer is hidden, and a request that gets sent anyway is refused by the server — the same goes for payment links. The conversation shows the contact is blocked, with the note *"— replies are disabled. Unblock from the details panel to message again."* Blocking is therefore the only switch short of deletion that stops your team sending by hand, and it is reversible. Use blocking for spam, abuse and time-wasters. Use opt-out for consent. A contact can be both, and the Suppressions list shows both. **Unblocking does not resume the bot.** Blocking pauses the bot as well as setting the status, but unblocking only restores the status. If you want the bot answering that contact again, use **Resume bot reply** on their page as well. ## The Suppressions list **Contacts → Suppressions** is a filtered view of *"Blocked and unsubscribed contacts — no automated messages are sent to them."* Filter it by **Blocked** or **Unsubscribed**. Each row gives you the action that matches its axis: * **Unblock** — clears the blocked status * **Resubscribe** — clears the opt-out and removes the **Unsubscribe** tag Two switches, two buttons. Unblocking someone does not resubscribe them, and resubscribing someone does not unblock them. A contact who is both needs both. Opt-out survives a merge. If you merge two duplicate contacts and either one had opted out, the surviving contact is opted out — with the earlier of the two dates. Consent is never lost by tidying up your records. ## Bot paused **Pause bot reply** on a contact's page is not a consent control. It is a human hand-off: it stops automations, sequences and booking reminders for that one contact while a person deals with them, and **Resume bot reply** puts them back. It has no bearing on whether the contact consented to anything. ## Exporting a contact's data **Contacts → Export** streams a CSV of your contacts, honouring the channel filter you have applied. It needs the export permission — see [Roles and permissions](/account/roles-and-permissions). The file has exactly seven columns, the same seven the importer reads: `name`, `country_code`, `phone`, `tags`, `stage`, `notes`, `custom_fields`. The `country_code` column is always written empty; the full number is already in `phone`, so a round trip back through [CSV import](/contacts/import-csv) still works. **This export is not a subject-access or data-portability export.** It is a round-trip file for the importer. It leaves out data DMLY holds about the contact, including their email address, lifecycle stage, source, status, opt-out date, birthday, language and timezone, their channel identities, and their **entire message history**. Do not hand it to someone as a complete answer to "send me everything you have on me". If you need to answer a data request properly today, you have to assemble it by hand from the contact's page — Profile, Custom fields, Activity timeline, Channels, Internal notes and the conversation itself — or pull it through the [API](/api-reference/introduction), which exposes considerably more of the record than the CSV does. ## Deleting a contact Erasure is a hard delete. **Delete contact** on the contact's page removes the contact and cascades to their channel identities, their whole message history, their internal notes, their client profile, and their tags. The confirmation says `Delete ? This cannot be undone.` and it means it. There is no soft delete, no undo, and no trash. There is also no anonymise or pseudonymise option and no retention policy — nothing ages contacts out on a schedule. Deleting is the only erasure DMLY has, and it takes the conversation with it. If you need the history for tax or dispute reasons, export or screenshot what you need **before** you delete. Deleting needs the delete permission, so you can keep it away from most of the team via [Roles and permissions](/account/roles-and-permissions). The same delete is available through the API. ## What DMLY does not have Being straight about the gaps is more useful than implying coverage: * **No contact-facing privacy page.** There is no "request my data" or "delete my data" link you can give a contact. Every request is handled by you, by hand, in the dashboard. * **No consent record.** DMLY records that someone opted *out*, and when. It does not record how or when they opted *in*. If you need proof of consent, keep it in a [custom field](/contacts/custom-fields) or a note. * **No retention schedule.** Data stays until you delete it. DMLY does handle Meta's data-deletion callback, but that is about a **connected social account** — an owner disconnecting their Facebook or Instagram login — not about a contact in your CRM. It never deletes CRM contacts. ## Practical rules for a compliant workspace Do not delete the **Unsubscribe** tag or try to work around opt-out. It is wired into every automated send path already. Put it in **Exclude contacts with tags** on any Segment you use for [Broadcasts](/broadcasts/audiences). Redundant, but free. The Inbox will happily send to an opted-out contact. If a person must not be messaged at all, block them as well — that is the switch that disables the composer. It is irreversible and takes the message history with it. Capture anything you are legally required to retain first. Seven columns is not the record. Build the answer from the contact's page or the API. Use the Unsubscribe tag to keep opted-out people out of an audience. How one person record spans several channels. Who a campaign actually reaches once suppression is applied. Restrict who can export or delete contacts.