Холодные письма не отправляются: разбираем причины по шагам

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

Шаг 0: определить масштаб проблемы, прежде чем чинить

Прежде чем лезть в SPF-записи или писать в поддержку провайдера, за две минуты выясните, где именно встала отправка. Ответ на этот вопрос сразу отсекает большинство версий и экономит остаток разбора.

Если не отправляется один ящик из пула, а остальные работают нормально — проблема локальная: лимит, заморозка, пароль приложения именно этого аккаунта. Если встал весь пул одновременно — ищите общую причину: домен в блэклисте, изменившийся DNS, отключённый транспорт или сбой у самого провайдера рассылки. Если письма уходят, но возвращаются баунсом только от адресов на одном домене получателя (например, все bounce с @yandex.ru, а к остальным доходит) — это почти всегда блокировка на стороне конкретного почтового сервиса, а не поломка у вас.

Дальше смотрите не на факт «не отправилось», а на текст ошибки. SMTP-баунс почти всегда содержит код (450, 550 и так далее) и человекочитаемую причину следом — эта строка обычно прямо называет проблему: daily sending limit exceeded, IP blocked, SPF fail. Не игнорируйте её в панике, это самая быстрая диагностика из всех возможных.

• Встал один ящик или весь пул отправки?
• Есть ли доступ в веб-интерфейс почты этого ящика, или заблокирован сам логин?
• Баунсит всё подряд или только письма к одному-двум доменам получателей?
• Что написано в тексте ошибки SMTP-сервера дословно — не пересказ, а точная строка?
• Когда началось: сразу после смены настроек/увеличения объёма или без видимой причины?

Причина 1–2: дневной лимит исчерпан или аккаунт заморожен провайдером

Самая частая причина остановки отправки в адресном B2B-аутриче — не хитрая техническая поломка, а банальное превышение дневного лимита. Личный или корпоративный почтовый ящик, который вы используете для рассылки, — не промышленная ESP-инфраструктура с десятками выделенных серверов, а обычный аккаунт Gmail, «Яндекс.Почты» или корпоративного домена на условном Google Workspace. У таких ящиков есть собственный, часто не документированный порог, после которого провайдер начинает придерживать или полностью блокировать исходящую почту.

Ориентир из практики: для нового или недавно прогретого ящика безопасный дневной объём — 30–50 писем, для хорошо прогретого домена с историей — 80–150. Цифры в 300–500 писем в день, которые встречаются в общих инструкциях, рассчитаны на массовые ESP-платформы с выделенной инфраструктурой и репутацией сервиса, а не на личный ящик, который вчера ещё не использовался для рассылок вообще. Если вы резко увеличили объём на одном аккаунте — это первый подозреваемый.

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

Причина 3: SPF, DKIM и DMARC разъехались

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

Проверяется быстро: любой публичный чекер DNS-записей (dig в консоли или онлайн-инструмент) покажет текущую SPF-запись домена — сверьте её с фактическим списком отправляющих сервисов. DKIM проверяется похожим образом через селектор подписи в заголовках письма. DMARC-политика на p=reject особенно жёстко наказывает несовпадение: если SPF или DKIM не проходят выравнивание с доменом From, письмо не просто улетает в спам, а отбраковывается на приёме и не доходит вообще.

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

Причина 4: IP-адрес или домен попал в блэклист

Если баунс содержит формулировки вроде «blocked», «listed as spam source» или прямую ссылку на блэклист-сервис — домен или IP отправки внесены в один из спам-листов (Spamhaus, SORBS, Barracuda и десятки более мелких). Это может случиться даже без вашей вины: например, домен раньше принадлежал другому владельцу и уже был скомпрометирован, или IP-адрес общий с другими арендаторами хостинга, один из которых спамил.

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

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

Причина 5: порт заблокирован, SMTP-настройки сбились, истёк пароль приложения

Отдельная группа причин — самая скучная, но проверяется первой именно потому, что чинится за минуты. Порт 25 часто блокируется на уровне хостинг-провайдера или интернет-провайдера как антиспам-мера по умолчанию — это касается не только почтовых серверов, но и любых скриптов, которые пытаются слать письма напрямую через SMTP. Решение — использовать порт 587 (submission, с STARTTLS) или 465 (SMTPS) вместо 25, они для исходящей почты через авторизованный аккаунт и обычно не режутся так агрессивно.

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

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

Как не наступить на те же грабли снова

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

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

• Прогревайте новый ящик 2–6 недель постепенным наращиванием объёма, прежде чем ставить его в боевой пул отправки
• Держите дневной лимит на ящик на 20–30% ниже потолка, который он выдерживал раньше — это запас на колебания репутации провайдера
• Раз в квартал сверяйте SPF-запись домена с фактическим списком сервисов отправки, особенно после подключения новых инструментов
• Мониторьте постмастер-инструменты крупных провайдеров (Google Postmaster Tools и аналоги) — они показывают репутацию домена и IP до того, как начнутся массовые баунсы
• Ведите календарь ротации паролей приложений и заранее проверяйте их работоспособность, а не по факту отказа отправки
• При любом изменении почтового провайдера или транспорта — тестовая отправка на контрольный ящик в тот же день, а не после того, как заметили падение метрик
• Проверяйте IP и домен в агрегаторе блэклистов не реже раза в месяц, если пул отправляет заметный объём

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