IMAP/SMTP setup for Bitrix24: deliverability and synchronization

Why IMAP in Bitrix24 loses emails and diverges from the server

A mailbox is connected via IMAP, emails are visible in the web interface, but they are not on the portal — this is what the most common failure looks like.

The portal polls the mailbox on a schedule, not at the moment of delivery: if the session drops or the server returns an error, some emails in the interval between polls are not picked up.

Sending breaks for another reason: the relay goes through the portal, and without aligned domain records and a correct sender mailbox, emails go to spam or are rejected on the recipient side — the employee is sure they replied, but the client received nothing.

The second class of problems is desynchronization of folders and labels. Mailbox state lives on the server side: read and reply flags, moved and deleted emails are tied to identifiers within a specific folder.

After reindexing at the provider, the portal sees it as new — labels are reset, emails are duplicated, and "Sent" diverges from what actually went out.

A shared department mailbox adds its own layer. One address for several employees — each has their own copy of the folder tree and their own labels: an email taken into work by one remains unread for the others.

And if correspondence went through a personal mailbox, the history leaves along with access — the portal is left with fragments without incoming messages.

In Bitrix24, this is solved by the connection scheme, not by repeatedly "reconnecting the mailbox." We break down how email synchronization with the portal works, what is configured separately for a shared mailbox, and how to achieve predictable deliverability.

What a well-tuned email exchange with the portal provides

When a mailbox is connected to Bitrix24 via IMAP, and outgoing messages go through authorized SMTP, each email leaves a trace in the delivery log: the recipient mail server response code, a read receipt, a reply flag, and a bounce report.

Without this link, emails go "into the void" — the employee sees the sent message but does not know whether it arrived, whether a filter cut it off, or whether the client opened it.

The practical effect is measured in numbers. The share of undelivered emails drops from several percent to tenths of a percent, and non-delivery stops being hidden: the bounce arrives in the portal and raises a notification to the responsible person.

Searching for a request by subject, address, or attachment takes seconds instead of a quarter of an hour — the correspondence history in the portal is stored in the contact card, not in the mailbox of a departed manager.

Duplicates are removed at the routing level: sales, support, and shared-address mailboxes are consolidated into a single stream, and one email does not create three parallel cards.

Read statuses and the fact of a reply are recorded automatically, so the manager sees not activity but coverage: which requests were responded to and which were not.

Correspondence history becomes predictable — the thread is assembled by headers and addresses, quotes do not break, and attachments are stored together with the message.

The response time to a request stops depending on who is on shift today: the distribution rule assigns a responsible person and reminds about overdue items before the client writes again.

IMAP connection modes in Bitrix24 and their limitations

Connecting a mailbox to the portal runs into email provider limitations: the number of simultaneous IMAP sessions, polling frequency, protocol availability on the plan, and the requirement for an app password with two-factor authentication.

It is these, not the portal settings, that determine which scheme will withstand the department's load.

An employee's personal mailbox and a shared department mailbox behave differently: in the first case, linking correspondence to the client card is important; in the second, several people should process one incoming batch without duplicates. Below are the options we apply in practice and their limitations.

We choose the scheme based on the department structure, not ease of setup: a mixed option — personal mailboxes for managers, a shared one for support — covers both tasks and stays within the provider's limits. Next, we break down how this is configured and what breaks when the sequence of steps is wrong.

How we configure email exchange: stages of engineering work

Email infrastructure in Bitrix24 consists of several independent layers: inbound via IMAP, outbound via SMTP, routing within the portal, and sender domain reputation.

A failure in any of them looks the same to an employee — "the email did not arrive" — so the stages proceed with verification at each one.

1. Audit of the email scheme. We assemble a mailbox map: where mail physically resides, who reads it from multiple devices, which forwarding and shared addresses are already in use.
2. Domain authentication check. We configure sender records — without them, emails from the portal go to spam for some recipients, and this looks like a "broken mailing."
3. Access design. We create a service mailbox with an app password, not a personal account: an employee changing their password does not break the exchange, and connections are visible in the logs.
4. Email routing rules. We set out which addresses go to specific pipelines, what is copied to responsible persons, how mailings and system notifications are handled — without duplicate deals.
5. Delivery checks. We send test emails inbound and outbound, test attachments, replies from the portal, and behavior when the server is unavailable: whether emails queue and whether they leave after recovery.
6. Synchronization and labels. We review read status and moves between folders when working from the portal and from a phone, as well as mailbox reconnection.
7. Handover to support. We provide the infrastructure map, routing scheme, credentials in secure storage, and the response policy.

After handover, the infrastructure is not left unattended: queue and deliverability monitoring is enabled, and any change to the email scheme goes through the same checklist.

Routing schemes, access rights, and policies

After the work, the client is left not with a "configured mailbox" but with a set of rules and documents according to which the email infrastructure lives without us.

We document not only the connection parameters but also the logic: who has access, where an email is routed, who is responsible for processing, and what to do in case of failure.

• Email routing scheme — which addresses the portal accepts, which queues and groups requests go to, and by what rules an email is linked to a contact, lead, or deal.
• Mailbox access rights matrix — who reads the shared mailbox, who replies on its behalf, who has the right to delete and export correspondence; rights are granted by groups.
• Request handling policy — response times by email type, escalation procedure, actions on non-delivery, and attachment handling rules.
• Email infrastructure documentation — server addresses, ports, encryption modes, service accounts, and integrations with CRM and external services.
• Employee instructions — how to connect a mailbox on a computer and phone, set up a signature and templates, and where to turn if access is lost.
• Change log — who changed settings and when, where service data is stored, and what is checked when connecting a new mailbox.

The set shortens the onboarding time for a new employee and removes dependency on a single administrator: an engineer understands the infrastructure from documents, not from correspondence.

A month later, we check the request log to see what questions employees still have and adjust the policy in a targeted way.

Project case study: how folder desynchronization and email loss were eliminated

The client is a sales department with distributed managers: requests came to three mailboxes and reached Bitrix24 through a chain of forwarding rules.

Provider filters cut off some emails with attachments; when forwarding failed, the email remained only in the manager's mailbox, and folders diverged when connected from multiple devices: what the phone saw, the web interface did not.

Such an infrastructure produced a constant background of losses: the share of emails that did not reach the card hovered around 6%, and requests like "the client wrote, but there is no email" accounted for 35–45 support tasks per month.

Searching for correspondence with a specific counterparty took 5–8 minutes — several mailboxes had to be manually reconciled.

What we changed

We started the analysis with the delivery log and email headers: we found where the chain breaks and which addresses bounce on the sender side.

Then we moved inbound to direct mailbox access via IMAP with a unified folder structure, and outbound through SMTP with authentication and mandatory logging of outgoing email to the card.

We added matching of addresses and subjects with system entities so that an email is immediately linked to the deal rather than settling in the general incoming stream.

Separately, we configured sender domain authentication records and queue logging — the delay is visible before a manager reports it.

After the changes, undelivered emails — 0.3%, email support requests — 4–6 per month instead of forty, search for correspondence by client — up to 30 seconds, because the history is stored in one place.

The email infrastructure stopped being a source of incidents: failures are caught by monitoring, not by a customer complaint.

How a shared mailbox differs from a personal one and what a department should choose

A shared department mailbox is one address to which all employees are connected: an email goes to the shared "Inbox" folder, and anyone can take it into work. The advantage is that no request is lost, and the flow is visible in full.

The disadvantage is that there is no person responsible for the request: the email either gets stuck or two people respond to it at the same time, and the client receives duplicates.

An employee's personal mailbox is synchronized via IMAP with a separate account. The person responsible for the request is visible immediately, correspondence is not mixed, and searching one's own history is faster.

The limitation is the opposite: the manager does not see the overall workload, and during vacation incoming messages accumulate unanswered.

In practice, a combination more often works: the shared address remains the entry point, and incoming email distribution goes to an assignee by a rule based on subject or label. The personal mailbox remains for correspondence with regular counterparties.

In Bitrix24, both schemes are connected via IMAP — the difference is not in the protocol but in routing rules and access rights.

The choice depends on the flow volume, the number of assignees, and control requirements. Before connecting, we run the scenario on a test mailbox: how the rules work, whether duplicates and autoresponder loops appear when forwarding between addresses.

Common email infrastructure failures and ways to fix them

Email infrastructure rarely breaks entirely — a specific area fails: emails are sent but land in spam, synchronization hits connection limits, and after changing the scheme duplicates appear in mailboxes. Below are the questions most often received from clients and what we check in each case.

Hosting interrupts synchronization due to a connection limit. How can this be worked around?

The limit is based on the number of simultaneous sessions per mailbox, not on the volume of correspondence, so polling all folders at once hits a refusal. We calculate the actual number of sessions, spread polling over time, and move shared folders to a separate mailbox.

Duplicate emails have appeared in mailboxes. Where do they come from?

Usually the mailbox is connected in two places at once — to an email client and to the portal, and both pull the same folders. We leave the mailbox with a single synchronization owner and configure a single rule for the Sent folder.

Will correspondence history be preserved when switching to a new scheme?

Yes, if the archive is migrated before switching. We export folders preserving the structure, attachments, and threads, connect the new mailbox, and only then disable the old one — correspondence remains searchable, and archive rights remain with the same roles.

Let's discuss your email scheme and return with a work plan

For the scope estimate to be accurate rather than an "industry average," we need your current mailbox scheme. Describe the task in free form — we will clarify the rest on a short call with your administrator.

It is worth sending approximately the following:

• How many mailboxes and domains are currently in use and where they live: your own server, a cloud provider, or both at the same time.
• How mail is integrated with Bitrix24: an external mailbox via IMAP, forwarding, a shared department mailbox — and which of these works unstably.
• What hurts most: emails land in spam, are duplicated, are lost when an employee leaves, or replies come from the wrong address.
• Whether there are mailings and how sending is configured: notifications, invoices, emails to clients from an address on your domain.
• Which departments correspond with clients and whether shared mailboxes are needed for sales, support, and accounting.
• What restrictions apply: correspondence retention requirements, corporate policies, access to the domain control panel.

From this we assemble an email work plan: the target mailbox scheme, the correspondence migration procedure, rollback points in case of failure, and the rules that stop emails from going to spam.

We will return with an estimate of the scope of work and a breakdown by stages, and we will include post-implementation support as a separate block — so that deliverability settings do not drift a month later.