Как защитить почтовые ящики для аутрича от взлома и не сжечь домен

Взломанный ящик аутрич-домена — это не просто утечка: злоумышленник за ночь выжигает с него тысячи спам-писем, домен улетает в чёрные списки, и канал встаёт на недели. При этом ящики для рассылки ломают чаще обычных: их пароли лежат в CRM и сервисах отправки, к ним подключены интеграции по IMAP/SMTP. Разбираем, как выстроить защиту почтового ящика, не парализовав работу инструментов.

Почему ящики для аутрича ломают чаще и что теряется при взломе

У ящика для холодных рассылок поверхность атаки шире, чем у личной почты. Его пароль хранится не только в голове владельца: он введён в платформу отправки, в CRM, в сервис прогрева, иногда в таблицу «доступы» на общем диске. Каждое из этих мест — потенциальная точка утечки. Плюс сами ящики часто заводятся пачками, с однотипными паролями вида Company2025-1, Company2025-2 — подобрав один, злоумышленник получает все.

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

Последствия для владельца несимметричны выгоде атакующего. Ночной залп в 10–20 тысяч спам-писем — и репутация домена в postmaster-кабинетах падает до «плохой», домен попадает в публичные чёрные списки, провайдер блокирует аккаунт за нарушение правил. Восстановление занимает от двух недель до месяцев, а иногда домен проще похоронить и начать с нового — потеряв весь накопленный прогрев.

Фундамент: пароли, 2FA и app-пароли

Первое правило скучное, но решающее: каждому ящику — уникальный сгенерированный пароль из менеджера паролей, длиной от 16 символов. Никаких серий с инкрементом, никаких паролей, совпадающих с паролем от панели домена или CRM. Утечки баз паролей происходят регулярно, и переиспользованный пароль — самый частый вектор взлома почты.

Второе — двухфакторная аутентификация на каждом ящике и, что не менее важно, на управляющих аккаунтах: админке Google Workspace или Яндекс 360, панели регистратора домена, DNS-хостинге. Взлом админки страшнее взлома ящика: атакующий заведёт свои ящики, перепишет DNS и перехватит всю почту. Для 2FA предпочитайте приложение-аутентификатор или аппаратный ключ; SMS — лучше, чем ничего, но перехватывается.

Третье — app-пароли (пароли приложений) для всего, что подключается по IMAP/SMTP: платформа отправки, CRM, сервис прогрева. App-пароль даёт доступ только к почтовым протоколам, не позволяет войти в веб-интерфейс и сменить настройки, и его можно отозвать, не трогая основной пароль. Правило: одна интеграция — один app-пароль с понятным названием. Утёк ключ из одного сервиса — отозвали один ключ, остальное работает.

• Уникальный пароль 16+ символов из менеджера паролей — на каждый ящик.
• 2FA через приложение или аппаратный ключ — на ящиках, админке домена, DNS и регистраторе.
• App-пароли для IMAP/SMTP-интеграций, по одному на сервис.
• Резервные коды 2FA — в менеджере паролей, а не в письме самому себе.
• Доступы сотрудникам — через общий менеджер паролей с разграничением прав, не через чат.

Гигиена доступа: люди и сервисы

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

Отдельно про сторонние сервисы. Каждая платформа, куда вы вводите пароль или app-пароль ящика, становится хранителем вашего доступа — выбирайте те, что хранят креды шифрованно и позволяют отозвать доступ со своей стороны. Раз в квартал полезно провести ревизию: открыть в настройках ящика список app-паролей и активных сессий и удалить всё, что не опознаётся. Мёртвые интеграции — любимая дверь для атакующих.

И про фишинг: ящики, с которых идёт аутрич, получают много входящих, включая письма «ваш аккаунт будет заблокирован, войдите для подтверждения». Люди, разбирающие ответы кампаний, должны быть предупреждены: провайдер не просит пароль по ссылке из письма. Одна введённая на фишинговой странице пара логин-пароль обнуляет всю остальную защиту, если нет 2FA.

Мониторинг: как заметить компрометацию за часы, а не недели

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

Что проверять регулярно: журнал входов в аккаунт (незнакомые IP, страны, устройства), правила фильтрации и пересылки (появившиеся «сами собой» правила — почти стопроцентный признак взлома), папку «Отправленные» на письма, которых никто не писал, и список активных сессий. В Google Workspace и Яндекс 360 админ видит журналы по всем ящикам организации — настройте оповещения о подозрительных входах, они там штатные.

Со стороны отправки индикатор — аномалия объёма. Если ящик, который шлёт 40 писем в день по кампании, внезапно отправил 400 за час — это либо сбой автоматики, либо компрометация; в обоих случаях отправку надо стопить немедленно. Платформа аутрича должна иметь лимиты на ящик и алерты на их превышение — в LDM такие лимиты и автостоп встроены в контур отправки.

Если ящик всё-таки взломали: порядок действий

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

После разрыва доступа оцените масштаб: сколько и каких писем ушло (папка «Отправленные» и журналы SMTP), затронуты ли другие ящики домена, не менялись ли DNS-записи и настройки DKIM. Проверьте, не попал ли домен в чёрные списки — это видно по резкому росту reject'ов и в публичных чекерах DNSBL. Уведомите команду: если с ящика ушёл фишинг по вашим клиентам и партнёрам, честное предупреждение с другого канала сохранит отношения и снизит ущерб.

Восстановление репутации — самая долгая часть. Снизьте объёмы отправки с домена до минимума, разошлите заявки на исключение из чёрных списков (у большинства DNSBL есть форма delisting), следите за postmaster-кабинетами. Если через 3–4 недели репутация не восстанавливается, экономически осмысленнее перенести аутрич на резервный домен — он у зрелой инфраструктуры должен быть прогрет заранее.

• Сменить пароль ящика и разорвать все активные сессии.
• Отозвать все app-пароли и OAuth-доступы, проверить 2FA и резервные коды.
• Удалить чужие правила пересылки и фильтры, проверить подпись и автоответчик.
• Остановить все кампании с домена до выяснения масштаба.
• Проверить журналы: что ушло, кому, с каких ещё ящиков.
• Проверить DNS, DKIM-ключи и чёрные списки; подать на delisting.
• Разобрать вектор взлома и закрыть его — иначе всё повторится.

Чек-лист: безопасность email аккаунта для аутрича

Защита почтового ящика для рассылки — это не разовая настройка, а режим: раз в квартал ревизия доступов, раз в неделю взгляд на журналы и метрики. На фоне цены сгоревшего домена — недели простоя канала и потерянный прогрев — эти полчаса в месяц окупаются как ничто другое.

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

• У каждого ящика уникальный пароль 16+ символов из менеджера паролей.
• 2FA включена на ящиках, админке почты, регистраторе домена и DNS.
• Интеграции подключены через app-пароли, по одному на сервис.
• Доступы команды — в общем менеджере паролей, отзыв при увольнении — процедура, а не память.
• Раз в квартал — ревизия app-паролей, сессий и OAuth-доступов.
• Настроены алерты на подозрительные входы и аномальные объёмы отправки.
• Есть написанный план реагирования и прогретый резервный домен.

Вопросы и ответы