Куда почтовый сервер несёт письмо после проверки MX?
Когда сервер видит адрес ivan@company.ru, он запрашивает MX-запись домена company.ru. В записи указан сервер-получатель и его приоритет: чем меньше число, тем раньше сервер попробует этот маршрут. Если основной сервер недоступен, почтовая система переходит к следующему MX с более низким приоритетом.
| Состояние домена | Что происходит с письмом | Риск для кампании |
|---|---|---|
| MX указывает на рабочую почту | Сервер принимает письмо и передаёт его в ящик | Адрес можно проверять дальше по другим сигналам |
| MX отсутствует или ведёт на несуществующий хост | Отправитель получает отказ доставки | База загрязняется адресами с отскоками (отказами доставки) |
| MX настроен, но ящик удалён | Домен существует, конкретный адрес не принимает почту | Нужен второй контакт в той же компании |
MX отвечает за путь входящего письма. Он не подтверждает репутацию отправителя и не обещает попадание во «Входящие». За идентификацию домена отвечают SPF, DKIM и DMARC.
Как ошибка в MX лишает кампанию ответов, хотя первое письмо ушло?
Представим письмо интегратора: «Алексей, увидели, что ваша сеть расширяет склад. Есть ли смысл показать расчёт по терминалам сбора данных?» ЛПР отвечает: «Да, пришлите пример проекта». Но если у домена отправителя после переноса почты осталась неверная MX-запись, ответ не попадёт в ящик. Для ЛПР это выглядит как отказ доставки, для отдела продаж — как молчание лида.
- До запуска отправьте тестовое письмо с внешнего ящика на каждый домен, с которого планируется вести переписку.
- Ответьте на тестовое письмо обратно и проверьте, что ответ пришёл в нужный ящик, а не только отображается в интерфейсе сервиса.
- После смены провайдера почты проверьте MX, почтовые ящики и маршрут ответа до возобновления кампании.
Для базы это отдельная задача: сначала уточняют компанию и роль, затем проверяют адреса и фиксируют результат. Такой порядок описан в услуге валидации и очистки базы.
Какие ошибки в MX встречаются перед рассылкой?
- В MX внесён IP-адрес вместо имени почтового сервера. Запись должна вести на имя узла, которое затем разрешается в IP-адрес.
- После миграции на новый почтовый сервис старые MX удалили, а новые не добавили или добавили с опечаткой.
- Два провайдера настроены одновременно без понятного приоритета: часть писем уходит на старый сервер, часть — на новый.
- Отправка идёт с поддомена, а команда проверила только основной домен и не проверила, куда придут ответы.
Неудачный подход — смотреть только на возможность отправить тестовое письмо. Удачный — проверить полный круг: отправка, получение, ответ и отображение ответа у менеджера. Затем уже настраивать доставляемость и запускать email-аутрич.
Когда MX-запись не решит проблему с письмами?
Исправный MX не поможет, если письмо отправлено на несуществующий адрес, домен получателя временно не принимает внешнюю почту или сообщение отфильтровано до ящика. Он также не исправит нерелевантный оффер: технически доставленное письмо не создаёт интереса само по себе.
MX-проверка не подходит как единственный критерий качества базы. Для кампании по узкому списку компаний нужен разбор роли, источника контакта и запасного маршрута — например, второй корпоративный адрес. Если задача шире одной DNS-настройки, начинайте с сбора базы ЛПР, а не с массовой отправки.