НКО: рассылка на 20 000 подписчиков — своя вместо 15 000 ₽ в месяц сервису

MAATRIX

Ежемесячная рассылка для доноров, волонтёров и подопечных — это часто самая заметная статья ИТ-расходов в небольшой НКО, и она же самая обидная: деньги, которые могли пойти на программную деятельность, уходят на сервис, который просто отправляет письма. Если у вас база в районе 20 000 подписчиков и счёт на 15 000 ₽ в месяц, есть рабочая альтернатива — развернуть открытую платформу рассылок на собственном сервере. Это не про «бесплатно», это про контроль над расходами и данными, и ниже — честный разбор, что это будет стоить и стоит ли оно возни именно для вашей организации.

Что НКО реально платит за рассылку и куда уходят деньги

Когда сервис email-рассылок берёт 15 000 ₽ в месяц за базу в 20 000 адресов, вы платите не за «отправку писем» как таковую — отправить письмо дёшево. Вы платите за набор вещей, упакованных вместе:

• инфраструктуру отправки с уже наработанной репутацией IP-адресов, чтобы письма не улетали в спам;
• конструктор писем и шаблоны, которые не надо верстать самим;
• сегментацию базы, автоворонки, A/B-тесты — то, что нужно коммерческому маркетингу и часто избыточно для НКО;
• поддержку, SLA, готовую интеграцию с CRM и формами подписки;
• юридический комплаенс по обработке персональных данных на стороне сервиса.

Для НКО с ограниченным бюджетом значительная часть этого набора — переплата. Вам обычно не нужны сложные автоворонки и A/B-тестирование десятков вариантов темы письма. Нужно: собрать базу, разбить её на 2-3 сегмента (доноры, волонтёры, подписчики новостей), один раз в 2-4 недели отправить письмо, которое не попадёт в спам, и видеть статистику открытий. Это тот функционал, который закрывают открытые платформы рассылок за минимальную цену инфраструктуры.

Отдельная статья расходов, о которой часто забывают, — это то, что тариф сервиса растёт вместе с базой не линейно, а скачками по порогам (условно: до 10 000 адресов один тариф, до 25 000 — следующий). Если ваша база в 20 000 подписчиков близка к очередному порогу, через полгода-год счёт может вырасти ещё сильнее, а собственная инфраструктура от размера базы в разумных пределах почти не зависит.

Своя рассылка: из чего она состоит технически

Чтобы заменить внешний сервис, нужно закрыть три задачи, которые сейчас решает подписка одним пакетом:

1. Управление базой и письмами — где хранится список подписчиков, кто на что подписан, кто отписался, как выглядит письмо. Это берёт на себя open-source платформа рассылок — практически стандартом де-факто здесь стал Listmonk: лёгкое Go-приложение с PostgreSQL под капотом, веб-интерфейсом для создания кампаний, сегментации по спискам и статистикой открытий/переходов.
2. Отправка писем — сам факт передачи письма получателю. Технически это SMTP: либо свой почтовый сервер на том же VPS (Postfix), либо отправка через SMTP-релей стороннего провайдера. Для НКО с базой в 20 000 адресов начинать разумнее с собственного Postfix — это управляемо и не создаёт лишней зависимости, но требует внимания к репутации IP (об этом ниже).
3. Доставляемость — чтобы письма не попадали в спам: правильно настроенные SPF, DKIM, DMARC записи, обратная DNS-запись (PTR) на IP сервера, «прогрев» нового IP постепенным наращиванием объёма отправки.

Всё это укладывается в один VPS среднего тарифа. Listmonk — лёгкое приложение: авторы проекта прямо говорят, что оно рассчитано на работу на скромном железе, и для базы в 20 000 адресов с рассылкой раз в 2-4 недели хватит конфигурации в 1-2 vCPU и 2-4 ГБ RAM с запасом — подробный разбор требований по памяти есть в статье «Сколько RAM нужно для Listmonk». Диска на PostgreSQL и логи писем для такой базы нужно немного — 20-40 ГБ с запасом более чем достаточно на годы вперёд.

Разворачиваем Listmonk на сервере: пошагово

Самый предсказуемый способ поднять Listmonk — через Docker Compose, там же поднимается PostgreSQL как зависимость. Общая последовательность действий на свежем VPS (Ubuntu 24.04):

# обновляем систему и ставим Docker
sudo apt update && sudo apt upgrade -y
curl -fsSL https://get.docker.com | sudo sh
sudo systemctl enable --now docker

# создаём рабочую директорию
mkdir -p /opt/listmonk && cd /opt/listmonk

Дальше нужен файл docker-compose.yml с сервисами db (PostgreSQL) и listmonk, и файл config.toml с настройками подключения к базе и SMTP. Структура файла простая: контейнер с базой, контейнер с приложением, том для данных PostgreSQL, проброс порта 9000 наружу (лучше через nginx с TLS, а не напрямую).

После первого запуска:

docker compose up -d
# инициализация схемы базы данных при первом старте
docker compose run --rm listmonk ./listmonk --install

Дальше — вход в веб-интерфейс, создание списков (например, «Доноры», «Волонтёры», «Новости»), импорт текущей базы подписчиков из CSV-экспорта прежнего сервиса и настройка SMTP-подключения для отправки. На этом этапе организации иногда сталкиваются с типовыми проблемами конфигурации — от неверных прав на том с данными до путаницы в переменных окружения, — но это стандартные вещи, которые решаются проверкой логов контейнера.

Важный практический момент: перед тем как переносить всю базу разом, отправьте тестовую кампанию на 100-200 адресов из своего же списка (например, сотрудникам и активным волонтёрам, которые точно откроют письмо и не пожалуются). Это позволит проверить вёрстку, отписку и то, что письмо доходит до входящих, а не в спам, — прежде чем рисковать репутацией на всей базе.

Репутация IP, SPF/DKIM/DMARC — чтобы письма не улетали в спам

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

Три вещи обязательны с первого дня:

• SPF — запись в DNS домена, которая говорит, что ваш сервер имеет право отправлять письма от имени домена;
• DKIM — криптографическая подпись письма, подтверждающая, что оно не подделано по пути;
• DMARC — политика, которая говорит почтовым системам получателя, что делать с письмами, не прошедшими SPF/DKIM.

Пошаговая настройка всех трёх записей разобрана в статье «Как установить и настроить SPF, DKIM и DMARC на VPS» — рекомендую пройти её целиком до первой массовой рассылки, а не после.

Дальше — «прогрев» IP. Новый IP-адрес без истории отправки почтовые системы (особенно крупные вроде Gmail и Mail.ru) поначалу воспринимают настороженно. Практический подход: первые рассылки после переноса делать не на всю базу сразу, а порциями — условно, первую неделю 1000-2000 адресов в день, постепенно наращивая объём до полной базы за 2-3 недели. Это ориентировочная схема, а не точный рецепт: у каждого почтового провайдера свои внутренние алгоритмы, и универсальной цифры не существует — ориентируйтесь на статистику открытий и отказов (bounce rate) в самом Listmonk.

Если несмотря на всё этому IP всё равно не доверяют или он случайно попал в чёрный список (например, из-за предыдущего владельца), это решаемая, но отдельная работа — она описана в статье «IP попал в чёрные списки: восстановление репутации».

Иллюстративный расчёт: своя рассылка против подписки на сервис

Ниже — намеренно упрощённая иллюстративная модель, а не готовая смета. Точные цифры зависят от вашего тарифа сервера, объёма рассылок и того, кто будет настраивать систему (штатный админ, волонтёр с техническим бэкграundом или подрядчик на почасовой оплате). Считайте это отправной точкой для собственного расчёта, а не готовым ответом.

Год со сторонним сервисом, при заданных в условии 15 000 ₽/мес:

15 000 ₽ × 12 месяцев = 180 000 ₽ в год.

Год со своей инфраструктурой (иллюстративные допущения):

Даже если оценить единоразовую настройку в условные 15 000-30 000 ₽ (наняв подрядчика, если своих рук не хватает), а аренду сервера — в сумму на порядок ниже 15 000 ₽/мес, экономия в первый же год обычно превышает стоимость перехода, а начиная со второго года почти вся сумма подписки — это чистая экономия для программной деятельности организации. Это направление расчёта, а не точная цифра: у организации с базой ровно в заявленном размере и типичной частотой рассылки раз в 2-4 недели порядок экономии именно такой, но финальную сумму стоит посчитать на своих реальных условиях.

Отдельно стоит учесть нефинансовую сторону: перенос базы и настройка репутации IP занимают время и требуют, чтобы кто-то в организации (или подрядчик) взял на себя ответственность за доставляемость. Если в НКО нет вообще никого с техническими навыками и нет бюджета на разовый найм — переход может оказаться дороже по факту, чем по цифрам в таблице, за счёт рисков и потраченного времени волонтёров. Оцените это честно до того, как отказываться от текущего сервиса.

Юридические нюансы для НКО: 152-ФЗ, согласие, отписка

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

Что стоит проверить и настроить с первого дня:

• Согласие на рассылку. У каждого адреса в базе должно быть документируемое основание — форма подписки с явным согласием, либо статус донора/волонтёра, зафиксированный в момент сбора данных. Listmonk хранит метку двойного подтверждения подписки (double opt-in), если вы её включите, — это полезная страховка на случай вопросов о законности рассылки.
• Простая и рабочая отписка. Ссылка отписки должна быть в каждом письме и реально работать без лишних шагов — это требование и закона, и здравого смысла: жалобы на спам от людей, которые не смогли отписаться, бьют по репутации IP сильнее, чем сама отписка.
• Хранение и удаление данных. Определите внутри организации, кто отвечает за базу подписчиков, как долго хранятся адреса неактивных подписчиков и по какому запросу данные удаляются.
• Резервное копирование базы. База подписчиков — это актив организации, который нельзя потерять; настройте регулярный бэкап тома PostgreSQL на отдельное хранилище, а не полагайтесь на единственную копию на том же сервере.

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

Частые вопросы