Email в Bitrix24 и amoCRM: техническая архитектура отправки, типичные узкие места и как починить доставляемость

от автора

Bitrix24 и amoCRM — две доминирующие CRM в России — отправляют email принципиально разным образом, но имеют общую проблему: ни одна из них не показывает, дошло ли письмо до инбокса получателя. Зелёный статус «Письмо отправлено» в карточке сделки означает только то, что SMTP-сервер получателя принял письмо. Куда оно легло у клиента — спам, входящие, промоакции — CRM не знает.

В статье:

  • архитектура отправки в каждой системе (Bitrix24 «Облако» / «Коробка», amoCRM с привязанным IMAP/SMTP);

  • какие у каждой есть API и события для интеграции;

  • какие заголовки добавляются автоматически, какие надо контролировать;

  • где письма теряются (на каком из уровней) и что это значит для разработчика;

  • встраивание webhook-driven мониторинга через REST API с примерами кода;

  • типовые DNS-настройки SPF/DKIM/DMARC для отправителей через Bitrix24 и amoCRM.

Почему CRM-отправка — отдельный класс проблем

Большинство deliverability-статей рассматривают два случая: транзакционные письма (через SendGrid, Postmark, UniSender Go) и маркетинговые рассылки (через ESP — UniSender, SendPulse, Mindbox). CRM не попадает ни в одну категорию полностью:

  • Это не транзакционка, потому что письма часто шлются менеджером вручную из карточки клиента

  • Это не массовая рассылка, потому что отправляется по одному, но в большом количестве и из одного домена

  • Содержание сильно индивидуально, но шаблоны и подписи могут совпадать тысячами

  • Поведение базы непредсказуемо, потому что менеджеры пишут разным контактам без предварительной сегментации

  • Отправитель — корпоративный почтовый ящик, у которого репутация формируется и портится одновременно несколькими процессами

И ещё одна особенность: для CRM-отправки обратная связь критична. Если в маркетинговой рассылке вы можете позволить себе 5% попадания в спам, в CRM это означает 5% сорванных сделок: КП не дошло, клиент не понимает, что произошло, конверсия падает на пустом месте.

Bitrix24: архитектура email

Bitrix24 — это сразу несколько продуктов с разной архитектурой отправки. Это часто упускают из виду.

Bitrix24 «Облако» (cloud-версия)

Облачная Bitrix24 на b24-xxx.bitrix24.ru. Email-отправка идёт двумя путями:

1. Внутренний почтовый клиент Bitrix24 — модуль, где менеджер привязывает свой почтовый ящик через IMAP+SMTP или OAuth. Все письма с/на этот ящик становятся видны в карточках клиентов.

Поток отправки:

Менеджер пишет письмо в Bitrix24 → Bitrix24 backend через SMTP клиента → SMTP-сервер привязанного ящика (Я.360 / GSuite / corp Exchange / прочее) → получатель

То есть с точки зрения принимающего сервера письмо идёт от вашего почтового сервера, не от Bitrix24. Это правильная архитектура: репутация формируется на вашем домене.

2. Системные уведомления и шаблонные письма — отправляются с серверов самого Bitrix24 от имени noreply@yourportal.bitrix24.ru или с настроенного адреса. Тут начинаются вопросы.

Bitrix24 «Коробка» / 1C-Битрикс CMS

Self-hosted версия Bitrix. Архитектура отправки:

1. PHP mail() через настроенный sendmail на сервере

Базовый дефолт. Письма идут с IP-адреса сервера, где стоит Bitrix. Если это shared-хостинг (что для коробочной Битрикс редкость, но бывает) — IP с плохой репутацией. Если выделенный сервер — IP не прогрет.

2. SMTP через настроенный модуль

В административной панели → Настройки → Почтовые шаблоны → можно указать SMTP. Это правильный путь. SMTP может быть:

  • Корпоративный сервер организации

  • Внешний транзакционный сервис (SendGrid, Mailgun, UniSender Go, Postmark)

  • Любой другой SMTP

3. Через события OnBeforeEventAdd / OnEventAdd

Разработчик может перехватить событие отправки и реализовать любую логику отправки, включая использование внешнего API. Это самый гибкий путь, и он используется при кастомных интеграциях.

Архитектура события:

php

AddEventHandler("main", "OnBeforeEventAdd", "MyCustomMailHandler");function MyCustomMailHandler(&$event, &$lid, &$arFields){    // здесь можно перехватить отправку и сделать что-то ещё:    // отправить параллельно на seed network для проверки,    // залогировать факт отправки в БД,    // отправить через внешний API (Mailgun, SendGrid)        return true; // или false, чтобы отменить штатную отправку}

REST API Bitrix24

Для интеграций — REST API с методами:

  • crm.activity.add — добавить активность (включая email) к лиду/контакту/сделке

  • mailservice.sender.add — настроить отправителя (для коробки)

  • crm.activity.communication.fields — управление коммуникациями

Реальная отправка email через API возможна через создание Activity типа Email с указанием получателя, темы, тела. Bitrix24 при создании такого Activity сам инициирует отправку через настроенный механизм (SMTP облачной версии или коробочный SMTP).

Где Bitrix24 теряет письма

Я разбираю по типичным сценариям, которые мы видим на проектах.

Сценарий 1: облако + привязанный ящик на Mail.ru / mail.ru business

  • Менеджер привязал свой manager@yourcompany.ru, размещённый на Mail.ru для бизнеса

  • Bitrix24 шлёт через SMTP Mail.ru

  • На стороне получателя — Authentication-Results показывает spf=pass dkim=pass dmarc=pass (Mail.ru правильно подписывает)

  • НО: если ваш домен Mail.ru для бизнеса использовался для массовой рассылки или имеет жалобы в FBL, репутация шарится между всеми ящиками этого домена

  • Менеджер пишет КП → улетает в спам, потому что вчера маркетолог из той же компании отправил рассылку, на которую кто-то нажал «спам»

Дебаг: смотреть Postoffice от Яндекса и postmaster.mail.ru для вашего домена — там видны статистика и причины.

Сценарий 2: коробка + PHP mail()

  • Самый типичный для проектов на 1C-Битрикс CMS

  • IP-адрес сервера не прогрет, не имеет DKIM, не настроен PTR-запись (reverse DNS)

  • Все письма с сервера улетают на Mail.ru/Яндекс с рейтингом «новый отправитель» → большая часть в спам

  • В админке Битрикса всё «отправлено»

Дебаг: проверить заголовки реально отправленного письма (отправить себе на Gmail, открыть Show original).

Сценарий 3: коробка + SMTP через корпоративный Exchange

  • Письма из CMS идут через корпоративный Exchange

  • На Exchange настроено SPF / DKIM / DMARC — вроде всё хорошо

  • НО: те же серверы Exchange используются и под маркетинг, и под обычную переписку

  • Когда маркетинг шлёт рассылку и портит репутацию — страдают и письма из CMS

Сценарий 4: облако + отправка с @bitrix24.ru

  • Системные уведомления идут с noreply@yourportal.bitrix24.ru

  • Этот домен — Bitrix24, не ваш

  • У пользователей нет доверия и нет правил в почтовой клиентах для этого домена

  • Часть писем уходит в Promotions у Gmail, часть в спам у Mail.ru

amoCRM: архитектура email

amoCRM устроена иначе. Email — не «отдельный модуль для рассылок», а полноценный почтовый клиент внутри карточки клиента. Архитектура:

Подключение почты

Менеджер подключает свой почтовый ящик через IMAP+SMTP или OAuth (Gmail, Я.360, Outlook, Я.Почта, Mail.ru для бизнеса). После подключения:

  • Входящие письма от/в адреса привязанные к контактам автоматически попадают в карточки

  • Исходящие письма из карточки идут через SMTP подключенного ящика

То есть архитектурно amoCRM ближе к Bitrix24 «Облако» с привязанным ящиком: реальная отправка через SMTP вашего почтового провайдера.

Поток отправки

Менеджер пишет письмо из карточки → amoCRM backend → SMTP/OAuth подключенного ящика (Я.360 / Gmail / Mail.ru / corp Exchange) → получатель

API amoCRM

Для интеграций есть REST API и webhook’и:

  • GET /api/v4/leads/{id} — карточка сделки

  • POST /api/v4/leads/{id}/notes — добавить примечание (включая email)

  • Webhook’и на событие создания/изменения карточки и сообщения

Прямого API для отправки email через amoCRM нет (можно отправить только через REST API того сервиса, который подключен — Gmail API или SMTP сервера). Это значит, что инструменты автоматизации (Salesbot, Digital Pipeline) тоже шлют через подключенный ящик.

Особенность: salesbot и шаблоны

amoCRM позволяет менеджеру/админу настроить шаблоны писем и автоматические сценарии Salesbot. Это создаёт интересную ситуацию:

  • Шаблон с одним и тем же текстом отправляется тысячами разных карточек разным контактам

  • Технически это идёт через личный SMTP менеджера

  • С точки зрения провайдера-получателя — это массовая рассылка с личного ящика менеджера

  • Mail.ru, Яндекс, Gmail и Microsoft видят паттерн: одинаковые письма, разные адресаты, нормальный личный ящик → подозрение

Типичная ошибка: менеджер настроил шаблон «приветствие нового лида», который Salesbot шлёт всем новым лидам. Через 2 недели открываемость падает с 60% до 15%. Причина — Mail.ru начал режать одинаковые письма с этого ящика как массовку.

Где amoCRM теряет письма

Сценарий 1: личный Gmail подключён к amoCRM

  • Менеджер подключил manager@yourcompany.com через Gmail OAuth

  • Лимит Gmail для Workspace — 2000 писем в день; лимит «relay/SMTP» — 10 000 в день, но при «спайках» Gmail throttle’ит

  • Шаблонные письма через Salesbot быстро попадают в фокус Postmaster Tools → Gmail снижает доставляемость

Сценарий 2: ящик на Я.360 для бизнеса

  • В целом более лояльная среда

  • Лимиты — 500 писем в сутки на исходящие с одного аккаунта (по последней документации)

  • При превышении — временная блокировка отправки

Сценарий 3: личная Я.Почта (@yandex.ru)

  • Не предназначена для outbound, лимиты ещё жёстче

  • 100 писем в сутки с задержкой между отправками

  • Использовать как «бизнес-ящик» в amoCRM плохая идея

Сценарий 4: Mail.ru для бизнеса

  • Аналогично — есть лимиты и FBL-обработка

  • Проблема общей репутации домена та же, что и в Bitrix24

Технические настройки для повышения доставляемости

1. DNS-аутентификация на вашем sender-домене

Если в Bitrix24 / amoCRM подключен ящик manager@yourcompany.ru, в DNS домена yourcompany.ru должно быть:

SPF:

yourcompany.ru.  IN  TXT  "v=spf1 include:_spf.mail.ru                                   include:spf.smtp.bitrix.info                                   ~all"

(добавьте включения для всех ESP/SMTP, через которые шлёте — Mail.ru для бизнеса, Я.360, Gmail Workspace, Bitrix24 mail relay)

DKIM:

DKIM настраивается на стороне SMTP-провайдера, и публичный ключ публикуется в DNS. Если ящик на Я.360 — Яндекс даст инструкции и ключ. Если Mail.ru для бизнеса — Mail.ru. Если Gmail Workspace — Google. Без DKIM: на Bitrix24 с PHP mail() и без настроенной подписи письма пойдут с dkim=none, что для Mail.ru — фактор спама.

DMARC:

_dmarc.yourcompany.ru.  IN  TXT  "v=DMARC1; p=quarantine;                                   rua=mailto:dmarc-reports@yourcompany.ru;                                   pct=100"

2. Разделение outbound по доменам

Хороший паттерн: основной корпоративный домен (yourcompany.ru) используется только для личной переписки и КП от менеджеров. Маркетинговые рассылки идут с отдельного outbound-домена (get-yourcompany.ru или try-yourcompany.ru), у которого своя репутация.

Это особенно важно для отправителей через amoCRM с Salesbot-шаблонами — выделить под автосообщения отдельный домен и подключить отдельный ящик.

3. Bitrix24 «Коробка» — не использовать PHP mail()

Всегда настраивать SMTP в Bitrix CMS через панель администратора. Лучше через внешний транзакционный сервис (UniSender Go, SendPulse SMTP, Mailgun), а не через PHP mail().

4. amoCRM Salesbot — варьировать контент

Если используете автосценарии — генерировать вариативность в шаблонах (несколько версий с разными вступлениями, разные подписи, разные структуры абзацев). Иначе одинаковые письма триггерят фильтры.

Webhook-driven мониторинг через REST API

Архитектура контроля доставляемости для CRM:

Bitrix24/amoCRM шлёт письмо → параллельно отправляется тестовое на seed network → через 30-60 секунд REST API возвращает placement → если spam_rate выше порога — алерт в Telegram/Slack + запись в БД для аналитики

Для Bitrix24 «Коробки» через OnAfterEventAdd:

php

AddEventHandler("main", "OnAfterEventAdd", "MonitorDeliverability");function MonitorDeliverability($event, $lid, $arFields){    // Параллельно отправляем на seed network    $seedAddresses = getSeedNetworkFromApi();        foreach ($seedAddresses as $seed) {        // Отправляем то же письмо через те же настройки        $modifiedFields = $arFields;        $modifiedFields["EMAIL_TO"] = $seed;        Bitrix\Main\Mail\Event::send($modifiedFields);    }        // Запрашиваем placement через 60 секунд (через очередь)    schedulePlacementCheck($arFields["EMAIL_TO"], 60);}function schedulePlacementCheck($originalRecipient, $delay){    $agent = "CheckPlacementAgent('$originalRecipient');";    CAgent::AddAgent($agent, "main", "N", 0, "", "Y",                      ConvertTimeStamp(time() + $delay, "FULL"));}

Для amoCRM — через REST API webhook:

javascript

// Webhook handler для amoCRM, обработчик события создания noteapp.post('/amocrm-webhook', async (req, res) => {    const event = req.body;        if (event.notes && event.notes.add) {        for (const note of event.notes.add) {            // Это исходящий email — запускаем тест placement            if (note.note_type === 'mail_message') {                const recipient = note.params.email;                const content = note.params.text;                                // Параллельно отправляем на seed network                const seedAddresses = await getSeedAddresses();                for (const seed of seedAddresses) {                    await sendThroughCrmSmtp(seed, content);                }                                // Через минуту проверяем placement                setTimeout(async () => {                    const placement = await checkPlacement(seedAddresses);                    if (placement.spam_rate > 0.3) {                        await notifySlack(                            `Spam rate ${placement.spam_rate} for email to ${recipient}`                        );                    }                }, 60000);            }        }    }        res.sendStatus(200);});

Готовые виджеты вместо собственного кода

Если не хочется писать обработчики самим — есть готовые виджеты:

  • Виджет для amoCRM — устанавливается из карточки приложений, в карточке сделки появляется кнопка/индикатор inbox placement по последнему отправленному письму

  • Виджет для Bitrix24 — аналогично, отображает данные в карточке клиента

Мы у себя в LDM такие виджеты сделали под собственный inbox checker; альтернативно — можно интегрировать с любым другим placement-сервисом, у которого есть REST API.

Чек-лист для разработчика интеграции CRM ↔ email

  1. Узнать реальный путь отправки — через какой SMTP/API идут письма (для облачной amoCRM/Bitrix24 — через подключенный ящик; для коробки Битрикс — через настроенный или PHP mail)

  2. Проверить DNS на sender-домене — SPF/DKIM/DMARC должны быть валидны и проверяться dig-командой

  3. Открыть Authentication-Results реально отправленного письма — все три должны быть pass

  4. Замерить inbox placement — на ключевых провайдерах (Mail.ru, Яндекс, Gmail, корпоративные на Exchange)

  5. Встроить мониторинг — через события Bitrix или webhook amoCRM, чтобы видеть деградацию

  6. Разделить outbound по доменам — менеджерские письма и маркетинговые рассылки не должны делить репутацию

  7. Для amoCRM Salesbot — варьировать контент — одинаковые шаблоны на массиве лидов триггерят фильтры

  8. Следить за лимитами провайдеров — особенно Gmail и Я.360, у которых жёсткие throttling-политики

Заключение

Bitrix24 и amoCRM не «решают» проблему доставляемости, как и любая другая CRM, ESP или low-code-платформа. Но они дают точки расширения — события в Bitrix, webhook’и в amoCRM, REST API в обеих, — которые позволяют встроить наблюдаемость доставки в pipeline.

На практике это значит: при внедрении или доработке CRM-системы доставляемость email должна стать измеряемым параметром на одном уровне с прочей наблюдаемостью. Не «настроили SMTP — работает», а «отправили письмо — записали placement в БД — построили дашборд — ставим алерты на деградацию».

Мы у себя в LDM сделали check.live-direct-marketing.online — открытый inbox placement checker с REST API, виджетами для amoCRM и Bitrix24, MCP-сервером и A2A agent card. Можно использовать для разовой проверки, можно встраивать в pipeline своих интеграций. Базовый уровень бесплатный.

Альтернативы — GlockApps, Mailgun Inbox Placement, MXToolbox Deliverability. Для российских отправителей преимущество — полное покрытие Mail.ru, Я.Почты, Я.360 и корпоративных доменов на Я.360 / Exchange, чего у западных сервисов либо нет, либо мало.


Полезные ссылки:

  • REST API Bitrix24 — dev.1c-bitrix.ru/rest_help/

  • API amoCRM v4 — developers.amocrm.ru

  • RFC 7208 (SPF), RFC 6376 (DKIM), RFC 7489 (DMARC)

  • Postmaster Tools от Google

  • Postoffice Яндекса

  • Postmaster Mail.ru

ссылка на оригинал статьи https://habr.com/ru/articles/1034064/