Как настроить MTA-STS и TLS-RPT для почты

Как настроить MTA-STS и TLS-RPT для защиты электронной почты

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

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

1. Убедитесь, что почтовый хостинг готов

Для начала проверьте текущие MX-записи домена. Составьте список всех указанных в них имён хостов, включая серверы резервной или региональной доставки. Если входящую почту обслуживает провайдер, уточните у него, какие имена MX нужно включить в политику MTA-STS и поддерживает ли каждый из этих хостов TLS с действительным сертификатом.

Проверяйте именно имена хостов, а не только название провайдера. Например, MX-записи домена могут указывать на mx1.mail.example.com и mx2.mail.example.com, хотя провайдер использует и другие хосты, не указанные для вашего домена. Политика должна охватывать все имена MX-хостов, которые могут принимать почту для домена.

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

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

2. Укажите адрес для отчётов TLS-RPT

Прежде чем публиковать DNS-запись, решите, куда будут поступать отчёты. Это может быть почтовый ящик, принимающий отчёты, или сервис TLS-отчётности, который предоставит адрес электронной почты либо HTTPS-адрес. Убедитесь, что за этим адресом следят и что ваша почтовая система принимает туда входящие отчёты.

Опубликуйте TXT-запись для _smtp._tls.example.com, заменив example.com своим доменом. Для отправки отчётов на почту используйте значение такого формата: v=TLSRPTv1; rua=mailto:tls-reports@example.com. Если сервис отчётности предоставил другой адрес, укажите точно тот URI, который он выдал.

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

Из-за кэширования записей в соответствии с TTL DNS-изменения могут вступить в силу не сразу. После публикации записи проверьте её через авторитетный DNS-сервер и общедоступный резолвер: оба должны возвращать нужное значение TXT. Опечатка в имени записи может сделать адрес недоступным для отправителей.

3. Разместите файл политики MTA-STS

Разместите файл политики по адресу https://mta-sts.example.com/.well-known/mta-sts.txt, заменив example.com своим доменом. Адрес должен быть доступен по HTTPS, а сертификат — действителен для имени хоста mta-sts.example.com. Файл по обычному адресу главной страницы сайта не подойдёт.

Политика представляет собой обычный текстовый файл. Для первичного тестирования используйте поля, например:

• version: STSv1
• mode: testing
• mx: mx1.mail.example.com
• mx: mx2.mail.example.com
• max_age: 86400

Замените примеры имён MX на реальные входящие хосты вашего домена. Значение max_age задаёт срок в секундах, в течение которого отправитель может хранить политику в кэше; в примере выше это одни сутки. Более короткий срок на начальном этапе упростит корректировку тестовой политики, а при более длительном сроке отправители могут хранить её дольше.

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

4. Опубликуйте запись для обнаружения MTA-STS

Для настройки MTA-STS для домена отправители находят политику по TXT-записи для _mta-sts.example.com. В её значении указываются версия и идентификатор политики, например: v=STSv1; id=20261104a. Выберите идентификатор, который можно отследить в журнале изменений, и не используйте повторно старое значение.

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

Публикуйте запись только после того, как файл политики станет доступен по нужному URL. Затем проверьте TXT-запись и откройте URL через внешнее подключение. DNS-запись и файл должны соответствовать текущей конфигурации: новый идентификатор, указывающий на отсутствующий или устаревший файл, всё равно означает, что настройка работает неправильно.

5. Проверьте обнаружение, политику и соответствие MX-хостов

Проверьте каждый компонент отдельно. Запросите TXT-записи _smtp._tls и _mta-sts, откройте URL политики по HTTPS и сравните каждую строку mx: с актуальными MX-записями. Такая проверка из трёх частей помогает выявить ошибки, которые нельзя обнаружить одним лишь запросом DNS.

Убедитесь, что HTTPS-соединение использует доверенный сертификат для имени хоста MTA-STS, а файл содержит ожидаемые поля. Затем проверьте поддержку TLS и действительность сертификата для точного имени каждого MX-хоста. Если у провайдера несколько входящих MX-хостов, протестируйте каждый из них, а не предполагайте, что конфигурация сертификатов у всех одинаковая.

Зафиксируйте результаты: значения DNS-записей, идентификатор политики, имена MX-хостов и дату проверки. Это даст следующему администратору точку отсчёта, если позже в отчётах появятся ошибки. Дополнительные материалы о настройке электронной почты можно добавить в список источников команды, подписавшись на RSS-ленту блога YourTrend.

6. Изучите отчёты, прежде чем включать принудительное применение политики

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

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

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

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

7. Включите принудительное применение, отслеживайте результаты и поддерживайте настройку

Когда список MX-хостов, сертификаты, HTTPS-политика и результаты тестирования будут готовы, смените режим политики с testing на enforce. Опубликуйте обновлённый файл политики и задайте новый идентификатор _mta-sts. После обновления проверьте их извне своей сети, а затем продолжайте отслеживать отчёты TLS-RPT и журналы доставки почты.

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

Задокументируйте порядок обслуживания вместе с URL политики и DNS-записями. При смене MX-хоста обновите политику, прежде чем полагаться на новый хост; после обновления сертификата проверьте, для каких имён он действителен, и убедитесь в корректности цепочки доверия. Если при принудительном применении обнаружится проблема, возврат к режиму тестирования может снизить влияние политики. При этом обновите идентификатор и проверьте, что новая версия файла доступна по нужному адресу.

Назначьте ответственного за проверку почтового ящика или сервиса отчётности, а также за отслеживание изменений DNS и сертификатов. Если вы публикуете для коллег рабочие заметки или новости о почтовом сервисе, они могут подписаться и на RSS-ленту блога YourTrend. Назначенный ответственный и задокументированный порядок смены MX-хостов упростят подготовку к следующему продлению сертификата или переходу к другому провайдеру.