Как расследовать блокировку почты и вернуть отправку

Если почтовый IP попал в блэклист, сначала подтвердите конкретную запись и остановите причину отправки, затем подавайте запрос по процедуре оператора. Код 550 или 554 сам по себе блокировку не доказывает. Ниже — порядок диагностики, разбор условного магазина на 15 рабочих мест и меры против повторной рассылки.

Как подтвердить блокировку и найти нужный список?

При недоставке я начинаю с полного ответа принимающего SMTP-сервера: важны код, расширенный код, текст, адрес получателя и этап, на котором оборвалась передача. Числа 550 и 554 сами по себе не означают «IP в блэклисте»: по RFC 5321 это общие ответы об отказе или сбое транзакции, а причина может быть в политике получателя, адресе ящика, настройке релея и других условиях. Поэтому сначала смотрю, какой сервер вернул отказ и какой IP он видел. Если нужна помощь с настройкой корпоративной почты, разбираю этот путь вместе с администратором, а не угадываю по одному числу. Сравниваю и результат на других доменах-получателях: один адрес может принять письмо, а другой — вернуть отказ по своей политике. Ответ 4xx обычно означает временную проблему и повторную попытку позже; 5xx — постоянный отказ, который сам по себе повтором не исправить. Но разница между временным и постоянным ответом всё ещё не называет причину. В рабочую заметку я сохраняю полный текст DSN и соответствующий фрагмент журнала, чтобы не потерять имя удалённого узла, время и идентификатор сообщения.

Затем сверяю именно исходящий IP — тот, с которого письмо ушло к получателю, а не адрес рабочего компьютера или веб-интерфейса. Если отправка идёт через SMTP-релей, смотрю его адрес и ответ релея. IP и домен проверяю отдельно: запись для IP и доменная репутация — разные результаты, разные списки и иногда разные владельцы данных. В Spamhaus SBL связан с сетями и адресами, замеченными в злоупотреблениях; XBL — с адресами скомпрометированных устройств; PBL — с адресным пространством, которому не следует отправлять почту напрямую в интернет. ZEN объединяет несколько наборов, поэтому одного слова «listed» мало: откройте детали конкретной записи и её объяснение.

Разборный пример — условный московский магазин тканей «Ткань и дом», 15 рабочих мест. В нём я фиксирую не придуманный диагноз, а исходные данные: ответ удалённого сервера, время, адрес отправителя, исходящий IP и результат проверки. Если список не указан в ответе принимающего сервера, я не записываю в акт «Spamhaus виноват»: проверяю IP и домен через сервис оператора, а затем сравниваю результат с журналом доставки. Для отдельного сценария быстрой проверки репутации есть проверка IP за пять минут.

Ещё один полезный срез — масштаб отказа. Если письма не принимает один почтовый сервис, а остальные получают их, фиксирую это отдельно и смотрю его собственную политику; если отказ приходит от нескольких независимых получателей, ищу общий фактор отправки. Сверяю повторные ответы по удалённому хосту, времени и типу отказа. Так становится видно, блокируется ли конкретный маршрут, IP или только один тип сообщения. Заголовок «не доставлено» слишком широк для диагноза, а журнал обычно уже показывает, где именно закончился путь.

Как найти источник и остановить исходящую рассылку?

Когда у меня есть подтверждённая запись, я выясняю, кто создал исходящие сообщения: пользователь по SMTP-аутентификации, веб-приложение, локальный скрипт или другой узел, который отправляет напрямую. На Postfix очередь можно посмотреть командой postqueue -p; она показывает ожидающие сообщения, но сама по себе не объясняет причину попадания в список. Я сопоставляю время, отправителя, получателей и журналы почтового сервера. Не удаляйте очередь целиком до разбора: в ней могут быть и обычные письма сотрудников, и материал, который помогает установить источник.

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

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

Проверяю и направление потока. При исходящей жалобе удалённый получатель оценивает адрес, который подключился к нему; при входящей жалобе на спам IP принадлежит отправителю письма, а не нашей организации-получателю. За общим NAT или релеем могут быть разные аккаунты и приложения, поэтому по одному внешнему адресу нельзя сразу назвать конкретный ящик. В журнале я ищу инициатора сообщения, маршрут и сопоставимый идентификатор, а затем проверяю источник внутри своего контура. Это не даёт перепутать чужую репутационную проблему с нашим почтовым сервером.

Как подать запрос на снятие блокировки?

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

У PBL отдельная логика: она помечает адреса, которым не следует отправлять почту напрямую, а не просто динамические IP. Spamhaus допускает исключение одиночного адреса, если это статический IP исходящего почтового сервера, он назначен запрашивающей организации, настроены прямое и обратное DNS-имена, а исходящий порт 25 закрыт для остальных устройств. Для динамического адреса Spamhaus советует исходящий релей провайдера либо переход на статический адрес с корректным DNS. После PBL-исключения указывают примерно 15 минут на распространение DNS-зоны; это не срок снятия любой записи в любом списке. PBL-исключение пользовательского IP также не бессрочно и отменяется при обнаружении спама.

SPF, DKIM и DMARC проверьте отдельно — это настройки аутентификации домена и согласованности отправителя, а не кнопка снятия IP из списка. Исправленная SPF-запись не устраняет скомпрометированный ящик, а успешная DKIM-подпись не отменяет запись SBL. Если проверка показывает проблему с подписями или доменной политикой, исправляйте её как отдельную часть доставки; детали есть в материале о кодах SMTP 550.

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

Что делать при отказе или повторном попадании в список?

Если запрос не принят, читаю причину отказа и сверяю её с текущим состоянием, а не отправляю ту же заявку снова наугад. Оператор мог увидеть продолжающуюся активность, неподходящий тип адреса или неполные данные. Проверяю, действительно ли мой исходящий IP совпадает с указанным в заявке, не перепутан ли адрес SMTP-релея с адресом приложения и не добавился ли новый отправитель после первичной блокировки. Повторное обращение имеет смысл, когда есть новые факты или выполнен конкретный пункт, который назвал оператор; универсального правила «ждать неделю» нет.

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

Смену адреса рассматриваю только как изменение почтовой инфраструктуры, а не как способ отменить последствия инцидента. Перед ней нужно понять, кому назначен новый адрес, кто настроит прямую и обратную DNS-записи и каким релеем пойдёт почта. Иначе новый IP отправляет те же сообщения от той же скомпрометированной системы и быстро наследует ту же проблему. Если повторный листинг связан с устройством или приложением, сначала закрываю его, затем проверяю статус у оператора.

После снятия записи проверяю доставку по обычному маршруту и сохраняю новый ответ принимающего сервера. Успешное SMTP-принятие означает, что сервер получателя согласился принять сообщение; оно не гарантирует попадание во входящие, потому что дальше действуют фильтры и правила самого сервиса. Поэтому проверяю и факт снятия IP, и отсутствие новой подозрительной активности, и доставку контрольного письма на подконтрольный адрес. Если один этап не прошёл, возвращаюсь именно к нему, а не объявляю инцидент закрытым по одному зелёному статусу.

Как снизить риск новой блокировки?

Я настраиваю один понятный маршрут исходящей почты и собираю статистику по отправителям: сколько писем уходит, кто их инициировал и куда. Если почтовая платформа умеет ограничивать исходящий поток и присылать уведомления о превышениях, задаю лимиты под реальную работу компании и проверяю, что сигнал доходит до администратора. Документация Plesk описывает ограничения на уровне сервера, домена и ящика, которые помогают заметить или остановить массовую отправку; конкретный набор возможностей зависит от используемой системы. Лимит не заменит разбор инцидента, зато он может ограничить ущерб, пока человек реагирует.

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

SPF, DKIM и DMARC настраиваю по фактической схеме отправки: перечисляю разрешённые источники, проверяю подписи и согласование домена, читаю отчёты. Эти меры помогают принимающим системам оценивать подлинность отправителя, но не дают гарантии попадания во входящие и не отменяют репутационные списки. Регулярно проверяю фактический IP исходящей почты и состояние IP и домена в нужных списках. Это занимает меньше сил, чем спорить с ошибкой, в которой никто ещё не прочитал полный ответ SMTP.

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

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