TLS в почте и доставляемость: что настроить, чтобы Gmail и Outlook не резали письма

Gmail и Outlook всё жёстче относятся к письмам, которые приходят без шифрования канала, — это не про содержимое письма, а про то, как ваш сервер разговаривает с почтовым сервером получателя. Для холодного B2B-аутрича, где каждое письмо уходит адресно и малым объёмом, потеря даже нескольких процентов доставляемости из-за неверной настройки TLS — это конкретные несостоявшиеся разговоры с ЛПР. Разбираем, что такое TLS, MTA-STS и DANE применительно к почтовой инфраструктуре и что из этого действительно нужно настраивать самим.

Что вообще проверяют Gmail и Outlook в вашем TLS

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

Gmail и Outlook в последние годы стали явно понижать репутацию доменов, у которых соединение TLS нестабильно или отсутствует, — письмо может физически дойти, но попасть в папку «Спам» или задержаться. Для отправителя это выглядит как необъяснимое проседание open rate без изменений в тексте письма.

Отдельная деталь: TLS шифрует канал передачи, а не содержимое письма на диске получателя — это разные уровни защиты. Шифрованный канал не заменяет, например, DKIM или SPF, которые подтверждают подлинность отправителя. Все три механизма работают вместе и оцениваются провайдером в совокупности при решении, куда положить письмо.

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

MTA-STS: как объявить провайдерам, что вы всегда используете шифрование

MTA-STS (Mail Transfer Agent Strict Transport Security) — способ явно сообщить почтовым серверам получателей: наш домен всегда принимает почту только через TLS, и если рукопожатие не удалось, отправлять письмо открытым текстом не нужно, лучше отложить. Политика публикуется в специальной DNS-TXT-записи и файле по HTTPS, который сервер отправителя проверяет перед соединением.

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

Настройка MTA-STS занимает у администратора почтового домена один заход: публикация политики, TXT-запись, HTTPS-эндпоинт с самой политикой. После этого крупные провайдеры вроде Gmail автоматически подхватывают политику при следующей отправке и обеспечивают более строгую проверку соединения.

DANE и DNSSEC: когда это действительно нужно

DANE (DNS-based Authentication of Named Entities) идёт на шаг дальше MTA-STS: политика шифрования публикуется не в обычной TXT-записи, а в защищённой через DNSSEC записи TLSA, что делает подмену почти невозможной даже при компрометации промежуточных DNS-серверов.

Для большинства инфраструктур адресного B2B-аутрича DANE избыточен: он требует включённого DNSSEC на всей зоне домена, что усложняет администрирование и не даёт заметного прироста доставляемости по сравнению с грамотно настроенным MTA-STS. DANE оправдан там, где отправляются письма с повышенными требованиями к конфиденциальности — например, в финансовом или юридическом секторе.

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

Как проверить, что ваш сервер настроен верно

Полная проверка занимает 15–20 минут и стоит делать перед каждым запуском новой инфраструктуры под кампанию, а не только при первичной настройке домена.

• Отправить тестовое письмо на ящик Gmail и посмотреть полные заголовки — строка Received указывает версию TLS соединения
• Проверить публикацию MTA-STS policy через DNS-запрос TXT-записи _mta-sts и доступность файла /.well-known/mta-sts.txt по HTTPS
• Убедиться, что сертификат на почтовом сервере не просрочен и выпущен на актуальное имя хоста
• Проверить версию протокола: TLS 1.2 как минимум, TLS 1.0 и 1.1 уже не признаются провайдерами достаточными
• Сверить DKIM, SPF и DMARC — без них TLS не компенсирует проблемы с аутентификацией отправителя

Частые ошибки настройки TLS в почтовой инфраструктуре

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

• Просроченный или самоподписанный сертификат на почтовом сервере — провайдеры получателей такие соединения понижают в приоритете
• Публикация MTA-STS policy в режиме testing и забытое переключение на enforce
• TLS настроен на исходящей стороне, но не проверен на стороне сервера, принимающего ответы, — входящий канал остаётся уязвимым
• Использование устаревших версий OpenSSL на сервере рассылки без обновления
• Ротация почтовых доменов под новые кампании без переноса уже настроенной конфигурации MTA-STS и DKIM на новый домен

Что делаем в LDM для инфраструктуры адресного аутрича

Для клиентских доменов под адресный аутрич мы проверяем TLS, MTA-STS и полный набор аутентификации (SPF, DKIM, DMARC) как часть предстартового чек-листа, а не разовую настройку при заведении домена. Инфраструктура для холодных писем работает на нескольких прогретых доменах одновременно, и расхождение конфигурации хотя бы на одном из них снижает репутацию всей ротации.

DANE в базовый чек-лист не входит — для объёмов, характерных для персонализированного B2B-аутрича, прирост от него не оправдывает сложность администрирования DNSSEC. Приоритет отдаём тому, что реально двигает метрику: стабильный TLS 1.2+, актуальный MTA-STS в режиме enforce и синхронная настройка аутентификации на каждом домене в ротации.

Как TLS связан с прогревом домена и репутацией отправителя

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

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

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

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

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

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