Что такое SMTP TLS Reporting (TLS-RPT)?

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

SMTP TLS Reporting (TLS-RPT) - это критически важный протокол, который работает вместе с MTA-STS для обеспечения безопасной доставки электронной почты. Предоставляя подробную информацию о проблемах с доставкой электронной почты, TLS-RPT помогает владельцам доменов поддерживать целостность и конфиденциальность их сообщений. В этом подробном руководстве мы рассмотрим, что такое SMTP TLS Reporting, как он работает и почему он необходим для вашей стратегии безопасности электронной почты."

Несколько протоколов помогают шифровать каналы передачи сообщений SMTP, чтобы злоумышленники не смогли перехватить электронную почту. К ним относятся STARTTLS, DANE и MTA-STS. Однако, когда попытки шифрования при использовании этих протоколов терпят неудачу, ваше письмо может быть не доставлено. TLS-RPT (как описано в RFC 8460) обеспечивает механизм обратной связи, позволяющий сообщать о таких сбоях в доставке.

Мы настоятельно рекомендуем использовать TLS-RPT в сочетании с MTA-STS протоколом. Давайте разберемся, как эти протоколы работают вместе, чтобы укрепить безопасность электронной почты.

Что такое TLS-RPT?

TLS-RPT (Transport Layer Security Reporting) - это стандарт, позволяющий сообщать о проблемах с доставкой электронной почты, когда письмо не зашифровано с помощью TLS. Его важность для аутентификации электронной почты совпадает с причиной включения шифрования TLS для электронной почты. 

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

• Проблемы с обработкой политики MTA-STS 
• Причина и тип отказа в доставке
• IP-адреса агентов по передаче и получению электронной почты
• Общее количество успешных и неуспешных сеансов TLS-соединения 

Это обеспечивает видимость ваших каналов электронной почты и позволяет быстрее решать проблемы с доставкой.

Упростите отчетность по SMTP TLS с помощью PowerDMARC!

Как работает отчетность TLS?

При передаче электронной почты по протоколу SMTP шифрование TLS является "оппортунистическим". Это означает, что если зашифрованный канал не может быть согласован, электронная почта все равно отправляется в незашифрованном (обычном) формате. На самом деле, почти 4 десятилетия назад протоколы электронной почты SMTP не поддерживали шифрование TLS. Его пришлось внедрять позже в виде команды STARTTLS. 

Команда STARTTLS выполняется в SMTP-коммуникациях только в том случае, если обе стороны поддерживают шифрование TLS. В противном случае письмо будет отправлено в виде обычного текста. 

Чтобы избавиться от оппортунистического шифрования в SMTP, был введен MTA-STS (RFC 8461). Протокол MTA-STS обеспечивает шифрование электронной почты перед доставкой. Ваш почтовый сервер или агент передачи почты (MTA) договаривается с принимающим сервером о том, поддерживает ли он команду STARTTLS. Если поддерживает, письмо шифруется с помощью TLS и доставляется. В противном случае доставка не выполняется.

Пошаговое объяснение работы TLS-RPT

1. Понимание процесса рукопожатия TLS

Рукопожатие безопасности транспортного уровня (рукопожатие TLS) - это процесс установления безопасного соединения между двумя взаимодействующими агентами передачи почты (MTA). Этот процесс включает в себя следующие шаги: 

• MTA, отправляющий электронную почту, посылает получающему MTA сообщение "Client Hello". Это сообщение содержит такие полезные параметры, как версии TLS и наборы шифров. 
• MTA, принимающий электронную почту, получает это сообщение и отвечает сообщением "Приветствие сервера". Оно содержит выбранную версию TLS и набор шифров. 
• После инициирования рукопожатия TLS принимающий MTA отправляет свой сертификат SSL/TLS, выданный доверенным центром сертификации (Certificate Authority). Этот сертификат содержит открытый ключ.
• Оба взаимодействующих MTA безопасно обмениваются своими криптографическими ключами и устанавливают зашифрованное TLS-соединение. Это обеспечивает безопасную передачу электронной почты между обеими сторонами. 

2. Сценарии неудачного рукопожатия TLS 

TLS Handshakes может не работать по разным причинам: 

• Ошибки сертификации: Просроченные сертификаты или сертификаты, выданные ненадежными центрами сертификации, могут привести к сбоям в рукопожатии TLS.
• Несоответствие версий: Если существует несоответствие между версиями TLS, поддерживаемыми отправляющим и принимающим MTA, это может привести к сбою квитирования.
• Сбои в работе STARTTLS: Если команда STARTTLS выполнена неправильно, это снова может привести к сбою шифрования TLS.
• Применение MTA-STS: Если получатель электронной почты установил режим политики MTA-STS на "применение", неудачное рукопожатие TLS может привести к отклонению сообщения.

3. Формирование и предоставление отчетов

При возникновении сбоев в шифровании TLS сервер-отправитель формирует отчет TLS-RPT и отправляет его владельцу домена для дальнейшей оценки и устранения неполадок. 

Содержание отчета

Сведения об отправляющем сервере: IP-адрес и доменное имя отправителя.

Сведения о принимающем сервере: Домен получателя и информация о сервере электронной почты.

Описание ошибки: Тип и подробности сбоя (например, ошибка сертификата, несоответствие протокола).

Время неудач: Временная метка, когда возникла проблема.

Режим политики: Находится ли домен в режиме "тестирования" или "применения".

Доставка отчетов

Эти TLS-отчеты отправляются в формате JSON на адрес электронной почты, указанный в TXT-записи TLS-RPT DNS владельца домена. 

Роль оппортунистического шифрования в SMTP

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

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

Как MTA-STS и TLS-RPT работают вместе

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

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

Взаимосвязь между DANE и TLS-RPT

DNS-based Authentication of Named Entities (DANE) - это протокол, позволяющий владельцам доменов указывать сертификаты TLS, проверенные через DNSSEC, для предотвращения атак типа "человек посередине". В то время как TLS-RPT отслеживает сбои TLS, DANE гарантирует, что используются только доверенные сертификаты. Таким образом, DANE активно предотвращает атаки злоумышленников на понижение уровня TLS и подмену сертификатов, тем самым сохраняя целостность почтовых сообщений. 

Зачем нужна отчетность SMTP TLS?

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

• Безопасность электронной почты: Выделите риски, связанные с незашифрованной электронной почтой (например, перехват, атаки "человек посередине").
• Compliance: Укажите, как TLS-RPT помогает организациям выполнять нормативные требования по защите данных.
• Доставляемость: Объясните, как TLS-RPT улучшает доставляемость электронной почты, выявляя и устраняя проблемы с шифрованием.

Шаги по настройке TLS-RPT

Вы можете включить TLS-отчетность для своего домена, создав TXT-запись для TLS-RPT и опубликовав ее в DNS. Эта запись должна быть опубликована на поддомене smtp.tls.yourdomain.com

Шаг 1: Создайте запись TLS-RPT (с помощью генератора записей TLS-RPT)

Вы можете зарегистрироваться В PowerDMARC можно зарегистрироваться бесплатно и использовать наш генератор записей TLS-RPT для создания записи.

Шаг 2: Введите адрес электронной почты для отчетности

Введите адрес электронной почты, на который вы хотите получать отчеты SMTP TLS.

Шаг 3: Опубликуйте запись TLS в вашем DNS

Вы можете обратиться к регистратору домена, чтобы создать новую TXT-запись для TLS-RPT. Если вы сами управляете DNS, измените настройки DNS, чтобы включить эту запись.

Синтаксис и пример записи TLS-RPT

Синтаксис: v=TLSRPTv1; rua=mailto:[email protected];

Давайте разберем 2 компонента предоставляемой отчетной записи TLS:

1. v=TLSRPTv1: Этот тег указывает версию используемого протокола TLS-RPT. В данном случае, "TLSRPTv1" указывает на первую версию протокола.
2. rua=mailto:[email protected]: rua означает "Reporting URI(s) for Aggregate Data". Этот тег указывает, куда почтовый сервер получателя должен отправлять агрегированные отчеты TLS.

Вы можете настроить несколько пунктов назначения для получения отчетов. Для нескольких пунктов назначения разделяйте каждый пункт запятой (,). Вы можете использовать "mailto:", чтобы указать адрес электронной почты для этого шага, или указать MTA отправлять отчеты через POST на URL-адреса конечных точек, используя "https:" в поле rua=. Если вы используете "https:" , убедитесь, что поле определяет URL-адрес веб-сервера с поддержкой HTTPS и действующим сертификатом. И "mailto:", и "https:" также можно использовать в одной записи, разделяя их запятой. 

Пример: v=TLSRPTv1; rua=mailto:[email protected],https://tlsreport.example.com;

Примечание: На практике вы замените "yourdomain.com" на реальное имя домена, в котором вы хотите получать эти отчеты.

Понимание отчетов TLS-RPT JSON

Структура отчета TLS-RPT JSON

Отчеты TLS отправляются в формате JSON. Ниже приведен пример того, как может выглядеть отчет TLS в формате JSON:

{

  "organization-name": "Organization Inc.",

  “date-range”: {

    "start-datetime": “2020-10-22T00:00:00Z”,

    "end-datetime": “2020-10-22T23:59:59Z”

  },

  "contact-info": "[email protected]",

  "report-id": “2020-10-22T00:00:00Z_domain.com”,

  "policies": [

    {

      “policy”: {

        "policy-type": "sts",

        "policy-string": [

          "Версия: STSv1",

          "Режим: тестирование",

          "mx: mx.domain.com",

          "mx: mx2.domain.com",

          "mx: mx3.domain.com",

          "max_age: 604800"

        ],

        "policy-domain": "domain.com".

      },

      “summary”: {

        "total-successful-session-count": 15,

        "total-failure-session-count": 0

      }

Ключевые поля и их значение

Вот разбивка основных полей этого JSON TLS-отчета:

Формат отчета TLS-RPT JSON и интерпретация данных

Метаданные отчета

{

  "organization-name": "Организация отправляющего MTA",

  “date-range”: {

    "start-datetime": “2025-02-25T00:00:00Z”,

    "end-datetime": “2025-02-25T23:59:59Z”

  },

  "report-id": “unique-report-id-12345”

}

В этом разделе отчета JSON содержится основная информация, такая как название организации отправителя электронной почты, дата и время начала, дата и время окончания, а также уникальный идентификатор для созданного отчета TLS.

Подробности политики

“policy”: {

  "policy-type": "sts",

  "policy-string": "mode: enforce; mx: mail.example.com; max_age: 604800;"

}

В этом разделе описывается используемый режим политики MTA-STS, который в данном случае является режимом Enforce, но его также можно установить в режим Testing. 

Подробности отказа

"failure-details": [

  {

    "result-type": "certificate-expired",

    "sending-mta": "smtp.example.org",

    "receiving-mta": "mail.example.com",

    "failure-reason": "TLS handshake failed due to expired certificate".

  }

]

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

Причины сбоев шифрования TLS и устранение неполадок

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

1. Вопросы сертификации

сертификат_истёк

Срок действия сертификата, представленного удаленным сервером, истек. Это делает его недостоверным для шифрования. В этом случае необходимо обновить сертификат.

сертификат_не_действительный_еще

Сертификат, представленный удаленным сервером, еще не действителен. Это может быть связано с неправильным временем сервера или преждевременным использованием сертификата. В этом случае лучше всего обратиться к поставщику сертификатов.

сертификат_отменён

Сертификат, представленный удаленным сервером, был отозван центром сертификации по соображениям безопасности. В этом случае лучше всего обратиться к поставщику сертификатов.

no_valid_signature

Цепочка сертификатов, представленная удаленным сервером, не вызывает доверия у почтового сервера или клиента отправителя, что указывает на потенциальную угрозу безопасности. В этом случае лучше всего обратиться к поставщику сертификатов.

неподдерживаемый_сертификат

В сертификате, представленном удаленным сервером, используются алгоритмы шифрования или длина ключа, которые не поддерживаются почтовым сервером отправителя, что препятствует установлению безопасного соединения. В этом случае лучше всего обратиться к поставщику сертификатов.

2. Несоответствие имени хоста и идентификатора

несоответствие имени хоста

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

Вы можете проверить MX-записи в файле политики MTA-STS, чтобы убедиться, что они совпадают с MX-записями для домена.

3. Вопросы рукопожатия и протокола

рукопожатие_неудача

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

4. Вопросы политики MTA-STS

mta_sts_policy_not_found

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

mta_sts_policy_invalid

Этот сбой происходит, когда политика MTA-STS, найденная в DNS для домена получателя, недействительна, содержит ошибки или не соответствует спецификации MTA-STS. Просмотрите файл политики MTA-STS. Укажите подходящий режим политики MTA-STS. Это может быть None, Enforce или Testing. Это указывает серверам-отправителям, как обрабатывать сообщения электронной почты, в которых произошли сбои при проверке политики MTA-STS. 

mta_sts_policy_fetch_error

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

mta_sts_connection_failure

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

mta_sts_invalid_hostname

Этот сбой возникает, когда имя хоста почтового сервера получателя, указанное в политике MTA-STS, не совпадает с реальным именем хоста сервера. Необходимо проверить MX-записи в файле политики MTA-STS, чтобы убедиться, что они совпадают с MX-записями домена.

Лучшие практики внедрения TLS-RPT

Регулярно отслеживайте отчеты TLS

Отчеты TLS следует регулярно отслеживать, чтобы не пропустить недоставленные сообщения. Для этого можно вручную отслеживать почтовый ящик на предмет отчетов в формате JSON или использовать инструмент для анализа отчетов, например PowerTLS-RPT.

Убедитесь, что политика MTA-STS настроена должным образом

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

Оперативно устраняйте сбои в шифровании

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

Используйте безопасные версии протокола TLS

Использование только последних и поддерживаемых версий протокола TLS необходимо для предотвращения нежелательных сбоев в шифровании. 

Упрощенная отчетность по SMTP TLS с помощью PowerDMARC

SMTP TLS-отчетность PowerDMARC - это повышение уровня безопасности и упрощение работы с размещенным сервисом.

Переведенные отчеты TLS

Сложные отчеты TLS-RPT JSON преобразуются в упрощенную информацию, которую можно просмотреть за несколько секунд или прочитать подробно. 

Проблемы автоопределения

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

В платформе PowerDMARC мне нравится не что-то одно, а простота использования и понятная компоновка с полным набором функций, позволяющих управлять DMARC на хостинге, сглаживание SPF, возможность легко расширить SPF для проверки специфики записи и даже полная поддержка MTA-STS и TLS-RPT!

Дилан Б (владелец бизнеса)

Часто задаваемые вопросы по безопасности транспортного уровня

1. Что означает TLS?

TLS расшифровывается как Transport Layer Security. 

2. Кто выдает сертификаты TLS? 

Центры сертификации (ЦС) могут выдавать сертификаты TLS. Процесс выдачи сертификата включает проверку личности владельца сертификата. При успешной идентификации сертификат выдается. 

3. Зачем нужен сертификат TLS?

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

4. Каков текущий стандарт TLS?

TLS 1.3 является последней версией Transport Layer Security. TLS-RPT может быть реализован с использованием любой версии TLS. Это могут быть как старые версии протокола, так и будущие. Версия обычно определяется такими критериями, как возможности взаимодействующих серверов. 

Дополнительные ресурсы

1. Генератор записей TLS-RPT 
2. Программа проверки записей TLS-RPT
3. МТА-СТС 
4. DMARC

• О сайте
• Последние сообщения

Юнес Тарада

Эксперт по безопасности доменов и электронной почты в PowerDMARC

Юнес - руководитель группы операций в PowerDMARC, обладающий экспертными знаниями в области аутентификации и безопасности электронной почты. Юнес имеет сертификат Microsoft Azure Administrator Associate, а также сертификаты CompTIA A+ и многие другие.

Последние сообщения Юнеса Тарады (см. все)

• Объяснение DMARCbis — что меняется и как подготовиться - 16 апреля 2026 г.
• Неверный формат серийного номера SOA: причины и способы устранения - 13 апреля 2026 г.
• Как отправлять защищенные письма в Gmail: пошаговое руководство - 7 апреля 2026 г.