SPF DKIM DMARC для рассылок клуба

Почта клуба обычно ломается не одним большим событием, а серией мелких жалоб. Клиент не получил письмо с подтверждением записи. Абонемент ушёл в спам. Рассылка про акцию открылась хуже обычного. Администратор вручную пересылает информацию из личной почты, потому что «так точно доходит». В какой-то момент выясняется, что домен отправляет письма через сайт, CRM, сервис рассылок, хостинг и ещё старый ящик, о котором все забыли.

SPF, DKIM и DMARC нужны, чтобы почтовые системы понимали: письмо действительно отправлено от имени вашего домена, а не кем угодно. Это не волшебная кнопка «всегда во входящие», но без этих настроек доставляемость становится лотереей. Особенно если домен используется и для транзакционных писем, и для маркетинговых рассылок.

Транзакционная и маркетинговая почта — разные задачи

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

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

Практичный подход — разделять домены или поддомены и сервисы отправки. Например, основной домен для корпоративной почты, отдельный поддомен для рассылок, транзакционные письма через сервис, который умеет DKIM и нормальные логи доставки. Конкретная схема зависит от CRM и сайта.

SPF: кто имеет право отправлять

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

Типичная проблема — несколько SPF-записей одновременно. Так делать нельзя: должна быть одна запись TXT с объединёнными разрешениями. Вторая проблема — бесконечные include, которые превышают лимиты DNS-запросов. Визуально запись есть, а проверка у получателей работает нестабильно.

SPF не подписывает письмо и не защищает содержимое. Он отвечает на вопрос: «Этот сервер имел право отправлять от имени домена?» Этого мало, но это базовый слой.

DKIM: подпись письма

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

Для бизнеса важна дисциплина ключей. У каждого сервиса отправки обычно свой DKIM-селектор. CRM, сайт, почтовый провайдер, сервис рассылок — все могут требовать отдельные DNS-записи. Удалять старые ключи нужно аккуратно: сначала понять, используется ли сервис. Иначе можно внезапно сломать доставку заявок с сайта.

Если сайт отправляет формы через SMTP, убедитесь, что письма идут от корректного домена и подписываются провайдером. Для заявок с сайта IT-CG использует почтовую доставку без базы лидов, и похожую логику можно применить в проектах клиентов: меньше самодельной отправки, больше управляемого сервиса и логов.

DMARC: что делать с нарушителями

DMARC связывает SPF и DKIM с политикой домена. Он говорит получателям, что делать, если письмо не прошло проверку: ничего не предпринимать, отправить в спам или отклонить. Ещё он позволяет получать отчёты о том, кто отправляет письма от имени домена.

Начинать лучше с режима наблюдения p=none. Так вы увидите легитимные источники: корпоративная почта, сайт, CRM, рассылки, старые интеграции. После исправления SPF и DKIM можно постепенно переходить к более строгой политике. Резкий p=reject без инвентаризации может отрезать собственные письма.

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

DNS и ответственность

Настройки SPF, DKIM и DMARC живут в DNS. Поэтому доступ к домену должен быть у компании, а не только у старого подрядчика или веб-студии. Перед настройкой стоит проверить, кто владеет регистратором, где управляются DNS-записи, есть ли второй администратор и включена ли MFA. Это ровно те вопросы, которые всплывают при IT-аудите перед сменой подрядчика.

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

Что ещё влияет на доставляемость

SPF, DKIM и DMARC не отменяют репутацию. Если база собрана без согласия, письма отправляются слишком часто, нет понятной отписки, тема обещает одно, а внутри другое — даже идеальные DNS-записи не спасут. Для маркетинговых рассылок нужны чистые списки, согласия, отписка и нормальная частота.

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

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