Как устроена доставка email: путь письма от отправки до инбокса ЛПР

Кнопка «Отправить» создаёт иллюзию, что письмо летит напрямую к получателю. На деле между этими двумя точками — минимум пять серверов, три протокола проверки и несколько алгоритмов репутации, любой из которых может завернуть письмо в спам или отклонить вовсе. Разберём путь письма по шагам — это база, без которой сложно понять, почему кампания вдруг перестала доходить.

Зачем разбираться в транспорте, если можно просто пользоваться сервисом рассылки

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

Для холодного B2B-аутрича это особенно важно: письмо адресовано конкретному ЛПР, второго шанса скоро не будет, и цена ошибки в транспорте — не абстрактная статистика, а упущенный контакт с конкретной компанией. Разбор пути письма ниже — минимум, который нужно понимать, чтобы отличить проблему текста от проблемы инфраструктуры.

Ещё одна причина разобраться в транспорте — общение с техническими специалистами. Когда доставляемость проседает, разговор с провайдером почты, с ИТ-отделом заказчика или с поддержкой сервиса рассылки идёт именно в терминах MX, SPF, DKIM и репутации IP. Без базового понимания этих понятий сложно даже сформулировать проблему, не говоря о том, чтобы оценить, действительно ли предложенное решение её устраняет.

Шаг 1: от почтового клиента до отправляющего сервера

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

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

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

Шаг 2: как сервер узнаёт, куда доставлять письмо — MX-записи

Прежде чем отправить письмо, сервер должен узнать, какой именно сервер отвечает за почту домена получателя — например, для company.ru это может быть совсем не тот сервер, что обслуживает сайт company.ru. Для этого существует MX-запись (Mail Exchange) — специальная запись в DNS домена, которая указывает, куда направлять почту.

Отправляющий сервер делает DNS-запрос, получает список MX-серверов с приоритетами и пытается доставить письмо на сервер с наивысшим приоритетом; если тот недоступен, пробует следующий по списку. Если MX-запись настроена неправильно или отсутствует, письма для этого домена в принципе не могут быть доставлены — независимо от качества текста и репутации отправителя.

Для отправителя это означает: если рассылка идёт по своей базе контактов, стоит хотя бы иногда проверять валидность доменов получателей — устаревшие или неправильно настроенные MX-записи в базе контактов создают bounce, за которые дальше расплачивается репутация вашего собственного домена.

Шаг 3: три проверки подлинности — SPF, DKIM, DMARC

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

SPF (Sender Policy Framework) — запись в DNS, которая перечисляет, каким серверам разрешено отправлять почту от имени домена. Принимающий сервер проверяет IP отправителя против этого списка. DKIM (DomainKeys Identified Mail) — криптографическая подпись письма, добавляемая отправляющим сервером и проверяемая получателем через публичный ключ в DNS; она подтверждает, что письмо не было изменено в пути. DMARC (Domain-based Message Authentication) — политика поверх SPF и DKIM, которая говорит принимающему серверу, что делать, если обе проверки провалились: пропустить, отправить в спам или отклонить письмо целиком.

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

Шаг 4: репутация IP и домена — фактор, который не виден в письме

Даже при идеально настроенных технических записях письмо может уйти в спам из-за репутации отправляющего IP-адреса или домена. Крупные почтовые провайдеры — Gmail, Mail.ru, Яндекс — накапливают историю по каждому отправителю: сколько писем открывают, сколько помечают спамом, сколько отправляют в корзину не читая, насколько резко меняется объём отправки.

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

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

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

Где письмо теряется чаще всего — практические выводы

Зная путь письма, легче диагностировать проблему с доставкой: если письма не уходят вообще — проблема на уровне SMTP-соединения или блокировки провайдера; если уходят, но не доходят до получателя — вероятна ошибка в MX-записи домена получателя или устаревший адрес; если доходят, но падают в спам — почти всегда дело в SPF/DKIM/DMARC или в репутации домена и IP.

• Письма не отправляются вообще — проверить настройки SMTP-сервера и лимиты провайдера
• Письма отправлены, но получатель их не получил — проверить MX-запись домена получателя и актуальность адреса
• Письма доходят, но падают в спам — проверить SPF, DKIM, DMARC и историю репутации домена
• Часть писем доходит, часть нет в рамках одной кампании — вероятна проблема репутации конкретного IP или ящика, а не текста письма
• Резкое ухудшение доставляемости после роста объёма — сигнал, что отправка идёт быстрее, чем позволяет текущая репутация домена

Что можно проверить самостоятельно, не привлекая ИТ-отдел

Часть базовой диагностики транспорта не требует специальных знаний или доступа к серверу. Проверить наличие и корректность MX-записи домена, SPF и DKIM можно через любой публичный DNS-checker сервис — достаточно ввести домен и посмотреть на результат, без установки дополнительного софта.

Также стоит время от времени отправлять тестовое письмо на несколько собственных ящиков в разных почтовых системах — Gmail, Mail.ru, Яндекс, корпоративная почта — и проверять, в какую папку оно попадает. Это простой, но информативный способ заметить проблему с доставляемостью до того, как она станет заметна по падению открытий в реальной кампании.

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

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