Приложение на no-code работает, а письма не доходят: разбор по платформам — ELMA365, Bubble, AppMaster, Albato, Make и другим

Команда собрала бизнес-процесс на ELMA365. Согласования ходят, задачи назначаются, отчёты собираются. Через две недели приходит сотрудник: «Я не получил уведомление, что мою заявку отклонили». Заглядывают в логи платформы — письмо отправлено, статус «успешно». В почте у сотрудника — пусто. Через час он вспоминает заглянуть в спам — письмо там.

Или другой сценарий. Стартап построил MVP на Bubble за месяц, подключил Stripe, регистрацию, личный кабинет. Запустились — приходят первые клиенты — половина пишет в поддержку: «Я не получаю ссылку для восстановления пароля». В Bubble всё зелёное: workflow отработал, action «Send email» выполнен.

No-code и low-code решают огромную часть инженерной работы: формы, базы данных, бизнес-логика, интеграции. Но деливерабилити email они не решают — и часто даже усугубляют проблему. Потому что отправку абстрагируют, а владелец платформы — нетехнический человек, и у него нет точки контроля над тем, доходят ли его письма.

Платформы устроены по-разному, и проблема в каждой случае выглядит немного иначе. Разберу четыре основные категории.

Это корпоративный сегмент: системы согласований, документооборота, управления процессами. Письма здесь — критичный элемент: уведомления о задачах, согласованиях, дедлайнах, эскалациях.

Отправка обычно идёт через:

Проблема: SMTP настраивает админ платформы один раз при внедрении. Дальше — ноль контроля. Если корпоративный домен имеет плохую репутацию у Mail.ru или Яндекса (что бывает у компаний, ведущих массовые рассылки с того же домена), системные уведомления ELMA365 или Creatio будут регулярно ложиться в спам. Сотрудники привыкают «всегда смотреть в спам» — это нормализация дисфункции, при которой процесс формально работает, а на практике постоянно тормозит.

Особый случай — внешние уведомления, которые BPM шлёт клиентам или контрагентам. У них нет настроенного правила «доставать из спама письма от этой компании», и значительная часть писем просто пропадает.

Здесь обычно стандартная связка: внутри платформы есть action «Send email», который под капотом шлёт через одного из транзакционных провайдеров. Bubble по умолчанию — через свой собственный, AppMaster — через сконфигурированный SMTP. Адрес отправителя — либо noreply@yourappname.bubbleapps.io, либо тот, что вы указали.

Проблема стандартная: домен отправителя не аутентифицирован — нет SPF, нет DKIM, нет DMARC. Если использовать дефолтный поддомен платформы — это сразу подозрительный сигнал для Mail.ru. Если использовать свой домен, но не настроить аутентификацию — это ещё хуже, потому что у провайдера срабатывает несоответствие между заявленным доменом и реальной инфраструктурой отправки.

Критичная зона для no-code-приложений — транзакционные письма безопасности: код подтверждения регистрации, ссылка восстановления пароля, OTP. Если они не доходят — пользователь физически не может пользоваться продуктом. И в отличие от подтверждения заказа, тут даже нельзя «попросить позвонить менеджеру».

Это «клей»: они дёргают триггеры в одних системах и запускают действия в других. Email в таких системах обычно — одно из действий: «Send email», «Gmail: Create draft» и так далее.

Здесь палитра шире:

Типичная ошибка — настроить автоматизацию в Albato или Make: «когда приходит лид → отправить ему письмо», и шесть месяцев не замечать, что 40% писем падает в спам. Albato покажет вам зелёный статус «выполнено» — потому что с её точки зрения письмо отправлено успешно. Что произошло у получателя, она не знает.

По дефолту шлют через инфраструктуру платформы. Без настройки SPF и DKIM на вашем домене — провайдеры режут. Подробно про Tilda был отдельный разбор; здесь логика та же для всех конструкторов.

Любая no-code/low-code платформа — будь то ELMA365, Bubble или Albato — может показывать только две вещи в отношении email:

И всё. Куда оно легло у клиента в ящике — спам, входящие, промоакции, карантин — платформа не знает и узнать не может. Это не ограничение конкретной платформы, это устройство email: получающий сервер не сообщает наружу, куда он положил письмо.

Поэтому когда вы видите в Bubble «Workflow completed successfully» или в ELMA365 «Уведомление отправлено» — это не означает, что человек увидел письмо. Это означает только то, что технический акт передачи произошёл.

Платформа может быть международной (Bubble, Make), а клиенты — на Mail.ru и Яндексе. Это сразу самая суровая среда фильтрации email в мире:

Если ваше приложение или процесс на ELMA365/Bubble/AppMaster обслуживает российскую аудиторию — деливерабилити критична, и проверять её регулярно нужно отдельно.

В каждом сегменте боль разная.

Low-code BPM (ELMA365, Creatio, BPMSoft):

No-code SaaS-приложения (Bubble, AppMaster, Adalo):

Интеграторы (Albato, Make, n8n):

Способ называется inbox placement testing — тест попадания в инбокс. Принцип:

check.live-direct-marketing.online — бесплатный inbox placement checker. Подходит для любой платформы, которая может отправить email на указанный адрес. То есть подходит вообще для всего — от ELMA365 до Make и от Bubble до самописного бэкенда.

Регистрируетесь, получаете уникальные адреса сид-сети, отправляете на них письма так же, как отправляли бы клиентам или сотрудникам, через секунды видите карту попадания и диагноз.

Разовая проверка решает «вижу сейчас». Но провайдеры регулярно меняют политики, а в вашей платформе меняются шаблоны, отправители, SMTP. Нужен постоянный мониторинг — чтобы видеть, если завтра ваши письма начали падать в спам, не от первого недовольного клиента, а до того, как до клиентов вообще что-то не дошло.

Готовые модули, которые подключаются без программирования:

Подключение через стандартные no-code-механизмы — за 10–15 минут без кода:

Принцип везде одинаковый: после события «письмо отправлено» в вашей платформе автоматически делается тестовый прогон на сид-сеть, и если что-то ушло в спам — приходит алерт. Не нужно ждать обращения от пользователя или сотрудника, который чего-то не получил.

Если вашей платформы нет в списке, но у неё есть возможность сделать HTTP-запрос или webhook — она подключается. У всех современных no-code и low-code платформ такая возможность есть по умолчанию.

No-code и low-code решают самую большую инженерную проблему — создание продукта без команды разработчиков. Но они не решают деливерабилити email, и сама абстракция платформы создаёт иллюзию «всё работает», когда на деле часть писем системно не доходит.

Это не значит, что нужно бросать no-code и нанимать разработчиков. Это значит, что доставляемость email — отдельный слой, который требует отдельного контроля. Так же, как мониторинг аптайма сайта или скорости загрузки — никто не считает, что само устроится.

Проверить, как сейчас доходят письма из вашего ELMA365, Bubble, Albato или любой другой платформы, можно бесплатно: check.live-direct-marketing.online.