Как спроектировать массовую email-рассылку для малого и среднего бизнеса без привязки к конкретному сервису

«Хотим рассылать десятки–сотни информационных писем с уже имеющимся доменом и сайтом, не подключая ещё один специализированный сервис рассылок». Практичный ответ — не отправка всем сразу через Bcc, а небольшая инфраструктура рассылки с индивидуальной отправкой по каждому адресату, учётом подписок, отпиской и настроенными SPF / DKIM / DMARC.

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

Кроме того, статья исходит из писем тем, с кем уже есть отношения или согласие: существующим клиентам, участникам, тем, кто запросил материалы, подписчикам рассылки. Речь не о сборе публичных адресов и рассылке без разбора. У рекламных писем есть правовые предпосылки, да и по качеству доставки такой подход долго не живёт.¹²

Ниже — систематизация по открытым японским материалам о законе о специализированной электронной почте и по рекомендациям отправителям от Google / Yahoo / Outlook, доступным на апрель 2026 года.¹²³⁴⁵

Для кого эта статья и какие допущения

Аббревиатуры, которые встречаются дальше

Слова, которые со 2-й главы идут без пояснения, собраны здесь.

1. Коротко о главном

Практичная схема внешней массовой рассылки для малого и среднего бизнеса обычно сводится к четырём пунктам.

1. Отправлять индивидуально по каждому адресату Не собирать всех в Bcc, а строить очередь из расчёта, что письма уходят по одному.
2. Держать состояние подписки у себя Явно вести состояния вроде active, unsubscribed, bounced в своей БД или CSV.
3. Принимать отписки автоматически Не строить процесс, где «пожалуйста, больше не пишите» обрабатывают вручную. В тело письма ставят видимую ссылку и, по возможности, заголовок List-Unsubscribe.³⁴⁵
4. Аутентифицировать домен отправителя Настроить SPF / DKIM / DMARC, обратную PTR-запись, TLS. Письмо может уйти и без этого, но доходить будет хуже.³⁴⁵

Иными словами, это не вопрос работы в почтовом клиенте, а вопрос инфраструктуры рассылки.

Если требование «хотим отправить всем сразу» понимать как «набить много адресов в To / Cc / Bcc», схема разваливается. На деле нужна механика, которая отвечает на такие вопросы:

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

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 22, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Почему недостаточно отправить всем сразу через Bcc

Во внешней массовой рассылке Bcc тяжело переносится именно потому, что при кажущейся простоте не даёт никакой операционной основы.

Особенно опасно то, что письмо отправить можно, поэтому кажется, будто система уже есть. На деле нет ни подавления отписавшихся, ни учёта bounce, ни записи согласий, ни логов отправки — и ручная схема ломается, как только адресатов становится чуть больше.

Bcc не зло само по себе. Для внутренней переписки, совсем небольшого сообщения закрытому кругу участников или разовой рассылки заинтересованным лицам это ещё может сработать. Но как основа системы, которая регулярно пишет внешним клиентам и потенциальным клиентам, это слабо.

3. Что на практике значит «не использовать конкретный сервис»

Здесь легко ошибиться: «не использовать конкретный сервис» — это не «делать всё руками».

На практике, если эти три вещи остаются у вас, привязки к поставщику можно в значительной мере избежать.

3.1 Что должно быть у вас

• Данные подписчиков
  • адрес email
  • дата и время согласия
  • источник согласия
  • категория рассылки
  • состояние отписки
• Правила рассылки
  • что кому отправлять
  • с какой скоростью
  • как учитывать bounce и отписки
• Идентичность отправителя
  • домен отправителя
  • SPF / DKIM / DMARC
  • адрес, на который приходят ответы
  • URL отписки

3.2 Что можно заменить

• фактический SMTP-релей, через который уходят письма
• способ реализации админ-панели
• где реализована очередь отправки
• где хранятся логи

То есть суть «не пользоваться сервисом» в том, чтобы не отдавать правила и состояние рассылки целиком на сторону поставщика.

• список адресатов лежит в вашей БД
• URL отписки находится на вашем домене
• шаблоны темы и текста — ваши
• заменить потом можно только исходящий SMTP

В такой схеме сначала можно опереться на уже имеющуюся почтовую инфраструктуру, а позже перейти на другой способ отправки.

4. Практичная схема для малого и среднего бизнеса

4.1 Минимальный набор частей

На десятках–сотнях писем за раз сразу городить большую систему не нужно. Но стабильнее держать раздельно хотя бы следующее.

1. Таблица подписчиков
2. Таблица подавления
   • отписки
   • hard bounce
   • жалобы
3. Шаблоны рассылки
   • тема
   • текст (HTML / text)
   • категория рассылки
4. Очередь рассылки
   • состояние по каждому адресату
   • результат отправки
   • число повторных попыток
5. SMTP-релей
   • существующая почтовая инфраструктура
   • или свой сервер
6. Логи
   • когда и кому отправили
   • успех / неудача
   • учёт отписки / bounce

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

4.2 Поля таблицы адресатов

Минимальный набор примерно такой.

Даже если исходный мастер — Excel или уже существующая клиентская база, до этого уровня данные лучше разделить. Особенно важно, чтобы сведения о подавлении всегда имели приоритет.

Например: адрес человека всё ещё есть в базе продаж, но в таблице подавления стоит unsubscribed — писать нельзя. Без этого правила после отписки адрес снова попадёт в рассылку по другому каналу, и это уже инцидент.

4.3 Схема

flowchart LR
    A[Сайт / форма подписки] --> B[Таблица подписчиков]
    A2[Существующая клиентская база / база участников] --> B

    C[Шаблоны рассылки<br/>тема / HTML / text] --> D[Очередь рассылки]
    B --> D
    E[Таблица подавления<br/>отписка / bounce / complaint] --> D

    D --> F[SMTP-релей<br/>существующая почтовая инфраструктура или свой релей]
    F --> G[Получатель]

    G --> H[URL отписки]
    G --> I[Ответ]
    G --> J[Bounce / жалобы]

    H --> E
    J --> E
    I --> K[Операционная служба]

    L[SPF / DKIM / DMARC / PTR / TLS] --> F

Если рисунок не отображается, то же самое словами.

• Вход: форма подписки на сайте и существующая клиентская база / база участников. И то и другое собирается в таблицу подписчиков.
• Центр: в очередь рассылки входят три источника: таблица подписчиков (кому писать), таблица подавления (кому писать нельзя) и шаблоны рассылки (тема, HTML, text).
• Исходящий канал: очередь передаёт письма в SMTP-релей (существующая почтовая инфраструктура или свой релей), оттуда они доходят до получателя. К SMTP-релею привязаны настройки SPF / DKIM / DMARC / PTR / TLS.
• Обратный поток: от получателя приходят три вида реакций. URL отписки и bounce / жалобы возвращаются в таблицу подавления; ответы принимает человек в операционной службе.

Главное на этой схеме: способ отправки — не центр. Центр — таблица подписчиков, таблица подавления и очередь рассылки.

SMTP-релей — только исходящий канал. Если это разделено, позже можно сменить способ отправки и не потерять историю отписок и согласий.

4.4 Как выбрать исходящий канал и движок рассылки

Когда «что держать у себя» и «что можно заменить» уже разделены, на практике следующим шагом обычно смотрят вот на это.

1. Какой исходящий канал (SMTP-релей)

Часто можно опереться на уже используемую почтовую инфраструктуру. Для Microsoft 365 официально разобраны способы отправки с устройств и из приложений без почтового ящика: аутентифицированный Client SMTP submission, SMTP relay через коннектор, Direct Send без аутентификации и High Volume Email для большой внутренней рассылки — их сравнивают вместе с лимитами отправки и требованиями к TLS и порту.¹⁰ Если есть свой почтовый сервер (Exchange Server и т. п.), в той же документации советуют принимать релей там — так схему обычно проще собрать.¹⁰

При выборе смотрят примерно на четыре вещи.

2. Писать движок рассылки самим или поставить существующий OSS

Таблицу подписчиков, таблицу подавления, очередь и страницу отписки писать с нуля — работы больше, чем кажется. Есть self-hosted OSS с той же структурой; быстрее сначала проверить, хватает ли его. Например, listmonk — self-hosted рассылка новостей под AGPLv3: списки подписчиков с single / double opt-in, статистика кампаний и учёт bounce, очередь на нескольких SMTP.¹¹

Ориентир такой.

В любом случае принцип один: данные подписчиков, данные подавления и URL отписки остаются у вас. Если это соблюдено, исходящий канал и движок рассылки можно сменить позже.

5. Насколько глубоко строить — по масштабу

5.1 Раз в месяц, десятки адресатов

На таком масштабе минимальной схемы часто хватает.

• шаблон с подстановкой полей, только для рассылки
• индивидуальная отправка по каждому адресату
• URL отписки
• сохранение логов отправки
• настроенные SPF / DKIM / DMARC

Главное здесь — не возвращаться к Bcc только потому, что адресатов мало. Даже при 50 и меньше получателях для регулярной внешней рассылки лучше сразу принять форму индивидуальная отправка + учёт состояния — потом будет проще.

5.2 Несколько раз в месяц, сотни адресатов

На этом этапе стабильности добавляют ещё несколько вещей.

• очередь рассылки
• ограничение скорости отправки
• учёт bounce
• немедленное применение отписок
• отдельный поддомен только для отправки
• процесс согласования
  • тестовая отправка
  • боевая отправка
  • проверка результата

Ещё важно отделить обычную человеческую переписку от рекламных и информационных писем. Google описывает подход с разными From и IP для разных типов сообщений; Yahoo тоже рекомендует не смешивать bulk / marketing с transactional / alerts на одном IP или DKIM-домене.³⁴

Даже простое разделение адресов по назначению уже заметно упорядочивает работу.³⁴⁵

• подтверждение заказа, счета: billing@example.com
• уведомления о сбоях, информация об обслуживании: notice@example.com
• рассылка новостей, объявления: news@example.com

5.3 Когда объём подходит к нескольким тысячам писем в день

На этом этапе «не пользоваться конкретным сервисом» легко превращается в самоцель.

Google для отправителей в Gmail свыше 5000 писем в день явно требует SPF / DKIM / DMARC, согласование домена From, отписку в один клик и другое. Outlook тоже требует SPF / DKIM / DMARC для доменов свыше 5000 писем в день и предупреждает, что письма без этих требований могут уйти в спам или быть отклонены.³⁵

На таком масштабе меняется и предмет эксплуатации.

• репутация IP
• доля жалоб
• доля bounce
• обработка отписок
• как наращивать объём
• мониторинг

Здесь часто оказывается, что специализированный сервис выгоднее.

То есть вывод статьи не «при любом масштабе делать всё самим», а на десятках–сотнях писем за раз как раз уместна небольшая инфраструктура рассылки, где состояние и правила остаются у вас.

6. Что нельзя выкинуть в праве и в качестве доставки

6.1 Согласие

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

И Google, и Yahoo требуют слать только то, чего получатель явно хотел, не использовать купленные списки и не опираться на заранее отмеченный opt-in.³⁴

На практике минимум, который стоит сохранять:

• дата и время согласия
• источник согласия
• на какую рассылку согласились
• поясняющий текст
• экран или формулировка, через которые брали согласие

В законе есть исключение для отправки на деловые адреса, опубликованные на сайте. Но строить инфраструктуру рассылки, опираясь на это исключение, не стоит. По жалобам, доставляемости, репутации и реальному отклику такое решение долго не живёт.²

6.2 Обязательные сведения и отписка

Даже когда пишете согласившимся, у отправителя есть обязанность указать сведения о себе. По разбору Центра консультаций по спаму нужны как минимум следующие данные.²

• имя или наименование отправителя
• адрес email или URL, куда принимают уведомление об отказе от получения
• указание, что от получения можно отказаться
• адрес отправителя
• контакт для жалоб и вопросов

То есть в подвале письма минимально нужно вот что.

Отправитель: ООО «○○»
Отписка: https://example.com/unsubscribe/xxxxx
Если хотите отказаться от получения писем, оформите это по ссылке выше.
Адрес: Токио, ...
Контакты: support@example.com

Крупные принимающие стороны к тому же очень смотрят на то, насколько легко отписаться.

• Google: для массовых отправителей требует one-click unsubscribe³
• Yahoo: требует / рекомендует List-Unsubscribe и ссылку в теле письма, применение в течение 2 дней⁴
• Outlook: рекомендует легко находимую и работающую unsubscribe⁵

Поэтому естественный минимум — видимая ссылка в теле письма и, по возможности, такие заголовки.³⁴

List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe: <https://example.com/unsubscribe/xxxxx>

6.3 Аутентификация и доставляемость

Крупные принимающие стороны уже исходят не из «можно ли отправить», а из «аутентифицирован ли отправитель».

Открытые рекомендации Google требуют следующего.³

• все отправители: SPF или DKIM, PTR (согласование прямой / обратной записи DNS), TLS
• массовые отправители: SPF + DKIM + DMARC, согласование домена From
• низкий spam rate
• для массовых отправителей — one-click unsubscribe

У Yahoo требования такие.⁴

• SPF / DKIM / DMARC
• DMARC alignment
• valid forward / reverse DNS
• unsubscribe
• spam rate ниже 0,3%
• opt-in
• разделение bulk и transactional

Outlook тоже публикует требования для отправителей с большим объёмом.⁵

• SPF pass
• DKIM pass
• DMARC (как минимум p=none, согласованный с SPF или DKIM)
• настоящие From / Reply-To
• unsubscribe
• list hygiene

Минимальный набор эксплуатационных проверок в таблице:

Google советует наращивать объём с малого, к тем, кто хорошо реагирует, ровным темпом. Внезапные всплески и резкое удвоение объёма легко приводят к лимитам и падению reputation.³

7. В каком порядке реализовывать

Если начинать с минимума, реалистичен примерно такой порядок.

1. Разделить типы писем
   • уведомления
   • рассылка новостей
   • приглашения на семинары
   • объявления для существующих клиентов
2. Сделать форму подписки или процесс получения согласия Чтобы согласие можно было взять на сайте вместе с поясняющим текстом. Важно, чтобы из текста было понятно, «что придёт и как часто».⁴
3. Разделить таблицу подписчиков и таблицу подавления Если разделить их сразу, позже можно сменить платформу и не сломать эксплуатацию.
4. Выбрать отдельный домен / поддомен только для отправки Например news.example.com или mail.example.com. Как минимум не смешивать зоны ответственности с повседневными заказами и личными ящиками.³⁴
5. Настроить SPF / DKIM / DMARC / PTR / TLS Если отправляете сами, это первый приоритет. Среду без рабочего обратного DNS в основу рассылки не ставят.³⁴
6. Админ-панель может быть маленькой Нужен не богатый UI, а такие функции:
   • правка темы
   • правка текста
   • тестовая отправка
   • боевая отправка
   • предпросмотр адресатов
   • размер пакета
   • проверка результата
7. Сначала слать малыми объёмами Ограничиться существующими клиентами и подписчиками, которые хорошо реагируют, держать ровный темп. Если проблем нет — расширять аудиторию.³
8. В первую очередь применять отписки и bounce Убедиться, что это работает, раньше, чем смотреть открываемость.

В таком порядке вы приходите не к состоянию «в принципе можем отправить», а к состоянию «можем продолжать без инцидентов».

7.1 Какие слова искать дальше

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

Первым делом берите настройку аутентификации. Пока её нет, сколько ни аккуратничайте дальше — письма не дойдут.

Если в пересмотр входят форма подписки, текст согласия и страница отписки, это удобнее делать вместе с разработкой сайта. Если же нужно связать существующую клиентскую базу, внутренние системы или Windows-инструменты, безопаснее начать с разделения зон ответственности в рамках технической консультации и ревью проектирования.

8. Частые ошибки

Типично вот что.

• Обычная человеческая переписка и рекламные / информационные письма идут от одного и того же отправителя
• Согласие ведут только заметкой в free text
• Отписку обрабатывают вручную по ответу на письмо
• Старый список визиток загружают целиком
• Внезапно начинают слать прошлым максимальным объёмом
• В уведомления подмешивают рекламный текст
• Результат отправки смотрят только по тому, что «API отправки вернул успех»
• Таблица подавления слабее существующей клиентской базы

Последний пункт особенно легко приводит к инциденту.

Адрес остаётся в Excel отдела продаж. Но человек уже отписался от рассылки новостей. Если нет правила, что сведения о подавлении всегда побеждают, письмо снова и снова уйдёт по другому каналу.

9. Итог

Если малому и среднему бизнесу нужно писать достаточно большому числу адресатов без конкретного сервиса, вопрос не в том, «какую кнопку нажать».

По-настоящему нужны пять вещей.

• не отправка всем сразу через Bcc, а индивидуальная отправка по каждому адресату
• таблица подписчиков и таблица подавления
• путь, который автоматически принимает отписки
• SPF / DKIM / DMARC / PTR / TLS
• эксплуатация, которая разделяет уведомления и рекламу

В конечном счёте сначала нужны правила отправки, а не сам способ отправки.

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

Похожие статьи

• Три места, которые стоит исправить в первую очередь на сайте, куда не приходят обращения
• Как связать статьи и страницы услуг — основы внутренних ссылок

Справочные материалы

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

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

Вопросы, которые часто возникают при консультациях по теме статьи.

Почему нельзя просто разослать информационные письма всем сразу через Bcc?

Как основа системы, которая регулярно пишет внешним клиентам и потенциальным клиентам, это слишком слабо. Через Bcc письмо отправить можно, но операционной основы нет: отписки не отслеживаются, bounce не обрабатываются, согласие не фиксируется, скорость отправки не регулируется, всё держится на одном сотруднике. Как только адресатов становится чуть больше, ручная схема ломается. Для внутренней переписки или разового сообщения узкому кругу это ещё может сработать. Для регулярной внешней рассылки нужны индивидуальная отправка по каждому адресату и учёт состояния.

Нужно ли согласие, чтобы отправлять рекламные и информационные письма?

Для рекламных писем, как правило, нужно предварительное согласие. Японский Центр консультаций по спаму тоже исходит из того, что рекламные письма без предварительного согласия в принципе нельзя отправлять. И Google, и Yahoo требуют слать только то, чего получатель явно хотел, и не использовать купленные списки. На практике стоит сохранять дату и время согласия, источник, на какую рассылку согласились, и поясняющий текст. Для деловых адресов, опубликованных на сайте, в законе есть исключение, но строить на нём инфраструктуру рассылки не стоит.

Что минимально нужно, чтобы письма не уходили в спам?

Аутентификация домена отправителя. Конкретно: SPF/DKIM/DMARC, среда отправки с рабочей обратной PTR-записью, TLS, реально существующие From/Reply-To, на которые приходят ответы, ссылка отписки в теле письма и заголовок List-Unsubscribe, список только из opt-in адресов. Google для отправителей, которые шлют в Gmail больше 5000 писем в день, требует SPF + DKIM + DMARC и отписку в один клик; Yahoo — spam rate ниже 0,3%. Когда наращиваете объём, начинайте с малого и держите ровный темп.

Можно ли построить инфраструктуру рассылки самим, без сервиса email-маркетинга?

На десятках–сотнях писем за раз — вполне. Суть в том, чтобы данные подписчиков, правила рассылки и идентичность отправителя (домен, аутентификация, URL отписки) оставались у вас, а заменить можно было только исходящий канал — SMTP-релей. Центр не SMTP, а таблица подписчиков, таблица подавления и очередь рассылки. Когда объём подходит к нескольким тысячам писем в день, на первый план выходят репутация IP и доля жалоб, и специализированный сервис часто оказывается выгоднее.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.