Широко известным интернет-стандартом, позволяющим повысить безопасность соединений между серверами SMTP (Simple Mail Transfer Protocol), является SMTP Mail Transfer Agent-Strict Transport Security (MTA-STS). MTA-STS решает существующие проблемы в SMTP безопасность электронной почты за счет применения шифрования TLS при передаче. Шифрование в SMTP является необязательным, что означает, что электронная почта может быть отправлена в открытом виде. MTA-STS позволяет поставщикам почтовых услуг внедрять Transport Layer Security (TLS) для защиты SMTP-соединений и указывать, должны ли отправляющие SMTP-серверы отказываться доставлять письма на MX-хосты, которые не поддерживают TLS с помощью надежного сертификата сервера. Доказано, что она успешно противодействует атакам на понижение уровня TLS и атакам типа "человек посередине" (MITM).
Ключевые выводы
- Изначально SMTP не обладал достаточной безопасностью, а затем получил опциональное шифрование через STARTTLS, но оставался уязвимым для MITM и атак на понижение.
- MTA-STS повышает безопасность электронной почты за счет обязательного использования TLS-шифрования при обмене данными между серверами, предотвращая возврат к открытому тексту.
- Реализация включает в себя файл политики, размещенный через HTTPS, и запись DNS, определяющую правила и доверенные почтовые серверы.
- MTA-STS работает в режимах (None, Testing, Enforce), позволяющих постепенно развертывать и внедрять политики шифрования.
- TLS-RPT дополняет MTA-STS, предоставляя диагностические отчеты о сбоях TLS-соединений, помогая в устранении неполадок и улучшая качество доставки.
История и происхождение MTA-STS
В 1982 году был впервые определен протокол SMTP, который не содержал никакого механизма обеспечения безопасности на транспортном уровне для защиты связи между агентами передачи почты. Однако в 1999 году в SMTP была добавлена команда STARTTLS, которая, в свою очередь, поддерживала шифрование электронной почты между серверами, обеспечивая возможность преобразования незащищенного соединения в защищенное, зашифрованное с помощью протокола TLS.
В таком случае вам должно быть интересно, почему SMTP принял STARTTLS для защиты соединений между серверами, зачем потребовался переход на MTA-STS и что он вообще дает. Давайте разберемся в этом в следующих разделах этого блога!
Упростите безопасность с помощью PowerDMARC!
Что такое MTA-STS? (Mail Transfer Agent Strict Transport Security - объяснение)
MTA-STS расшифровывается как Mail Transfer Agent - Strict Transport Security. Это стандарт безопасности, обеспечивающий безопасную передачу электронных сообщений по зашифрованному SMTP-соединению. Аббревиатура MTA означает Message Transfer Agent (агент передачи сообщений) - программа, передающая электронные сообщения между компьютерами. Аббревиатура STS означает Strict Transport Security - протокол, используемый для реализации стандарта. Агент передачи почты (MTA) или агент безопасной передачи сообщений (SMTA), поддерживающий MTA-STS, работает в соответствии с этой спецификацией и обеспечивает безопасный сквозной канал для отправки электронной почты по незащищенным сетям.
Протокол MTA-STS позволяет SMTP-клиенту проверить идентичность сервера и убедиться, что он не подключается к самозванцу, требуя от сервера предоставить отпечаток его сертификата в процессе квитирования TLS. Затем клиент проверяет сертификат в хранилище доверия, содержащем сертификаты известных серверов.
Введение в систему защиты электронной почты MTA-STS
Стандарт MTA-STS был введен для устранения пробелов в безопасности при передаче сообщений по протоколу SMTP. Как стандарт безопасности, MTA-STS обеспечивает безопасную передачу электронных писем через зашифрованное SMTP-соединение.
Аббревиатура MTA означает Message Transfer Agent - программу для передачи электронных сообщений между компьютерами. Аббревиатура STS означает Strict Transport Security - протокол, используемый для реализации стандарта. Агент передачи почты (MTA) или агент безопасной передачи сообщений (SMTA), поддерживающий MTA-STS, работает в соответствии с этой спецификацией и обеспечивает безопасный сквозной канал для отправки электронной почты по незащищенным сетям.
Протокол MTA-STS позволяет SMTP-клиенту проверить идентичность сервера и убедиться, что он не подключается к самозванцу, требуя от сервера предоставить отпечаток его сертификата в процессе квитирования TLS. Затем клиент проверяет сертификат в хранилище доверия, содержащем сертификаты известных серверов.
Необходимость перехода на принудительное шифрование TLS
STARTTLS не был совершенен, и ему не удалось решить две основные проблемы: первая заключается в том, что он является необязательной мерой, поэтому STARTTLS не может предотвратить атаки типа "человек посередине" (MITM). Это связано с тем, что MITM-злоумышленник может легко модифицировать соединение и предотвратить обновление шифрования. Вторая проблема заключается в том, что даже если STARTTLS реализован, нет способа проверить подлинность сервера-отправителя, как в случае с SMTP почтовые серверы не проверяют сертификаты.
Хотя сегодня большинство исходящих сообщений электронной почты защищено с помощью Transport Layer Security (TLS) шифрованием, отраслевым стандартом, принятым даже в потребительской электронной почте, злоумышленники все равно могут помешать и подделать вашу почту еще до того, как она будет зашифрована. Поскольку для обеспечения обратной совместимости в SMTP пришлось внедрить систему безопасности, добавив команду STARTTLS для инициирования шифрования TLS, в случае если клиент не поддерживает TLS, связь возвращается к чистому тексту. Таким образом, электронная почта в процессе пересылки может стать жертвой атак типа MITM, когда злоумышленники могут подслушивать ваши сообщения, изменять и подделывать информацию, заменяя или удаляя команду шифрования (STARTTLS), в результате чего сообщение возвращается к открытому тексту. MITM-злоумышленник может просто заменить STARTTLS на мусорную строку, которую клиент не сможет идентифицировать. Таким образом, клиент легко возвращается к отправке электронной почты в открытом виде. Если вы не передаете электронную почту по защищенному соединению, ваши данные могут быть скомпрометированы или даже изменены и подделаны киберзлоумышленником.
Именно здесь на помощь приходит MTA-STS, который решает эту проблему, гарантируя безопасный транзит ваших писем, а также успешно противодействуя атакам MITM. MTA-STS заставляет передавать электронные письма по зашифрованному пути TLS, а в случае невозможности установить зашифрованное соединение электронное письмо вообще не доставляется, вместо того чтобы быть доставленным в открытом виде. Кроме того, MTA хранят файлы политик MTA-STS, что усложняет злоумышленникам задачу запуска атаку с подменой DNS. Основной целью является повышение безопасности на транспортном уровне при SMTP-коммуникациях и обеспечение конфиденциальности почтового трафика. Кроме того, шифрование входящих и исходящих сообщений повышает информационную безопасность, используя криптографию для защиты электронной информации.
Настройте MTA-STS с помощью PowerDMARC!
Как работает МТА-СТС?
Протокол MTA-STS развертывается с помощью DNS-записи, определяющей, что почтовый сервер может получать файл политики с определенного поддомена. Этот файл политики загружается по протоколу HTTPS и аутентифицируется с помощью сертификатов, а также списка имен почтовых серверов получателя. Реализовать MTA-STS проще на стороне получателя, чем на стороне отправителя, поскольку она должна поддерживаться программным обеспечением почтового сервера. Хотя некоторые почтовые серверы поддерживают MTA-STS, например PostFixно не все. MTA-STS позволяет серверам указывать, что они поддерживают TLS, что позволит им не закрывать (т. е. не отправлять письмо), если переговоры о повышении TLS не состоятся, тем самым делая невозможным проведение атаки на понижение TLS.
Основные поставщики почтовых услуг, такие как Microsoft, Клятва и Google поддерживают MTA-STS. Google Gmail уже принял политику MTA-STS в последнее время. MTA-STS устранила недостатки в безопасности соединения электронной почты, сделав процесс обеспечения безопасности соединений легким и доступным для поддерживаемых почтовых серверов.
Соединения от пользователей к почтовым серверам обычно защищены и зашифрованы с помощью протокола TLS, однако, несмотря на это, до внедрения MTA-STS в соединениях между почтовыми серверами не хватало безопасности. С ростом осведомленности о безопасности электронной почты в последнее время и поддержкой со стороны основных почтовых провайдеров по всему миру, ожидается, что в ближайшем будущем большинство соединений между серверами будут зашифрованы. Кроме того, MTA-STS эффективно гарантирует, что киберпреступники в сетях не смогут прочитать содержимое электронной почты.
Файл политики МТА-СТС
Файл политики MTA-STS - это текстовый файл конфигурации MTA-STS, который размещается на веб-сервере домена по адресу HTTPS: Он определяет правила для установления безопасных соединений между почтовыми серверами, применения шифрования TLS и действий, которые необходимо предпринять, если безопасное соединение не может быть установлено.
https://mta-sts.<domain>//.well-known/mta-sts.txt
Структура файла политики MTA-STS
Поля | Описание | Пример |
версия | Версия формата политики MTA-STS | STS1 |
режим | Уровень применения политики из 3 доступных вариантов: нет, тестирование и применение | тестирование |
mx | Список действующих серверов Mail Exchange (MX) домена | mail.domain.com |
max-age | Продолжительность в секундах, в течение которой политика должна кэшироваться на внешних почтовых серверах | 86400 |
Пример политики MTA-STS
версия: STSv1
режим: принудительный
mx: mail.example.com
mx: backupmail.example.com
max_age: 86400
Необходимые условия для развертывания MTA-STS
Прежде чем приступить к настройке MTA-STS, вам понадобится следующее:
- Зарегистрированное доменное имя
- Действительные сертификаты TLS
- Сертификаты TLS должны быть выпущены доверенным центром сертификации
- Сертификаты должны быть актуальными и не просроченными
- Должен быть как минимум TLS версии 1.2 или выше
- TXT-запись DNS для MTA-STS
- Веб-сервер HTTPS
- Почтовый сервер настроен на использование TLS
- Имя хоста почтового сервера, соответствующее записям в поле mx вашего файла политики
- Тестовая среда или размещенная служба MTA-STS для отслеживания журналов и внесения необходимых корректировок
Шаги по настройке MTA-STS для вашего домена
Чтобы настроить MTA-STS для вашего домена, выполните следующие действия:
- Проверьте, есть ли в вашем домене существующие конфигурации MTA-STS. Если вы используете Google Workspace для своей электронной почты, вы можете легко сделать это с помощью этого руководства.
- Создайте и опубликуйте политику MTA-STS, настроенную отдельно для каждого домена. Файл политики MTA-STS определяет почтовые серверы с поддержкой MTA-STS, используемые этим доменом.
- После создания файла политики необходимо загрузить его на общедоступный веб-сервер, к которому могут легко получить доступ удаленные серверы.
- Наконец, создайте и опубликуйте DNS-запись MTA-STS (TXT-запись "_mta-sts"), чтобы указать принимающим серверам, что ваши письма должны быть зашифрованы TLS, чтобы считаться подлинными, и доступ к почтовому ящику получателя должен быть разрешен только в том случае, если верно первое.
Если у вас есть активный файл политики, внешние почтовые серверы не будут разрешать доступ к электронной почте без защищенного соединения.
3 режима политики MTA-STS: Нет, Тестирование и Усиление
Для режимов политики MTA-STS доступны следующие три значения:
- Нет: Эта политика сводит на нет вашу конфигурацию MTA-STS, поскольку внешние серверы будут считать протокол неактивным для домена.
- Тестирование: При использовании этой политики электронные письма, переданные по незашифрованному соединению, не будут отклонены, вместо этого при включенном TLS-RPT вы будете продолжать получать отчеты TLS о пути доставки и поведении электронной почты.
- Обеспечить: Наконец, при включении политики Enforce электронные письма, переданные через незашифрованное SMTP-соединение, будут отклонены вашим сервером.
MTA-STS предлагает защиту от :
- нападения даунграйдов
- Атаки типа "человек посередине" (MITM)
- Он решает множество проблем с безопасностью SMTP, включая просроченные сертификаты TLS, отсутствие поддержки безопасных протоколов и сертификаты, выданные ненадежными третьими сторонами.
Отчеты TLS: Мониторинг недостатков в доставке электронной почты после настройки MTA-STS
TLS-RPT (Transport Layer Security Reporting) - это протокол, позволяющий владельцам доменов получать подробные отчеты о сбоях TLS-шифрования в почтовых сообщениях. TLS Reporting работает в связке с MTA-STS. Он позволяет сообщать о проблемах с подключением к TLS, с которыми сталкиваются приложения, отправляющие электронную почту, и обнаруживать неправильные конфигурации. Он позволяет сообщать о проблемах с доставкой электронной почты, возникающих, когда письмо не зашифровано с помощью TLS. В сентябре 2018 года стандарт был впервые задокументирован в RFC 8460.
Основные характеристики включают:
- Отчеты об ошибках: Предоставляет подробные отчеты о проблемах доставки или сбоях, вызванных проблемами TLS, такими как просроченные сертификаты или устаревшие версии TLS, а также сбоями TLS-шифрования. Как только вы включите TLS-RPT, совместимые агенты передачи почты начнут отправлять диагностические отчеты о проблемах доставки электронной почты между взаимодействующими серверами на указанный почтовый домен. Отчеты обычно отправляются раз в день и содержат сведения о политиках MTA-STS, соблюдаемых отправителями, статистику трафика, а также информацию о сбоях или проблемах в доставке электронной почты.
- Наглядность: Помогает отслеживать проблемы, связанные с реализацией MTA-STS и доставкой электронной почты. TLS-RPT обеспечивает улучшенную видимость всех каналов электронной почты, что позволяет лучше понять все, что происходит в вашем домене, включая сообщения, которые не удается доставить.
- Повышение безопасности электронной почты: Устранение ошибок, связанных с неудачными переговорами по шифрованию TLS, позволяет повысить общую эффективность настройки MTA-STS и тем самым более эффективно предотвращать кибератаки. Кроме того, программа предоставляет подробные диагностические отчеты, позволяющие выявить корень проблемы доставки электронной почты и устранить ее без промедления.
Простое развертывание MTA-STS с помощью PowerDMARC
MTA-STS требует наличия веб-сервера с поддержкой HTTPS и действующим сертификатом, записей DNS и постоянного обслуживания. Внедрение MTA-STS может быть сложной задачей, которая сопряжена со сложностями при внедрении. От создания файлов политик и записей до обслуживания веб-сервера и сертификатов хостинга - это длительный процесс. PowerDMARC анализатор DMARC делает вашу жизнь намного проще, обрабатывая все это за вас, полностью в фоновом режиме. Как только мы поможем вам настроить его, вам больше никогда не придется об этом думать.
С помощью PowerDMARC вы можете развернуть Hosted MTA-STS в своей организации без хлопот с публичными сертификатами. Мы поможем вам:
- Публикуйте свои DNS CNAME записи всего несколькими щелчками мыши.
- Обновление политики и оптимизация записи одним щелчком мыши без необходимости доступа к настройкам DNS.
- Проверьте версию политики и валидность сертификата
- Обнаружение сбоев в работе приложений политики MTA-STS
- Разместите текстовый файл политики MTA-STS
- Возьмите на себя ответственность за обслуживание веб-сервера политики и размещение сертификатов
- С помощью упрощенных отчетов можно быстрее обнаружить сбои, успешные соединения и проблемы с подключением.
- Обеспечьте соответствие RFC и поддержку новейших стандартов TLS
PowerDMARC делает процесс внедрения SMTP TLS Reporting (TLS-RPT) простым и быстрым. Мы преобразуем сложные JSON-файлы, содержащие отчеты о проблемах с доставкой электронной почты, в простые и понятные документы (для каждого результата и источника отправки), которые вы сможете легко понять.
Зарегистрируйтесь сегодня, чтобы быстро обеспечить отправку электронной почты на ваш домен по зашифрованному TLS-соединению и защитить ваше соединение от MITM и других кибер-атак.
"`
- Что такое DMARC? Простое руководство по защите электронной почты - 11 июля 2025 г.
- Как читать отчеты DMARC: Типы, инструменты и советы - 10 июля 2025 г.
- Как создать и опубликовать запись DMARC - 3 марта 2025 г.