Как работает SMTP в холодных рассылках и почему это не «просто отправить письмо»

Когда кампания не доходит до адресатов, первым делом смотрят на текст письма и тему — а зря, потому что письмо чаще всего умирает на уровне SMTP, до того как получатель вообще о нём узнал. Если вы отправляете холодные письма по юрлицам, а не рассылку по подписной базе, понимание SMTP — не теория для админов, а рабочий инструмент: он объясняет, почему одни ящики «долетают», а другие мгновенно попадают в спам или вообще отклоняются.

Что такое SMTP и при чём тут доставляемость

SMTP (Simple Mail Transfer Protocol) — протокол, по которому почтовые серверы передают друг другу письма. Когда вы нажимаете «отправить», письмо не летит напрямую на сервер получателя: сначала оно уходит на ваш исходящий SMTP-сервер (релей), а тот уже связывается с почтовым сервером получателя (условно MX-записью домена компании-адресата) и передаёт письмо ему.

Это значит, что в цепочке минимум три участника: ваш почтовый клиент или CRM, ваш SMTP-релей и принимающий сервер. Принимающая сторона (Gmail для юрлиц на Google Workspace, Яндекс 360, Exchange и так далее) оценивает не только содержимое письма, но и репутацию того самого релея — IP-адреса, с которого пришло соединение, и домена, от имени которого письмо подписано.

Отсюда ключевой вывод для адресного B2B-аутрича: письмо может быть идеально написано под конкретного ЛПР, но если релей уже засветился спамом с других аккаунтов на том же IP, письмо получит пониженный приоритет или сразу уйдёт в папку «Спам» — вы этого не увидите, получатель тоже, кампания просто провалится молча.

Важно понимать разницу между SMTP как протоколом и SMTP-сервером как конкретной инфраструктурой. Протокол один и тот же везде — набор команд и кодов ответа стандартизирован десятилетиями назад. А вот сервер, через который вы отправляете, у каждого отправителя свой: это может быть встроенный релей CRM, отдельный сервис вроде Postfix на своём VPS или почтовый провайдер вроде Google Workspace. Именно выбор этого сервера определяет 90% проблем с доставляемостью, а не формулировки в письме.

Путь письма от клиента до inbox получателя

Разберём по шагам, что происходит технически. Ваша CRM или почтовый клиент открывает SMTP-соединение с релеем (обычно порт 587 с STARTTLS или 465 с SSL — порт 25 без шифрования сейчас использовать не стоит). Релей проверяет авторизацию отправителя, ставит письмо в очередь и ищет MX-запись домена получателя через DNS.

Дальше релей соединяется уже с принимающим сервером и начинает диалог по SMTP-командам: HELO/EHLO (представление), MAIL FROM (обратный адрес), RCPT TO (адрес получателя), DATA (тело письма). На каждом шаге принимающий сервер может ответить кодом — и это самое интересное место для диагностики отправки.

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

• 2xx — команда принята, всё хорошо
• 4xx — временная ошибка (soft bounce): ящик переполнен, сервер перегружен, greylisting — можно повторить позже
• 5xx — постоянная ошибка (hard bounce): адрес не существует, домен заблокировал отправителя — повторять бесполезно, адрес нужно исключить из базы
• 550 5.7.1 — типичный код отказа по репутации отправителя, а не по адресу получателя

Почему свой Gmail или Яндекс — плохой SMTP для аутрич-кампаний

На старте многие пробуют слать через личный ящик: настроил SMTP в CRM, указал логин-пароль от Gmail — и вперёд. Это работает ровно до первой сотни писем, а дальше упирается в жёсткие лимиты почтовых провайдеров: Google ограничивает Workspace-аккаунты примерно 500 письмами в сутки (для обычного Gmail — меньше), Яндекс держит похожие пороги. Превысили — временная блокировка отправки на сутки, а при повторах риск более долгой заморозки аккаунта.

Хуже другое: массовая рассылка холодных писем через личный почтовый ящик компании — это risk для основного рабочего адреса. Если провайдер решит, что аккаунт занимается спамом, под удар попадёт не только кампания, но и вся деловая переписка с этого адреса. Для адресного B2B-аутрича правильная архитектура — отдельный пул отправляющих ящиков (не подменных, а реальных, с прогревом), подключённых через SMTP-релей, который вы контролируете или которому доверяете по репутации.

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

Что проверять при выборе SMTP-релея для холодных писем

Не всякий SMTP-сервис одинаково подходит под холодные B2B-письма. Транзакционные релеи (заточенные под чеки, уведомления, OTP-коды) часто банят аккаунт при первом же всплеске холодных писем — их антиспам-модели ждут известных получателей, а не новых юрлиц. Нужен релей, который либо явно разрешает cold outreach, либо вы поднимаете свою инфраструктуру и полностью контролируете репутацию сами.

• Поддержка SPF, DKIM и DMARC на уровне домена — без них письма изначально стартуют с недоверием
• Отдельный IP или пул IP с известной, чистой историей — не shared-пул, где вперемешку транзакционные и спам-рассылки
• Разумные лимиты на прогрев: новый ящик — не больше 20–30 писем в день с постепенным ростом
• Логи с кодами ответа по каждому письму — иначе не отличить soft bounce от hard bounce и база быстро загрязняется
• Возможность ротации отправляющих ящиков по кампании, чтобы не концентрировать нагрузку на одном адресе

Как это выглядит в адресном B2B-аутриче на практике

В LDM письма уходят не одним потоком с одного адреса, а через пул прогретых ящиков с настроенными SPF/DKIM/DMARC, а система следит за откликами SMTP-релея на уровне каждого письма: если растёт число soft bounce по конкретному ящику, что намекает на проблему с репутацией, отправка через этот адрес приостанавливается раньше, чем провайдер-получатель успеет занести домен в чёрный список.

Это принципиально другая логика, чем в ESP для email-маркетинга: там объём — цель, здесь объём — риск. Чем аккуратнее распределена нагрузка по адресатам-юрлицам и ящикам-отправителям, тем стабильнее репутация каждого элемента цепочки SMTP, а значит и выше итоговая доставляемость конкретного письма конкретному ЛПР.

Типичные ошибки в настройке SMTP под аутрич

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

Вторая — игнорировать код ответа SMTP и слать повторно всем подряд после отказа. Soft bounce (4xx) можно и нужно повторить через время, hard bounce (5xx) — сигнал немедленно вычистить адрес из базы: повторные попытки на несуществующий или заблокированный адрес портят репутацию отправителя куда сильнее, чем один пропущенный контакт.

Третья — не разносить домен для отправки и домен для трекинг-ссылок/лендинга. Смешение ролей в одном домене увеличивает риск, что проблема на одном участке (например, жалоба на письмо) срикошетит на репутацию всего остального.

Четвёртая — забыть про PTR-запись (обратный DNS) для собственного сервера отправки. Многие корпоративные почтовые системы жёстко требуют совпадения PTR с HELO-именем и доменом отправителя — без этого письма молча режутся на этапе рукопожатия, задолго до content-фильтров.

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