Как работает проверка подлинности именованных сущностей (DANE) на основе SMTP dns

Статья
08/12/2023

Протокол SMTP — это протокол main, используемый для передачи сообщений между почтовыми серверами, и по умолчанию не является безопасным. Протокол TLS был представлен несколько лет назад для поддержки зашифрованной передачи сообщений по протоколу SMTP. Это обычно используется оппортунистически, а не в качестве требования, оставляя много трафика электронной почты в ясном тексте, уязвим для перехвата гнусными субъектами. Кроме того, SMTP определяет IP-адреса целевых серверов через общедоступную инфраструктуру DNS, которая подвержена спуфингам и атакам типа "человек в середине" (MITM). Эта уязвимость привела к созданию многих новых стандартов для повышения безопасности при отправке и получении электронной почты, одним из которых является проверка подлинности именованных сущностей (DANE) на основе DNS.

DANE для SMTP RFC 7672 использует запись TLSA в наборе записей DNS домена, чтобы сообщить домену и его почтовым серверам о поддержке DANE. Если запись TLSA отсутствует, разрешение DNS для потока обработки почты будет работать в обычном режиме без попыток проверки DANE. Запись TLSA безопасно сигнализирует о поддержке TLS и публикует политику DANE для домена. Таким образом, отправка почтовых серверов может успешно пройти проверку подлинности допустимых получающих почтовых серверов с помощью SMTP DANE. Такая проверка подлинности делает ее устойчивой к атакам на более раннюю версию и MITM. DANE имеет прямые зависимости от DNSSEC, который работает путем цифровой подписи записей для поиска DNS с использованием шифрования с открытым ключом. Проверки DNSSEC выполняются на рекурсивных сопоставителях DNS, DNS-серверах, которые выполняют DNS-запросы для клиентов. DNSSEC гарантирует, что записи DNS не будут изменены и являются подлинными.

После возвращения записей ресурсов MX, A/AAAA и DNSSEC для домена рекурсивного сопоставителя DNS в качестве подлинности DNSSEC отправляющий почтовый сервер запросит запись TLSA, соответствующую записи узла MX. Если запись TLSA присутствует и проверена подлинность с помощью другого проверка DNSSEC, рекурсивный сопоставитель DNS вернет запись TLSA на отправляющий почтовый сервер.

После получения подлинной записи TLSA отправляющий почтовый сервер устанавливает SMTP-подключение к узлу MX, связанному с подлинной записью TLSA. Отправляющий почтовый сервер попытается настроить TLS и сравнить сертификат TLS сервера с данными в записи TLSA, чтобы убедиться, что почтовый сервер назначения, подключенный к отправителю, является допустимым принимающим почтовым сервером. Сообщение будет передано (по протоколу TLS) в случае успешной проверки подлинности. Если проверка подлинности завершается ошибкой или если протокол TLS не поддерживается конечным сервером, Exchange Online повторите весь процесс проверки, начиная с DNS-запроса для того же целевого домена через 15 минут, а затем через 15 минут, а затем каждый час в течение следующих 24 часов. Если проверка подлинности по-прежнему завершается ошибкой после 24 часов повтора, срок действия сообщения истечет, и отправителю будет создан отчет об ошибке с информацией об ошибке.

Совет

Если вы не являетесь клиентом E5, используйте 90-дневную пробную версию решений Microsoft Purview, чтобы узнать, как дополнительные возможности Purview могут помочь вашей организации управлять безопасностью данных и соответствием требованиям. Начните сейчас, перейдя в центр пробных версий на портале соответствия требованиям Microsoft Purview. Сведения о регистрации и условиях пробной версии.

Что такое компоненты DANE?

Запись ресурса TLSA

Запись TLS Authentication (TLSA) используется для связывания сертификата или открытого ключа сервера X.509 с доменным именем, содержащим запись. Записи TLSA могут быть доверенными только в том случае, если DNSSEC включен в вашем домене. Если для размещения домена используется поставщик DNS, dnsSEC может быть предложенным параметром при настройке домена с ним. Дополнительные сведения о подписывание зоны DNSSEC см. по этой ссылке: Обзор DNSSEC | Документация Майкрософт.

Пример записи TLSA:

Существует четыре настраиваемых поля, уникальных для типа записи TLSA:

Поле использования сертификата. Указывает, как отправляющий почтовый сервер должен проверять сертификат целевого почтового сервера.

Значение	Акроним	Описание
0¹	PKIX-TA	Используемый сертификат — это общедоступный ЦС с привязкой доверия из цепочки доверия X.509.
1¹	PKIX-EE	Проверенный сертификат — это целевой сервер; Проверки DNSSEC должны проверять подлинность.
2	DANE-TA	Используйте закрытый ключ сервера из дерева X.509, который должен быть проверен привязкой доверия в цепочке доверия. Запись TLSA указывает привязку доверия, которая будет использоваться для проверки сертификатов TLS для домена.
3	DANE-EE	Соответствует только сертификату целевого сервера.

¹ Exchange Online следует руководству по реализации RFC, что значения поля использования сертификата 0 или 1 не должны использоваться при реализации DANE с помощью SMTP. Когда запись TLSA, которая имеет значение поля "Использование сертификата" 0 или 1, возвращается в Exchange Online, Exchange Online будет рассматривать ее как неприготовляемую. Если все записи TLSA признаны непригодными для использования, Exchange Online не будет выполнять действия по проверке DANE для 0 или 1 при отправке сообщения электронной почты. Вместо этого из-за наличия записи TLSA Exchange Online будет принудительно использовать TLS для отправки электронной почты, если конечный почтовый сервер поддерживает TLS, или удалить сообщение электронной почты и создать отчет о недоставке, если конечный почтовый сервер не поддерживает TLS.

В примере записи TLSA поле использования сертификата имеет значение "3", поэтому данные ассоциации сертификатов (abc123... xyz789') будет сопоставляться только с сертификатом целевого сервера.

Поле селектора: указывает, какие части сертификата целевого сервера следует проверить.

Значение	Акроним	Описание
0	Cert	Используйте полный сертификат.
1	SPKI (сведения об открытом ключе субъекта)	Используйте открытый ключ сертификата и алгоритм, с помощью которого идентифицируется открытый ключ.

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

Поле совпадающего типа: указывает формат, в котором сертификат будет представлен в записи TLSA.

Значение	Акроним	Описание
0	Full	Данные в записи TSLA — это полный сертификат или SPKI.
1	SHA-256	Данные в записи TSLA являются хэшом SHA-256 сертификата или SPKI.
2	SHA-512	Данные в записи TSLA являются хэшом SHA-512 сертификата или SPKI.

В примере записи TLSA поле совпадающего типа имеет значение "1", поэтому данные ассоциации сертификатов являются хэшом SHA-256 сведений открытого ключа субъекта из сертификата целевого сервера.

Данные ассоциации сертификатов. Указывает данные сертификата, которые используются для сопоставления с сертификатом целевого сервера. Эти данные зависят от значения поля селектора и значения соответствующего типа.

В примере записи TLSA для данных сопоставления сертификатов задано значение 'abc123.. xyz789'. Так как значение поля селектора в примере имеет значение "1", оно будет ссылаться на открытый ключ сертификата целевого сервера и алгоритм, который будет использоваться с ним. А так как значение поля "Тип соответствия" в примере имеет значение "1", оно будет ссылаться на хэш SHA-256 сведений открытого ключа субъекта из сертификата целевого сервера.

Как Exchange Online клиенты могут использовать исходящий трафик SMTP DANE?

Как клиенту Exchange Online, вам не нужно ничего делать, чтобы настроить эту расширенную защиту электронной почты для исходящей электронной почты. Эта улучшенная защита электронной почты создана для вас, и по умолчанию она включена для всех клиентов Exchange Online и используется, когда целевой домен объявляет о поддержке DANE. Чтобы воспользоваться преимуществами отправки электронной почты с помощью проверок DNSSEC и DANE, сообщите своим деловым партнерам, с которыми вы обмениваетсяе электронной почтой, что они должны реализовать DNSSEC и DANE, чтобы они могли получать электронную почту с помощью этих стандартов.

Как Exchange Online клиенты могут использовать входящий трафик SMTP DANE?

В настоящее время входящие SMTP DANE не поддерживаются для Exchange Online. Поддержка входящего SMTP DANE будет доступна в ближайшем будущем.

Какова рекомендуемая конфигурация записи TLSA?

В соответствии с рекомендациями по реализации RFC для SMTP DANE рекомендуется запись TLSA, состоящая из поля "Использование сертификата", для которого задано значение 3, для поля Selector — значение 1, а для поля "Тип соответствия" — значение 1.

Exchange Online потока обработки почты с помощью SMTP DANE

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

Существует только два сценария, в которых сбой SMTP DANE приведет к блокировке электронной почты:

Целевой домен сигнализирует о поддержке DNSSEC, но одна или несколько записей были возвращены как неавтогентные.
Все записи MX для целевого домена имеют записи TLSA, и ни один из сертификатов целевого сервера не соответствует ожидаемому значению данных записи TSLA, либо подключение TLS не поддерживается целевым сервером.

Технология	Дополнительные сведения
Агент передачи почты — строгая транспортная безопасность (MTA-STS) помогает предотвратить атаки на более раннюю версию и "человек в середине", предоставляя механизм настройки политик домена, которые указывают, поддерживает ли конечный почтовый сервер ПРОТОКОЛ TLS, и что делать, если протокол TLS не может быть согласован, например остановить передачу.	Дополнительные сведения о предстоящей поддержке Exchange Online входящих и исходящих MTA-STS будут опубликованы в конце этого года. Exchange Online новости транспорта от Microsoft Ignite 2020 — Microsoft Tech Community rfc8461 (ietf.org)
Платформа политики отправителей (SPF) использует сведения об IP-адресе, чтобы гарантировать, что целевые почтовые системы доверяют сообщениям, отправленным из личного домена.	Как платформа политики отправителей (SPF) предотвращает спуфинги
DomainKeys Identified Mail (DKIM) использует сведения о сертификате X.509, чтобы гарантировать, что целевые почтовые системы доверяют сообщениям, отправленным из личного домена.	Использование DKIM для работы с электронной почтой в личном домене
Проверка подлинности сообщений, создание отчетов и соответствие сообщений на основе домена (DMARC) работает с платформой политики отправителей и идентифицированной почтой DomainKeys для проверки подлинности отправителей почты и обеспечения доверия систем электронной почты, отправленных из вашего домена.	Использование протокола DMARC для проверки электронной почты и действий по настройке

Устранение неполадок при отправке сообщений электронной почты с помощью SMTP DANE

В настоящее время существует четыре кода ошибок для DANE при отправке сообщений электронной почты с Exchange Online. Корпорация Майкрософт активно обновляет этот список кодов ошибок. Ошибки будут видны в:

На портале Exchange Администратор Center в представлении Сведения о трассировки сообщений.
NDR, создаваемые, если сообщение не отправляется из-за сбоя DANE или DNSSEC.
Средство анализатора удаленного подключения Microsoft Remote Connectivity Analyzer.

Код недоставки	Описание
4/5.7.321	starttls-not-supported: почтовый сервер назначения должен поддерживать ПРОТОКОЛ TLS для получения почты.
4/5.7.322	Срок действия сертификата истек: срок действия сертификата почтового сервера назначения истек.
4/5.7.323	tlsa-invalid: домен не выполнил проверку DANE.
4/5.7.324	dnssec-invalid: целевой домен вернул недопустимые записи DNSSEC.

Примечание.

В настоящее время, когда домен сигнализирует о том, что он поддерживает DNSSEC, но не выполняет проверки DNSSEC, Exchange Online не создает ошибку 4/5.7.324 dnssec-invalid. Он создает общую ошибку DNS:

4/5.4.312 DNS query failed

Мы активно работаем над устранением этого известного ограничения. Если вы получаете эту инструкцию об ошибке, перейдите к анализатору удаленного подключения (Майкрософт) и выполните проверку DANE для домена, в котором возникла ошибка 4/5.4.312. Результаты покажут, является ли это проблемой DNSSEC или другой проблемой DNS.

Устранение неполадок 4/5.7.321 starttls-not-supported

Эта ошибка обычно указывает на проблему с почтовым сервером назначения. После получения сообщения:

Убедитесь, что адрес электронной почты назначения указан правильно.
Оповещение администратора электронной почты назначения о том, что вы получили этот код ошибки, чтобы он смог определить, правильно ли настроен конечный сервер для получения сообщений с помощью TLS.
Повторите попытку отправки сообщения и просмотрите сведения о трассировке сообщения на портале Exchange Администратор Center.

Устранение неполадок с истекшим сроком действия сертификата 4/5.7.322

На отправляющий сервер электронной почты должен быть представлен действительный сертификат X.509, срок действия которого не истек. Сертификаты X.509 должны обновляться по истечении срока действия, как правило, ежегодно. После получения сообщения:

Сообщите администратору электронной почты назначения о том, что вы получили этот код ошибки, и укажите строку кода ошибки.
Укажите время для обновления сертификата целевого сервера и обновления записи TLSA для ссылки на новый сертификат. Затем повторите попытку отправки сообщения и просмотрите сведения о трассировке сообщения на портале Exchange Администратор Center.

Устранение неполадок 4/5.7.323 tlsa-invalid

Этот код ошибки связан с неправильной настройкой записи TLSA и может быть создан только после возврата записи TLSA, аутентичной DNSSEC. Существует множество сценариев проверки DANE, которые происходят после возврата записи, что может привести к созданию кода. Корпорация Майкрософт активно работает над сценариями, на которые распространяется этот код ошибки, так что каждый сценарий имеет определенный код. В настоящее время один или несколько из этих сценариев могут привести к созданию кода ошибки:

Сертификат целевого почтового сервера не соответствует ожидаемой подлинной записи TLSA.
Подлинная запись TLSA настроена неправильно.
Целевой домен подвергается атаке.
Любой другой сбой DANE.

После получения сообщения:

Оповестите администратора электронной почты назначения о том, что вы получили этот код ошибки, и предоставьте ему строку кода ошибки.
Дайте администратору назначения время на проверку конфигурации DANE и срока действия сертификата сервера электронной почты. Затем повторите попытку отправки сообщения и просмотрите сведения о трассировке сообщения на портале Exchange Администратор Center.

Устранение неполадок 4/5.7.324 dnssec-invalid

Этот код ошибки создается, когда целевой домен указал, что он является DNSSEC-authentic, но Exchange Online не удалось проверить его как DNSSEC-authentic.

После получения сообщения:

Оповестите администратора электронной почты назначения о том, что вы получили этот код ошибки, и предоставьте ему строку кода ошибки.
Указать администратору целевой электронной почты время на проверку конфигурации DNSSEC своего домена. Затем повторите попытку отправки сообщения и просмотрите сведения о трассировке сообщения на портале Exchange Администратор Center.

Устранение неполадок с получением сообщений электронной почты с помощью SMTP DANE

В настоящее время администратор получающего домена может использовать два метода для проверки и устранения неполадок в конфигурации DNSSEC и DANE для получения электронной почты от Exchange Online, используя эти стандарты.

Внедрение ПРОТОКОЛА SMTP TLS-RPT (отчеты о безопасности транспортного уровня), появилось в RFC8460
Использование средства анализатора удаленного подключения Microsoft Remote Connectivity Analyzer

TLS-RPT https://datatracker.ietf.org/doc/html/rfc8460 — это механизм отчетности для отправителей, предоставляющий администраторам целевого домена сведения об успехах и сбоях DANE и MTA-STS с соответствующими целевыми доменами. Чтобы получать отчеты TLS-RPT, необходимо только добавить запись TXT в записи DNS домена, которая включает адрес электронной почты или универсальный код ресурса (URI) для отправки отчетов. Exchange Online будут отправлять отчеты TLS-RPT в формате JSON.

Пример записи:

Второй способ — использовать анализатор удаленного подключения Microsoft Remote Connectivity Analyzer, который может выполнять те же проверки DNSSEC и DANE для конфигурации DNS, которые Exchange Online будет выполнять при отправке электронной почты за пределы службы. Этот метод является наиболее прямым способом устранения ошибок в конфигурации для получения электронной почты от Exchange Online, используя эти стандарты.

При устранении ошибок могут создаваться следующие коды ошибок:

Код недоставки	Описание
4/5.7.321	starttls-not-supported: почтовый сервер назначения должен поддерживать ПРОТОКОЛ TLS для получения почты.
4/5.7.322	Срок действия сертификата истек: срок действия сертификата почтового сервера назначения истек.
4/5.7.323	tlsa-invalid: домен не выполнил проверку DANE.
4/5.7.324	dnssec-invalid: целевой домен вернул недопустимые записи DNSSEC.

Примечание.

4/5.4.312 DNS query failed

Устранение неполадок 4/5.7.321 starttls-not-supported

Примечание.

Эти действия предназначены для администраторов электронной почты, которые устраняют неполадки с получением электронной почты от Exchange Online с помощью SMTP DANE.

Эта ошибка обычно указывает на проблему с почтовым сервером назначения. Почтовый сервер, с которым проверяется подключение анализатора удаленного подключения. Как правило, этот код создается в двух сценариях:

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

После получения сообщения:

Проверьте адрес электронной почты.
Найдите IP-адрес, связанный с инструкцией error, чтобы можно было определить почтовый сервер, с которым связана инструкция.
Проверьте параметр почтового сервера, чтобы убедиться, что он настроен для прослушивания SMTP-трафика (обычно порты 25 и 587).
Подождите несколько минут, а затем повторите тест с помощью средства анализатора удаленного подключения.
Если он по-прежнему завершается ошибкой, попробуйте удалить запись TLSA и снова запустите тест с помощью средства анализатора удаленного подключения.
Если ошибок нет, это сообщение может указывать на то, что почтовый сервер, используемый для получения почты, не поддерживает STARTTLS, и вам может потребоваться выполнить обновление до сервера, который использует DANE.

Устранение неполадок с истекшим сроком действия сертификата 4/5.7.322

Примечание.

Проверьте IP-адрес, связанный с инструкцией об ошибке, чтобы определить почтовый сервер, с которым он связан. Найдите сертификат с истекшим сроком действия на сервере электронной почты, который вы определили.
Войдите на веб-сайт поставщика сертификатов.
Выберите сертификат с истекшим сроком действия и следуйте инструкциям по продлению и оплате продления.
После того как поставщик проверит покупку, вы можете скачать новый сертификат.
Установите обновленный сертификат на связанный почтовый сервер.
Обновите связанную с почтовым сервером запись TLSA данными нового сертификата.
Подождав соответствующее время, повторите тест с помощью средства анализатора удаленного подключения.

Устранение неполадок 4/5.7.323 tlsa-invalid

Примечание.

Этот код ошибки связан с неправильной настройкой записи TLSA и может быть создан только после возврата записи TSLA с проверкой подлинности DNSSEC. Но во время проверки DANE существует множество сценариев, которые происходят после возврата записи, что может привести к созданию кода. Корпорация Майкрософт активно работает над сценариями, на которые распространяется этот код ошибки, так что каждый сценарий имеет определенный код. В настоящее время один или несколько из этих сценариев могут привести к созданию кода ошибки:

Подлинная запись TLSA настроена неправильно.
Сертификат еще не действителен или настроен для будущего периода времени.
Целевой домен подвергается атаке.
Любой другой сбой DANE.

После получения сообщения:

Проверьте IP-адрес, связанный с инструкцией error, чтобы определить почтовый сервер, с которым он связан.
Определите запись TLSA, связанную с указанным почтовым сервером.
Проверьте конфигурацию записи TLSA, чтобы убедиться, что она сигнализирует отправителю о выполнении предпочтительных проверок DANE и что в запись TLSA включены правильные данные сертификата.
1. Если необходимо внести какие-либо изменения в запись на наличие несоответствий, подождите несколько минут, а затем повторно запустите тест с помощью средства анализатора удаленного подключения.
Найдите сертификат на идентифицированном почтовом сервере.
Проверьте период времени, в течение которого сертификат действителен. Если задано значение для начала срока действия в будущем, его необходимо продлить на текущую дату.
1. Войдите на веб-сайт поставщика сертификатов.
2. Выберите сертификат с истекшим сроком действия и следуйте инструкциям по продлению и оплате продления.
3. После того как поставщик проверит покупку, вы можете скачать новый сертификат.
4. Установите обновленный сертификат на связанный почтовый сервер.

Устранение неполадок 4/5.7.324 dnssec-invalid

Примечание.

Этот код ошибки создается, если целевой домен указывает, что он является DNSSEC-authentic, но Exchange Online не может проверить его как DNSSEC-authentic. Этот раздел не будет исчерпывающим для устранения неполадок DNSSEC и посвящен сценариям, когда домены ранее проходили проверку подлинности DNSSEC, но не сейчас.

После получения сообщения:

Если вы используете поставщик DNS, например GoDaddy, оповестите поставщика DNS об ошибке, чтобы он смог работать над устранением неполадок и изменением конфигурации.
Если вы управляете собственной инфраструктурой DNSSEC, существует много неправильных настроек DNSSEC, которые могут привести к возникновению этого сообщения об ошибке. Некоторые распространенные проблемы, которые проверка, если ваша зона ранее проходила проверку подлинности DNSSEC:
1. Сломанная цепочка доверия, когда родительская зона содержит набор записей DS, указывающих на то, что не существует в дочерней зоне. Такие указатели записей DS могут привести к тому, что дочерняя зона будет помечена как фиктивная путем проверки сопоставителей.
  - Чтобы устранить эту проблему, проверьте идентификаторы ключей RRSIG дочерних доменов и убедитесь, что они совпадают с идентификаторами ключей в записях DS, опубликованных в родительской зоне.
2. Запись ресурса RRSIG для домена не является допустимой по времени, она либо истекла, либо срок действия не начался.
  - Чтобы устранить эту проблему, создав новые подписи для домена с использованием допустимых интервалов времени.

Примечание.

Этот код ошибки также создается, если Exchange Online получает ответ SERVFAIL от DNS-сервера на запрос TLSA для целевого домена.

При отправке исходящего сообщения электронной почты, если в принимающем домене включен DNSSEC, мы запрашиваем записи TLSA, связанные с записями MX в домене. Если запись TLSA не опубликована, ответом на запрос TLSA должен быть NOERROR (нет записей запрошенного типа для этого домена) или NXDOMAIN (такого домена нет). DNSSEC требует этот ответ, если запись TLSA не опубликована; В противном случае Exchange Online интерпретирует отсутствие ответа как ошибку SERVFAIL. Согласно RFC 7672, ответ SERVFAIL не заслуживает доверия; Таким образом, целевой домен не проходит проверку DNSSEC. Затем это сообщение электронной почты откладывается со следующей ошибкой:

450 4.7.324 dnssec-invalid: Destination domain returned invalid DNSSEC records

Если отправитель сообщения сообщает о получении сообщения

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

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

Как клиент Exchange Online, могу ли я отказаться от использования DNSSEC и (или) DANE?

Мы твердо верим, что DNSSEC и DANE значительно повысят положение в области безопасности нашей службы и принесут пользу всем нашим клиентам. В течение последнего года мы усердно работали над снижением риска и серьезности потенциального воздействия, которое это развертывание может оказать на клиентов Microsoft 365. Мы будем активно отслеживать и отслеживать развертывание, чтобы свести к минимуму негативное воздействие по мере его развертывания. Из-за этого исключения на уровне клиента или отказ не будут доступны. Если у вас возникли проблемы, связанные с включением DNSSEC и (или) DANE, различные методы исследования сбоев, описанные в этом документе, помогут вам определить источник ошибки. В большинстве случаев проблема будет связана с внешней целевой стороной, и вам потребуется сообщить этим бизнес-партнерам, что они должны правильно настроить DNSSEC и DANE для получения электронной почты от Exchange Online, используя эти стандарты.

Как DNSSEC связан с DANE?

DNSSEC добавляет уровень доверия в разрешение DNS, применяя инфраструктуру открытых ключей, чтобы гарантировать подлинность записей, возвращаемых в ответ на запрос DNS. DANE гарантирует, что принимающий почтовый сервер является допустимым и ожидаемым почтовым сервером для подлинной записи MX.

В чем разница между MTA-STS и DANE для SMTP?

DANE и MTA-STS служат одной и той же цели, но для проверки подлинности DNS требуется DNSSEC, в то время как MTA-STS использует центры сертификации.

Почему не хватает opportunistic TLS?

Оппортунистический ПРОТОКОЛ TLS будет шифровать обмен данными между двумя конечными точками, если обе согласны поддерживать его. Однако даже если TLS шифрует передачу, домен может быть спуфинирован во время разрешения DNS таким образом, что он указывает на конечную точку вредоносного субъекта, а не на реальную конечную точку домена. Эта подделка является пробелом в безопасности электронной почты, который решается путем реализации MTA-STS и (или) SMTP DANE с DNSSEC.

Почему dnssec недостаточно?

DNSSEC не полностью устойчив к атакам "человек в середине" и понижает версию (с TLS до чистого текста) для сценариев потока обработки почты. Добавление MTA-STS и DANE вместе с DNSSEC предоставляет комплексный метод безопасности, чтобы сорвать атаки MITM и более ранней версии.

Дополнительные ссылки

Поиск и устранение неполадок после добавления домена и записей DNS

Общие сведения о DNSSEC | Документация Майкрософт

Использование DMARC для проверки электронной почты и действий по настройке — Office 365 | Документация Майкрософт

Использование DKIM для электронной почты в вашем пользовательском домене — Office 365 | Документация Майкрософт

Как платформа политики отправителей (SPF) предотвращает подделывание — Office 365 | Документация Майкрософт

Exchange Online новости транспорта от Microsoft Ignite 2020 — Microsoft Tech Community

rfc8461 (ietf.org)

Как работает проверка подлинности именованных сущностей (DANE) на основе SMTP dns