Подключение сервиса рассылок к сайту: пошаговый гайд

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

Минимальная рабочая схема состоит из пяти компонентов: домен отправителя, DNS-аутентификация, транспорт передачи сообщений, механизм подтверждения подписки и интеграция с CMS или backend сайта. Если исключить хотя бы один компонент, система будет работать нестабильно. Письма начнут попадать в спам, API-ключ окажется в клиентском коде, а база подписчиков будет заполняться невалидными адресами.

Ниже приведён порядок подключения без привязки к конкретному SaaS-провайдеру. Названия пунктов панели управления могут различаться. Принцип остаётся одинаковым.

1. Подготовьте домен отправителя

Не используйте адрес бесплатного почтового ящика как основной отправитель массовых писем. Для сервиса рассылок нужен собственный домен, например example.ru, и отдельный адрес отправителя — news@example.ru или support@example.ru.

Домен должен быть доступен для управления DNS-зоной. Это может быть панель регистратора, DNS-хостинг, Cloudflare или инфраструктура другого провайдера. Доступ к панели сервиса рассылок сам по себе недостаточен. Записи SPF, DKIM и DMARC добавляются именно в DNS-зону домена.

До начала интеграции зафиксируйте:

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

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

Рациональная схема выглядит так:

• example.ru — корпоративная почта;
• mail.example.ru — маркетинговые рассылки;
• tx.example.ru — транзакционные сообщения;
• отдельные DKIM-селекторы для каждого сервиса.

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

2. Настройте SPF, DKIM и DMARC

Email-аутентификация отправителя выполняется через TXT-записи DNS. Каждая запись отвечает за отдельный участок проверки.

SPF: список разрешённых отправителей

SPF указывает, какие IP-адреса или серверы имеют право отправлять письма от имени домена. Запись размещается на основном домене и выглядит так: example.ru. TXT "v=spf1 include:provider.example ~all".

Фактическое значение include: выдаёт сервис рассылок. Его нельзя заменять произвольным доменом. Если письма отправляются из нескольких систем, все разрешённые источники должны быть учтены в одной SPF-записи.

Например, домен может использовать сервис рассылок и отдельную платформу транзакционных уведомлений: example.ru. TXT "v=spf1 include:newsletter.example include:transactional.example ~all".

Не создавайте две независимые SPF-записи для одного домена — например, отдельно v=spf1 include:newsletter.example ~all и v=spf1 include:transactional.example ~all. Такая конфигурация приводит к ошибке проверки SPF, потому что DNS допускает только одну политику на домен.

Параметр в конце записи определяет реакцию на источник, не прошедший проверку:

• ~all — мягкий отказ;
• -all — жёсткий отказ;
• ?all — нейтральный результат;
• +all — разрешение всех источников.

+all фактически обнуляет смысл SPF. Не используйте его. Переход к -all выполняйте после инвентаризации всех систем, которые отправляют письма от имени домена. Иначе часть легитимной почты будет отклоняться.

SPF проверяет не отображаемое поле отправителя, а домен SMTP-конверта. Поэтому одна только корректная SPF-запись не гарантирует прохождение DMARC.

DKIM: криптографическая подпись

DKIM добавляет к письму цифровую подпись. Получающий сервер извлекает публичный ключ из DNS и проверяет, что сообщение не было изменено, а подпись создана разрешённым отправителем.

Сервис рассылок обычно выдаёт:

• имя селектора;
• имя DNS-записи;
• значение публичного ключа;
• параметры подписи;
• иногда CNAME-запись вместо TXT.

Типовая TXT-запись выглядит так: selector1._domainkey.example.ru. TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY_BASE64".

В записи должны присутствовать:

• v=DKIM1 — версия DKIM;
• k=rsa — тип ключа;
• p= — публичный ключ в формате base64.

Не переносите ключ вручную с изменением символов. Не добавляйте пробелы внутрь значения p=. DNS-панели могут автоматически разбивать длинную TXT-запись на несколько фрагментов. Это допустимо, если итоговое значение для DNS-клиента остаётся единым.

Частая ошибка — публикация ключа не на том селекторе. Если сервис подписывает письма селектором s1, запись s2._domainkey не поможет. Имя селектора должно совпадать с параметром s=, а домен подписи — с параметром d= в заголовке DKIM-Signature.

Если сервис предлагает CNAME, не преобразуйте его в TXT без необходимости. Следуйте типу записи, который выдал провайдер. В противном случае DNS будет содержать технически корректное, но бесполезное значение.

DMARC: политика обработки ошибок

DMARC связывает результаты SPF и DKIM с доменом в поле From. Запись размещается на поддомене _dmarc и выглядит так: _dmarc.example.ru. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.ru".

Основные политики:

• p=none — только наблюдение;
• p=quarantine — подозрительные сообщения помещаются в карантин, обычно в спам;
• p=reject — сообщения, не прошедшие проверку, отклоняются.

Начинайте с p=none. Это не защита от подделки в строгом смысле, а режим сбора информации. Он позволяет выявить легитимные источники отправки и ошибки выравнивания доменов.

После анализа отчётов переходите к p=quarantine, затем при подтверждённой корректности конфигурации — к p=reject.

SPF разрешает источник. DKIM доказывает целостность. DMARC проверяет согласованность этих механизмов с доменом отправителя.

Минимальный контрольный набор DNS:

Не рассчитывайте, что SPF и DKIM автоматически обеспечат доставку во входящие. На результат также влияют репутация домена, репутация IP, содержание сообщений, жалобы пользователей, корректность списков и поведение получателей.

3. Выберите способ передачи данных

Сервис рассылок подключается к сайту тремя основными способами:

1. API-интеграция.

2. SMTP.

3. Виджет, плагин или встроенная форма.

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

API-интеграция

API выбирайте, если сайт должен передавать в сервис рассылок дополнительные поля:

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

Через API можно создавать контакт, добавлять его в список, назначать теги, запускать автоматизацию и получать результат операции. Это предпочтительный вариант для интернет-магазина, личного кабинета, CRM и кастомного backend.

Общий алгоритм:

1. Создайте в сервисе отдельный API-ключ.

2. Ограничьте его права, если платформа поддерживает scopes.

3. Сохраните ключ в переменных окружения или секрет-хранилище.

4. Передавайте запросы только с backend.

5. Проверяйте HTTP-код и тело ответа.

6. Логируйте идентификатор операции без записи полного секрета.

7. Настройте повтор запроса только для временных ошибок.

8. Исключите повторную постановку одного контакта в очередь.

Не помещайте API-ключ в JavaScript-код формы. Код браузера виден посетителю. Такой ключ будет извлечён через DevTools, логи прокси или кэш. После утечки ключ необходимо отозвать и выпустить новый.

Типовая логика backend:

• пользователь отправляет форму;
• сервер проверяет CSRF-токен;
• сервер нормализует адрес;
• сервер применяет rate limit;
• сервер вызывает API провайдера;
• сервис создаёт контакт со статусом ожидания подтверждения;
• пользователь получает письмо Double Opt-In;
• после перехода по ссылке контакт становится активным.

Не передавайте в API «сырые» поля формы без валидации. Ограничьте длину имени, удалите управляющие символы, нормализуйте email и запретите произвольную подстановку списка или сегмента через пользовательский параметр.

SMTP-интеграция

SMTP нужен, когда сайт отправляет сообщения через почтовый транспорт, но управление подписчиками выполняется отдельно. Это распространённая схема для CMS, backend-приложений и систем, где требуется заменить локальную отправку PHP или системный MTA.

Используйте аутентифицированную отправку. Незащищённый SMTP на порту 25 не подходит для передачи клиентских сообщений в сервис рассылок.

Параметры зависят от провайдера, но транспортная модель стандартна:

• порт 25 — обмен между почтовыми серверами SMTP;
• порт 587 — передача от клиента к серверу с использованием STARTTLS;
• порт 465 — передача через защищённое SSL/TLS-соединение.

Для приложения обычно выбирают порт 587 с STARTTLS или 465 с TLS. Не включайте одновременно режим implicit TLS и STARTTLS. Это разные варианты установления защищённого соединения.

Проверьте:

• hostname SMTP-сервера;
• порт;
• тип шифрования;
• логин;
• пароль или токен;
• адрес отправителя;
• домен обратного пути;
• тайм-аут подключения;
• обработку кодов ответа SMTP.

Порт 25 часто ограничивается хостинг-провайдерами. Это ожидаемая мера против спама. Не пытайтесь обходить ограничение переводом приложения на незащищённый сервер. Используйте порт, рекомендованный сервисом, и корректную TLS-конфигурацию.

SMTP не заменяет систему подписок. Он передаёт письмо. Он не решает задачи сегментации, подтверждения адреса и удаления неактивных контактов, если эти функции не реализованы отдельно.

4. Реализуйте Double Opt-In

Форма, которая сразу добавляет адрес в активную базу, уязвима по конструкции. Любой пользователь может указать чужой email. Бот может отправить тысячи запросов. В базу попадут одноразовые адреса, спам-ловушки и адреса людей, которые не давали согласия.

Double Opt-In разделяет подписку на два действия:

1. Пользователь отправляет форму.

2. Пользователь подтверждает адрес переходом по ссылке из письма.

До второго действия адрес должен иметь статус ожидания. Не отправляйте на него регулярную маркетинговую рассылку.

Правильная последовательность:

1. Примите POST-запрос от формы.

2. Проверьте CSRF-токен.

3. Проверьте формат email.

4. Примените ограничение частоты запросов по IP и адресу.

5. Передайте контакт в сервис с признаком ожидания подтверждения.

6. Покажите нейтральное уведомление без раскрытия состояния адреса.

7. Отправьте письмо подтверждения.

8. Активируйте контакт только после перехода по одноразовой ссылке.

9. Зафиксируйте дату, источник и версию текста согласия.

10. Удаляйте или архивируйте неподтверждённые записи по внутреннему регламенту.

Не возвращайте разные ответы для существующего и отсутствующего адреса. Иначе форма становится инструментом проверки базы. Ответ должен быть одинаковым по структуре: запрос принят, дальнейшие действия выполняются через почту.

Ссылка подтверждения должна быть:

• одноразовой;
• ограниченной по сроку действия;
• привязанной к конкретной записи;
• защищённой от повторного использования;
• недоступной через предсказуемый числовой идентификатор.

Токен не храните в открытом виде, если система реализуется самостоятельно. Храните хеш токена, а исходное значение передавайте только в ссылке подтверждения.

Double Opt-In снижает риск попадания в базу невалидных адресов и спам-ловушек. Дополнительно он подтверждает, что контролируется именно указанный почтовый ящик. Это не исключает жалобы и отписки, но убирает значительную часть ошибок на этапе сбора контактов.

5. Установите форму подписки на сайт

Форма подписки может быть частью CMS, отдельным виджетом сервиса или собственной HTML-формой, которая отправляет данные на backend.

Виджет подходит для стандартного сценария: email, имя, одна группа подписчиков, готовое письмо подтверждения. Используйте его, если не требуется сложная логика и расширенное связывание с внутренними сущностями сайта.

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

• дату последнего обновления;
• совместимость с текущей версией CMS;
• список внешних запросов;
• способ хранения API-ключа;
• наличие обработки вебхуков;
• права доступа к настройкам;
• возможность отключить автоматическую загрузку скриптов.

Собственную форму выбирайте, когда необходим контроль. Она должна отправлять данные не напрямую в сервис, а на сервер сайта: браузер делает POST-запрос на backend, backend вызывает API сервиса рассылок и получает ответ.

В клиентском коде оставляйте только публичные параметры формы. API Key и Secret Key должны находиться на сервере.

Минимальный набор полей:

• email;
• согласие на получение конкретного типа рассылки;
• скрытый технический токен;
• источник подписки;
• опционально — имя и сегмент.

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

Автоматически подписывать пользователя после оформления заказа нельзя, если подписка не была выбрана отдельно. Транзакционное уведомление о заказе и рекламная рассылка имеют разные основания отправки и разные настройки.

6. Настройте обработку ошибок API и SMTP

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

Для API разделяйте ошибки на классы:

• 4xx из-за некорректных данных;
• 401 или 403 из-за ключа и прав;
• 404 из-за неправильного endpoint или идентификатора списка;
• 409 при конфликте или повторном создании контакта;
• 429 при превышении лимита;
• 5xx при временной ошибке провайдера.

Для 429 и части 5xx применяйте повтор с увеличивающейся задержкой. Не запускайте бесконечные повторы. Иначе кратковременный сбой превратится в очередь дубликатов и дополнительную нагрузку.

Для SMTP контролируйте коды ответа:

• 2xx — операция принята;
• 4xx — временная ошибка, возможна повторная доставка;
• 5xx — постоянный отказ или ошибка адресата.

Не отмечайте письмо как доставленное только потому, что SMTP-соединение установлено. Принятие сообщения сервером отправителя и доставка в почтовый ящик — разные события.

Сохраняйте в логах:

• время операции;
• внутренний идентификатор контакта;
• тип события;
• код ответа;
• сокращённое описание ошибки;
• корреляционный идентификатор.

Не сохраняйте в открытом виде:

• API-ключи;
• SMTP-пароли;
• полные URL с токенами;
• содержимое персональных данных без необходимости;
• ссылки подтверждения.

7. Проверьте DNS и фактическую подпись

После публикации DNS-записей не ограничивайтесь визуальной проверкой панели регистратора. Запросите записи с внешнего DNS-резолвера — например, через утилиты dig, nslookup или онлайн-сервисы. Панель может показывать запись, но кэш или проксирование DNS иногда возвращают устаревшее значение. Внешний запрос даёт ту же картину, которую увидит почтовый сервер получателя.

Для SPF запросите TXT-запись основного домена. В ответе должна присутствовать строка v=spf1 и все используемые include. Отсутствие записи или её фрагмента говорит о проблеме публикации, а не о работе самого сервиса рассылок.

Для DKIM запросите запись вида <селектор>._domainkey.вашдомен. Если сервис выдал селектор s1, проверяйте s1._domainkey.example.ru. Значение должно содержать v=DKIM1 и p=. Пустое значение p= означает, что ключ отозван. Это нормальная ситуация при ротации, но недопустимо для активной отправки.

После отправки тестового письма откройте его исходный код в почтовом клиенте или через сервис анализа заголовков. В заголовке DKIM-Signature проверьте:

• параметр d= — домен подписи, должен совпадать с вашим доменом или поддоменом;
• параметр s= — селектор, должен совпадать с опубликованным в DNS;
• результат проверки — поле Authentication-Results у принимающего сервера (например, dkim=pass, spf=pass, dmarc=pass).

Отсутствие заголовка Authentication-Results в копии письма не означает, что проверка не выполнялась. Не все почтовые серверы добавляют его в сообщение для отправителя. Используйте специализированные сервисы, которые показывают результат «изнутри» протокола.

Для DMARC заведите отдельный почтовый ящик или подключите сервис агрегации для адреса отчётов rua. Отчёты в формате XML приходят обычно раз в сутки. Их разбор покажет, какие системы реально отправляют почту от имени домена и где нарушено выравнивание.

Проверьте также обратный путь Return-Path. Если он указывает на домен, отличный от домена в From, DMARC может не пройти выравнивание даже при корректных SPF и DKIM. Это типичная ошибка при использовании разных поддоменов для транзакционных и маркетинговых потоков.

Без внешней проверки DNS и фактической подписи письма вы доверяете панели управления, а не работающему протоколу.

Что делать после запуска

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

• ротация DKIM-ключей — обычно раз в несколько месяцев, по регламенту конкретного сервиса;
• проверка новых источников отправки перед их добавлением в SPF;
• анализ DMARC-отчётов на предмет несанкционированных отправок;
• очистка базы от неактивных контактов и жёстких отказов;
• ревизия API-ключей и scopes;
• контроль версий CMS-плагинов и форм подписки.

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

Подключение сервиса рассылок к сайту — инженерная задача, а не маркетинговый тумблер. Каждый из семи шагов проверяется отдельно. Пропуск любого из них проявится позже — в папке «Спам» у получателя, в ошибках SMTP или в утечке API-ключа. Сборка по описанному порядку даёт предсказуемый результат: письма уходят, домен не теряет репутацию, база остаётся чистой.