TLS, MTA-STS и доверие к отправителю: как шифрование почты влияет на доставляемость

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

Что именно шифрует TLS в почте и чего он не делает

TLS (Transport Layer Security) в почте работает на уровне SMTP-соединения между двумя серверами: когда ваш почтовый сервер передаёт письмо серверу Gmail или Яндекса, оба договариваются о шифрованном канале, и дальше письмо передаётся в зашифрованном виде по этому конкретному отрезку пути. Это называется STARTTLS — сервер сначала пробует установить защищённое соединение и только потом передаёт содержимое.

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

Это принципиально отличается от end-to-end шифрования вроде PGP или S/MIME, где содержимое зашифровано ключом получателя и недоступно даже промежуточным серверам. Для рассылок и делового аутрича end-to-end шифрование почти никогда не используется — оно ломает совместимость с большинством почтовых клиентов и не нужно для деловой переписки. Разговор про доставляемость всегда о transport-уровне TLS.

Почему Gmail показывает открытый замок и что это значит для отправителя

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

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

• Проверьте, что сервер поддерживает STARTTLS и актуальную версию протокола (TLS 1.2 как минимум, 1.3 — предпочтительно)
• Убедитесь, что сертификат на MX-записи не просрочен и выдан на правильное имя хоста
• Отключите устаревшие шифры и версии SSL/TLS, которые современные почтовые провайдеры считают ненадёжными
• Проверьте настройку у своего провайдера SMTP-релея или ESP — часто TLS уже включён по умолчанию, но стоит подтвердить это тест-письмом

MTA-STS: защита от downgrade-атаки и следующий шаг зрелости

Проблема STARTTLS в его базовом виде — оппортунистичность: если атакующий вклинивается в соединение и делает вид, что TLS недоступен, оба сервера могут тихо согласиться передать письмо открытым текстом. Это называется downgrade-атакой, и для обычной переписки риск невысок, но для домена, который отправляет заметный объём деловой почты, это дыра в репутации.

MTA-STS (Mail Transfer Agent Strict Transport Security) — политика на уровне DNS и веб-сервера, которая явно говорит принимающим серверам: «для этого домена TLS обязателен, соединения без него отклоняй». Это убирает возможность тихого отката на незащищённую передачу и повышает уровень доверия к домену у крупных почтовых провайдеров.

TLS-RPT (TLS Reporting) идёт в паре с MTA-STS и присылает отчёты о неудачных попытках установить TLS-соединение с вашим доменом — полезно, чтобы вовремя заметить проблему на стороне своего сервера, а не узнать о ней постфактум по упавшей доставляемости.

Как это соотносится с SPF, DKIM и DMARC

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

На практике почтовые провайдеры смотрят на совокупность сигналов: прошла ли аутентификация по DKIM и SPF, совпадает ли DMARC-политика, установлено ли TLS-соединение, какая репутация у IP и домена, какое поведение получателей на предыдущих письмах (открытия, жалобы, удаления без открытия). Провал по одному пункту редко фатален сам по себе, но чем больше сигналов недоверия накапливается одновременно, тем выше шанс попасть в спам или получить визуальное предупреждение.

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

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

Типичные ошибки при настройке шифрования у отправителей холодных писем

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

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

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

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

Практический чек-лист для отправителя холодных писем

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

• STARTTLS включён и работает на почтовом сервере или у SMTP-провайдера — проверить тестовым письмом на несколько крупных провайдеров
• Сертификат актуален, версия протокола не ниже TLS 1.2
• SPF, DKIM, DMARC настроены и проходят проверку (доступно бесплатными онлайн-чекерами заголовков письма)
• MTA-STS и TLS-RPT настроены, если домен отправляет заметный регулярный объём деловой почты
• Отслеживается репутация домена и IP через панели провайдеров (Google Postmaster Tools и аналоги)
• Настройка проверяется повторно после смены SMTP-провайдера, миграции почтового сервера или обновления сертификата, а не только при первом запуске

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