Setting up unsubscribe and subscription management in Bitrix24

Why Bitrix24 unsubscribe fails and what breaks in mailings

Unsubscribe fails not because of the button in the email, but because of discrepancies between the template, the send log, and the subscriber profile.

The unsubscribe link is assembled at substitution time and carries the recipient ID and a security hash; if the template was edited manually or moved between projects, the substitution stops matching the database — and the unsubscribe link does not work: it leads to a deleted page, a section without a handler, or a blank screen. The person clicks, nothing happens, and the next campaign is marked as spam.

The second typical failure is that the subscription status does not change.

The opt-out is recorded where the page handler put it, while the mailing reads the consent flag from another place: from the contact record, from a segment, or from an address list exported to an external system.

Until these sources are aligned, it is formally possible to unsubscribe from the mailing, but in practice it is not: the address remains in the selection and continues to receive emails.

The third layer is delayed sending. Even when the status has updated correctly, some emails are already queued, and the scheduled job continues to process the previous segment.

The subscriber receives one or two more emails after opting out — and those are exactly the ones that generate mailing complaints.

The cost of all three failures is shared: the complaint rate grows, the domain lands in spam filters, and deliverability falls across the entire database, not only for those who opted out. We explain how this is resolved.

What managed unsubscribe delivers: effect in numbers and processes

Subscription management is not a cosmetic link in an email but part of delivery infrastructure. When unsubscribe works in one click and consents are stored in the contact record, not only the recipient experience changes — sender reputation metrics change. Bitrix24 passes these events to CRM, so the effect is visible in numbers, not in feelings.

Mailing complaint rate falls

The "this is spam" button is a last resort, used when unsubscribe is hidden in the footer or requires writing to support. A clear link in the email header and immediate opt-out processing remove irritation before the "report spam" click.

The complaint rate drops to tenths of a percent and stays there — this is direct work on domain reputation.

Manual unsubscribes leave support

Previously, requests like "remove me from the mailing" came to a manager or a shared mailbox and were processed manually, with the risk of forgetting or doing it twice.

After setup, the opt-out is recorded automatically: the reason, date, and channel remain in the contact record. The share of manual unsubscribes drops almost to zero, and response time to a client request goes from hours to minutes.

Email deliverability becomes predictable

Segments are built by current consent status, so the mailing goes to those who really expect it. Fewer complaints and abandoned addresses — higher email deliverability and fewer hits in the Spam folder.

A separate report shows which segment and which email produce unsubscribes — there is something to manage, not guesswork.

Bitrix24 unsubscribe options: native, template-based, via integration

Opting out of a mailing is an event that needs to be captured and recorded, not just a checkbox in the contact record.

In Bitrix24, built-in unsubscribe covers the basic scenario: there is a link in the email, clicking it adds the address to the exclusion list, and subsequent sends to this contact do not go out.

The limitation is that the mechanism lives only inside the environment — if some emails go through an external service, the built-in logic will not see its unsubscribes.

Comparison of approaches

The choice comes down to where the sending is physically generated and who stores the master subscriber list. In a mixed setup, an unsubscribe webhook is almost always needed: the external service sends an opt-out event, and the receiver updates the contact in CRM.

We make opt-out processing idempotent — a repeated call does not create a duplicate — and verify the request signature, otherwise the exclusion list gets inflated from outside.

There is one acceptance criterion: after an opt-out, no mailing — neither built-in nor from the service — goes to that address, and the contact record shows when and why the subscription was removed.

Workflow: from subscription audit to policy handover

Setting up unsubscribe is not a checkbox in the interface but a subscription state: it lives in the address database, in the contact record, and in mailing segments at the same time.

Until these places are connected, an unsubscribed address returns in the next send — hence spam complaints and falling deliverability.

We build the workflow so that each step is verified separately and does not break already accumulated data:

1. Mailing audit. We export mailings, segments, and address sources, and mark where subscription status is not stored at all and where it sits in two places and diverges.
2. Subscription status scheme. We fix a dictionary: active, unsubscribed, topic-specific opt-out, complaint, invalid address. For each status we assign the primary source and the conflict behavior rule.
3. Unsubscribe setup. Link in the email footer, confirmation page, and click processing: the request must change the status, not just show "you have unsubscribed."
4. CRM integration. The status is written to a contact field — the manager sees the opt-out before calling, and the selection for the next send no longer takes this address.
5. Test send. A run on control addresses: the email arrives, clicking unsubscribe changes the status within seconds, and a repeat send to that address does not go out.
6. Import and exclusions. We check that loading an external database does not resurrect unsubscribed contacts, and that a complaint is recorded as a separate status, not by deleting the record.
7. Policy handover. We deliver a document: status dictionary, who changes them and through which interface, how to handle a "return me to the mailing" request, and how to verify the result after an update.

Such an order solves the main problem: unsubscribe stops being a one-off fix and becomes a managed state. New channels are then connected by extending the status scheme, not by rewriting the logic from scratch.

What you keep: email templates, rules, and documentation

After launch, you keep not only a working unsubscribe mechanism but also a full set of materials for it. Everything is in one directory: templates, rules, state diagram, and the policy for working with the subscriber database.

We check the handover simply — a new administrator should be able to close a typical subscriber request without asking us a single question.

• Email template — texts for unsubscribe confirmation, service and regular mailings, with ready-made substitutions and working links. You change the wording yourself, and the logic does not break.
• Unsubscribe processing rules — which events close the subscription, how re-consent is interpreted, what to do with a mailing complaint, and how to return an address to work.
• Status scheme — active, unsubscribed, paused, complaint: transitions between states, the basis for each, and who is allowed to change it.
• Mailing policy — frequency of touches, intervals between emails, segment restrictions. Compliance reduces the unsubscribe rate without losing response.
• Support instructions — step-by-step scenarios: manual unsubscribe on request, checking consent history, bulk export, actions in case of a sending failure.
• Data map and log — which subscriber fields are stored and where they come from, what and when is recorded, how records can prove the fact and time of unsubscribe.

Materials describe specific actions and contain examples, not general principles. They can be handed over to a new contractor or an internal team — work with subscriptions will continue without our involvement.

Case study: how we eliminated mailing complaints and manual unsubscribes

The client is a retail chain with a subscriber base of several tens of thousands of addresses. Mailings were sent through an external service, while subscription statuses lived in two places at once: in contact records on the portal and in the service database.

A person unsubscribed via the link in the email, the service marked the opt-out, but on the portal the contact remained active — and the next mailing went out again.

What we changed

We made the portal the source of truth: Bitrix24 receives the unsubscribe event, places a mark in the contact record and in the unified unsubscribe list. The reverse flow — manager edits and import — goes to the service when a change occurs, not as a full export.

The exchange runs on a schedule, so a spike in unsubscribes after a large mailing is not lost. Manual unsubscribe was closed as an operation: a contact can be returned to the mailing only upon an explicit client request.

Metrics before and after

Before setup: about 400 "this is spam" complaints per month and 6–8 manual unsubscribes per week — managers fixed statuses by hand.

After: complaints dropped by an order of magnitude, manual operations disappeared from the process, and the database discrepancy fell to zero — reconciliation shows the same status on the portal and in the service.

Unsubscribes stopped being routine: marketing sees a unified list and does not risk email deliverability.

How unsubscribe differs from consent management in an email service

Unsubscribe and consent are different entities, and confusing them results in emails going to those who have already opted out. Unsubscribe is a technical event: the address enters the mailing service's exclusion list, and emails are not sent to it.

Consent is a legally significant record: who, when, and through which form allowed their data to be processed and mailings to be received.

The mailing service cannot be the source of truth. It sees the address and the fact of opt-out, but it does not know the basis, channel, or term.

If unsubscribe remains only a label inside the mailing platform, the manager continues to write from the client record — after all, it still says "agreed."

We separate areas of responsibility by events:

The single source of truth is the client record in Bitrix24: consent, its source, date, and withdrawal live there, while the mailing service receives status via exchange and remains the executor.

Unsubscribe in the email creates a withdrawal record, and changing the status in the record immediately removes the address from mailing segments.

We write each change with date and channel — this is both status synchronization and the evidence base when handling a complaint. Re-consent is formalized the same way: with source and date, otherwise the opt-out cannot be confirmed.

Technical questions about subscriptions and unsubscribe

An email sent after an unsubscribe is more expensive than a missed mailing: it generates a complaint and reduces deliverability for the entire domain.

Therefore we keep subscription and opt-out scenarios in one environment — state on the contact record, a unified exclusion list, and a change log with author and basis.

Below are the questions that most often come up at acceptance: how this is transferred, what happens on re-subscription, and whether a mass unsubscribe can be rolled back.

How does re-subscription work after an opt-out?

Only through an explicit action by the person — confirmation by email or via a form, with a record of the date and source of consent. Silent re-subscription during the next database load does not work: the import does not overwrite the opt-out, but adds an entry to the log.

What happens during a mass unsubscribe, and can it be rolled back?

A mass unsubscribe goes through the exclusion list, and each change is written to the log with its source. We roll back via the log — pointwise or as a group for the required period.

Automated scenarios read the same list, so an unsubscribed contact will not receive an email from a parallel branch.

What permissions are needed, and what is visible in the change history?

Permissions for the mailing section and the exclusion list are enough; full administrative access is not needed. The change history records the author, time, and basis — email, form, operator, or upload. The log is exported to a table so support can cross-check requests without logging into the portal.

Let's discuss the task: what to prepare for the start of work

To come back with an estimate and implementation plan, rather than general words, we need input data about your environment. Below is what is worth preparing for the task discussion; we will clarify the rest on the call.

• Portal: Bitrix24 in the cloud or an on-premise version, which external systems exchange data with it.
• Where subscriptions currently live: mailings, notifications, segments, deals — and who is responsible for setting them up.
• Current unsubscribe scenario: whether there is a link in the email, what happens on click, where complaints and opt-outs go.
• Channels and message types that need to be distinguished on unsubscribe: service, marketing, transactional.
• Requirements for the subscription log: what must be recorded, who needs exports and how often.
• Constraints: personal data regulations, integrations that cannot be changed, and deadlines by which you need to be ready.

The start order is: a call, review of the input data, agreement on the target scheme — and we come back with a work estimate and implementation plan: stages, control points, rollback procedure. If some data is not at hand, we will collect part of it ourselves using access. Describe the task in two or three paragraphs — that is enough to start.