Как работает аутентификация именованных сущностей (DANE) на основе DNS SMTP

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

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 как authentic DNSSEC, сервер отправляющей почты запрашивает запись TLSA, соответствующую записям хоста MX. Если запись TLSA присутствует и ее подлинность подтверждена с помощью другой проверки DNSSEC, рекурсивный преобразователь DNS возвращает запись TLSA на отправляющий почтовый сервер.

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

Каковы компоненты DANE?

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

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

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

Тип записи TLSA содержит четыре настраиваемых поля:

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

¹ 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') соответствует только сертификату сервера назначения.

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

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

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

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

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

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

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

Согласно руководству по внедрению RFC для SMTP DANE, используйте запись TLSA с полем "Использование сертификатов" со значением 3, полем "Выбор" значением 1 и полем "Тип соответствия" значением 1.

Поток обработки почты Exchange Online с DANE SMTP

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

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

• Домен назначения сигнализирует о поддержке DNSSEC, но одна или несколько записей возвращаются как неподлинные.

• Все записи MX для домена назначения содержат записи TLSA, и ни один из сертификатов сервера назначения не соответствует ожидаемым данным записи TLSA, или подключение TLS не поддерживается сервером назначения.

  

Связанные технологии

Входящий трафик SMTP DANE с DNSSEC

Предварительные условия

Перед началом работы убедитесь, что выполнены следующие предварительные требования.

1. Добавьте домен в качестве допустимого и убедитесь, что он имеет состояние "Работоспособно" в Центре администрирования Microsoft 365. В этой документации предполагается, что для записи MX домена установлен приоритет 0 или 10 и что "резервная" или вспомогательная запись MX отсутствует. Если у вас есть резервная запись MX, обратитесь к администратору Exchange Online, чтобы убедиться в правильности внесения изменений.
2. Чтобы получить все преимущества безопасности этой функции, включите DNSSEC для своего домена.
3. Доступ к Exchange Online PowerShell и разрешения на запуск командлетов, описанных в статье Exchange Online PowerShell.

Настройка входящего трафика SMTP DANE с помощью DNSSEC

Чтобы настроить входящий трафик SMTP DANE с DNSSEC, заполните следующие разделы:

• Включение DNSSEC
• Включить SMTP DANE

Включение DNSSEC

1. Обновите TTL существующей записи MX до минимально возможного TTL (но не менее 30 секунд). Затем дождитесь истечения предыдущего срока жизни, прежде чем продолжить. Например, если до изменения значения TTL существующей записи MX прошло 3600 секунд (1 час), необходимо подождать 1 час, прежде чем переходить к шагу 2.

2. Подключитесь к Exchange Online PowerShell.

   Предупреждение

   Если вы используете MTA-STS, необходимо установить режим политики в "testing" и обновить идентификатор в записи TXT MTA-STS. (В качестве идентификатора новой политики можно использовать текущее время в формате UTC.) Дождитесь окончания срока действия "max_age" политики, прежде чем продолжить. Например, если "max_age" существующей политики STS прошло 3600 секунд (1 час) до ее изменения, необходимо подождать 1 час, прежде чем продолжить.

3. Для домена, в котором требуется включить SMTP DANE с DNSSEC, включите DNSSEC в этом домене, выполнив следующую команду (замените "домен" на имя выбранного домена, например, contosotest.com):

   Enable-DnssecForVerifiedDomain -DomainName <DomainName>
   

   Примечание.

   Выполнение этой команды может занять несколько минут.

   Пример выходных данных успешного выполнения

   Результат	DnssecMxValue	ErrorData
   Успешно	contosotest-com.o-v1.mx.microsoft

   Ответ об успешном выполнении предоставляет значение MX для домена. Это значение является именем, на которое указывает новая запись MX для домена, который вы включаете с помощью DNSSEC. Например, contosotest-com.o-v1.mx.microsoft.

4. Возьмите значение "DnssecMxValue", перейдите к регистратору DNS, на котором размещен домен, добавьте новую запись MX, используя значение, возвращенное на шаге 3, установите минимально возможное значение TTL (но не ниже 30 секунд) и установите приоритет новой записи MX равным 20.

   Если вы используете сторонний почтовый шлюз и хотите использовать это значение в качестве нового целевого узла Exchange Online, на который сторонний почтовый шлюз отправляет входящую почту, перейдите на портал администрирования сторонней службы, обновите целевой смарт-узел, а затем проверьте поток почты с помощью теста DNSSEC (выберите "Проверка DNSSEC", а не "Проверка DANE [включая DNSSEC]") в анализаторе удаленного подключения. Если почта идет должным образом, нет необходимости продолжать остальные шаги DNSSEC. Если вы по-прежнему хотите включить SMTP DANE для этого домена, продолжайте включать SMTP DANE и начните с шага, на котором вы запускаете Enable-SmtpDaneInbound.

   Предупреждение

   Если вы используете MTA-STS, убедитесь, что для политики установлен режим "Тестирование". Затем удалите текущую строку mx, содержащую сведения о прежней записи MX, и добавьте новое полное доменное имя в файл политики MTA-STS в качестве новой строки mx. Затем обновите идентификатор политики в политике и запись TXT MTA-STS (в качестве нового идентификатора политики можно использовать текущее время в формате UTC).

5. Убедитесь, что новый MX работает, с помощью теста входящего SMTP Email, развернув шаги тестирования и убедившись, что обменник почты, заканчивающийся на mx.microsoft, был успешно протестирован. В зависимости от кэширования DNS может потребоваться повторить этот тест.

   Пример выходных данных об успешном выполнении

   

6. Изменение приоритета устаревшего MX, указывающего на mail.protection.outlook.com, с текущего приоритета на 30; измените приоритет записи MX, созданной на шаге 3, чтобы назначить ей приоритет 0 (наивысший приоритет).

7. Удалите устаревшую запись MX, заканчивающуюся на "mail.protection.outlook.com", "mail.eo.outlook.com" или "mail.protection.outlook.de". Затем обновите TTL для записи MX, оканчивающейся на mx.microsoft, до 3600 секунд. При необходимости вы можете проверить, все ли работает должным образом, с помощью теста DNSSEC (убедитесь, что во время ввода тестового кода выбрана "Проверка DNSSEC", а не "Проверка DANE [включая DNSSEC]") в анализаторе удаленного подключения. Возможно, вам придется повторить этот тест в зависимости от кэширования DNS и TTL.

Включить SMTP DANE

1. Обновите TTL существующей записи MX до минимально возможного TTL (но не менее 30 секунд). Затем дождитесь истечения предыдущего срока жизни, прежде чем продолжить. Например, если до изменения значения TTL существующей записи MX прошло 3600 секунд (1 час), необходимо подождать 1 час, прежде чем переходить к шагу 2.

2. Подключитесь к Exchange Online PowerShell.

   Предупреждение

   Если вы используете MTA-STS, необходимо установить режим политики в "testing" и обновить идентификатор в записи TXT MTA-STS. (В качестве идентификатора новой политики можно использовать текущее время в формате UTC.) Дождитесь окончания срока действия "max_age" политики, прежде чем продолжить. Например, если "max_age" существующей политики STS прошло 3600 секунд (1 час) до ее изменения, необходимо подождать 1 час, прежде чем продолжить.

3. Для домена, в котором требуется включить SMTP DANE с DNSSEC, включите DNSSEC в этом домене, выполнив следующую команду (замените "домен" на имя выбранного домена, например, contosotest.com):

   Enable-DnssecForVerifiedDomain -DomainName <DomainName>
   

   Примечание.

   Выполнение этой команды может занять несколько минут.

   Пример выходных данных успешного выполнения

   Результат	DnssecMxValue	ErrorData
   Успешно	contosotest-com.o-v1.mx.microsoft

   Ответ об успешном выполнении предоставляет значение MX для домена. Это значение является именем, на которое указывает новая запись MX для домена, который вы включаете с помощью DNSSEC. Например, contosotest-com.o-v1.mx.microsoft.

4. Возьмите значение "DnssecMxValue", перейдите к регистратору DNS, на котором размещен домен, добавьте новую запись MX, используя значение, возвращенное на шаге 3, установите минимально возможное значение TTL (но не ниже 30 секунд) и установите приоритет новой записи MX равным 20.

   Примечание.

   Если вы используете сторонний почтовый шлюз и хотите использовать это значение в качестве нового целевого узла Exchange Online, на который сторонний почтовый шлюз отправляет входящую почту, перейдите на портал администрирования сторонней компании, обновите целевой смарт-хост, который сторонняя компания использует для отправки в Exchange Online, а затем проверьте, что "поток почты работает, с помощью проверки DNSSEC (Убедитесь, что во время тестового ввода выбрана "Проверка DNSSEC", а не "Проверка DANE [включая DNSSEC])" в анализаторе Microsoft Remote Connectivity Analyzer: тестовый ввод". Если почта идет нормальным образом, не нужно продолжать выполнять указанные ниже действия. Если вы хотите включить SMTP DANE для этого домена, перейдите к шагу 7.

   Предупреждение

   Если вы используете MTA-STS, убедитесь, что для политики установлен режим "Тестирование". Затем удалите текущую строку mx, содержащую сведения о прежней записи MX, и добавьте новое полное доменное имя в файл политики MTA-STS в качестве новой строки mx. Затем обновите идентификатор политики в политике и запись TXT MTA-STS (в качестве нового идентификатора политики можно использовать текущее время в формате UTC).

5. Убедитесь, что новый MX работает, с помощью входящего SMTP Email test (https://testconnectivity.microsoft.com/tests/O365InboundSmtp/input), развернув шаги тестирования и убедившись, что почтовый обменник, заканчивающийся на mx.microsoft, был успешно протестирован. В зависимости от кэширования DNS может потребоваться повторить этот тест.

   Пример выходных данных об успешном выполнении

   

6. Изменение приоритета устаревшего MX, указывающего на mail.protection.outlook.com, с текущего приоритета на 30; измените приоритет записи MX, созданной на шаге 3, чтобы назначить ей приоритет 0 (наивысший приоритет).

7. Удалите устаревшую запись MX, заканчивающуюся на "mail.protection.outlook.com", "mail.eo.outlook.com" или "mail.protection.outlook.de". Затем обновите TTL для записи MX, оканчивающейся на mx.microsoft, до 3600 секунд. При необходимости вы можете убедиться, что все работает должным образом, с помощью теста DNSSEC (убедитесь, что во время ввода тестового кода выбрана «Проверка DNSSEC», а не «Проверка DANE [включая DNSSEC])» в анализаторе удаленного подключения. Возможно, вам придется повторить этот тест в зависимости от кэширования DNS и TTL.

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

   

8. Выполните следующую команду [замените (DomainName) на имя выбранного домена, например, contosotest.com], если вы хотите включить SMTP DANE для этого же домена после завершения включения DNSSEC:

   Enable-SmtpDaneInbound -DomainName <DomainName>
   

   Результат	ErrorData
   Успешно

9. Убедитесь, что запись TLSA была распространена (это может занять 15–30 минут) с помощью выбранного вами веб-средства и средства Microsoft Remote Connectivity Analyzer: тестовый ввод.

   После включения DNSSEC и подготовки записи SMTP DANE (TLSA) приложением Exchange Online отобразятся выходные данные, как показано на следующем снимке экрана:

   

   В Exchange Online размещается несколько записей TLSA, что повышает надежность успешной проверки DANE SMTP. Ожидается, что некоторые записи TLSA не пройдут проверку. Если одна запись TLSA проходит проверку, SMTP DANE настроен правильно, а электронная почта защищена с помощью SMTP DANE.

   Предупреждение

   Если вы используете MTA-STS, убедившись, что политика работает и что почта передается должным образом, снова установите режим политики "принудительно" и обновите идентификатор в записи TXT MTA-STS. (В качестве идентификатора новой политики можно использовать текущее время в формате UTC.)

Ограничения

1. Вирусные домены или домены самостоятельной регистрации: домены, которые вы настроили как "самообслуживание", в настоящее время не поддерживаются входящим трафиком SMTP DANE с DNSSEC.

2. Домены onmicrosoft.com: домен "onmicrosoft.com" для клиента в настоящее время не поддерживается входящим трафиком SMTP DANE с DNSSEC. Мы изучаем поддержку входящего трафика SMTP DANE с DNSSEC для доменов onmicrosoft.com. однако ETA неизвестен.

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

4. Другая сторонняя интеграция с потоком обработки почты: Некоторые клиенты используют сторонние шлюзы для исходящего трафика, когда электронная почта отправляется сторонней компании через соединитель, третья сторона выполняет некоторую обработку, а затем повторно отправляет ее в Exchange Online, после чего Exchange Online отправляет сообщение электронной почты. Таким клиентам может потребоваться обратиться к стороннему поставщику при включении функции, чтобы избежать сбоев. Сторонний ретранслятор должен использовать поиск DNS при отправке электронной почты обратно в Exchange Online и использовать новое имя узла записи MX -> contoso-com.( subdomain).mx.microsoft, созданный во время включения функции.

5. Полностью делегированные домены: домены, которые Microsoft размещает и использует делегирование NS, чтобы серверы доменных имен Microsoft были полномочными для домена, поддерживаются с помощью входящего трафика SMTP DANE с DNSSEC. Мы планируем поддерживать входящий трафик SMTP DANE с помощью DNSSEC для этих доменов; однако ETA неизвестен.

Устранение проблем, возникающих при включении входящего трафика SMTP DANE с помощью DNSSEC

Проблемы с входящими данными Enable/Disable-DnssecForVerifiedDomain и Enable/Disable-SMTPDane

1. DomainNotFound

   Сообщение (DNSSEC): 'Не удалось включить или отключить DNSSEC, из-за отсутствия contoso.com домена в AAD".
   Сообщения (SMTP DANE):
   

   • "Сбой включения или отключения SMTP DANE из-за отсутствия contoso.com домена в AAD".
     
   • "Сбой включения или отключения SMTP DANE из-за отсутствия contoso.com домена в списке допустимых доменов".
     Причина: предоставленный домен не найден в списке допустимых доменов.
     Необходимые действия: Перейдите в Центр администрирования Microsoft 365 Admin и убедитесь, что домен проверен в клиенте. Если домен работоспособен в Центре администрирования Microsoft 365, перейдите в Центр администраторов Exchange и убедитесь, что домен добавлен в качестве "Допустимого домена".

   DNSSEC

   Результат	DnssecMxValue	ErrorData
   Error		ErrorCode: 'DomainNotFound' ErrorDetails 'Сбой включения DNSSEC...

   SMTP DANE

   Результат	ErrorData
   Error	ErrorCode: 'DomainNotFound' ErrorDetails 'SMTP DANE enableing...

2. DnsSecOperationFailed

   Сообщение (DNSSEC): 'Не удалось включить или отключить DNSSEC из-за AdditionalErrorDetails. Повторите операцию позже".
   Сообщения (SMTP DANE): сбой включения или отключения SMTP DANE из-за AdditionalErrorDetails. Повторите операцию позже.
   Причина: ошибка создания соответствующей зоны DNS и/или записей.
   Необходимые действия: попробуйте повторно запустить командлет.

   DNSSEC

   Результат	DnssecMxValue	ErrorData
   Error		ErrorCode: 'DnssecOperationFailed' ErrorDetails 'Сбой включения DNSSEC...

   SMTP DANE

   Результат	ErrorData
   Error	ErrorCode: 'DnssecOperationFailed' ErrorDetails 'SMTP DANE enabling ...

3. PartitionNotFound

   Сообщения (SMTP DANE): "Не удалось включить или отключить SMTP DANE из-за отсутствия раздела в домене contoso.com ".
   Причина: DNSSEC не включен для домена.
   Необходимые действия: убедитесь, что вы используете домен с поддержкой DNSSEC.

   Результат	ErrorData
   Error	ErrorCode: 'PartitionNotFound' ErrorDetails 'Включение SMTP DANE

4. DomainNotSupported

   Сообщение (DNSSEC): 'Указанный домен является доменом Майкрософт: contoso-com.onmicrosoft.com.''
   Сообщения (SMTP DANE): 'Указанный домен является доменом onmicrosoft: contoso-com.onmicrosoft.com.''
   Причина: домен является начальным или доменом MOERA. В настоящее время эти домены не поддерживаются.
   Необходимые действия: убедитесь, что вы используете домен, имя которого не заканчивается на "onmicrosoft.com".

   DNSSEC

   Результат	DnssecMxValue	ErrorData
   Error		ErrorCode: 'DomainNotSupported' ErrorDetails 'Указанный домен ...

   SMTP DANE

   Результат	ErrorData
   Error	ErrorCode: 'DomainNotSupported' ErrorDetails 'Указанный домен ...

Проблемы с Get-DnssecStatusForVerifiedDomain

1. Сообщение: 'EG001: невозможно получить состояние функции DNSSEC для домена [{домен}].'
   Причина. При проверке конфигурации домена в Exchange Online домен не был добавлен в Exchange Online. Если вы считаете, что уже добавили этот домен в Exchange Online, повторите попытку запуска командлета, так как эта проблема может быть временной.
   Необходимые действия: Повторите работу командлета. Если по-прежнему возникает сбой, перейдите в Центр администрирования Microsoft 365 и завершите настройку для этого домена.

2. Сообщение: 'EG002: домен [{домен}] не является проверенным доменом организации.'
   Причина. Во время проверки конфигурации домена в Exchange Online домен был добавлен в Exchange Online, но не был проверен.
   Необходимые действия: перейдите в Центр администрирования Microsoft 365 Admin и завершите процесс настройки и проверки для этого домена.

3. Сообщение: "При получении записей MX для домена [{domain}] возникает ошибка запроса DNS".
   Причина. Во время проверки DNS при запросе домена произошел общий сбой DNS.
   Необходимые действия: повторите попытку запуска командлета. Возможно, потребуется проверить конфигурацию домена, который вы пытаетесь включить с помощью SMTP DANE с DNSSEC.

4. Сообщение: 'Домен [{домен}] не найден''
   Причина: во время проверки DNS произошел сбой NXDOMAIN при запросе домена.
   Необходимые действия: повторите попытку запуска командлета после проверки конфигурации записей MX для домена. Распространение DNS может занимать до 48 часов для некоторых поставщиков DNS.

5. Сообщение: 'ED003: Домен [{домен}] найден. Подлинные записи MX не найдены».
   Причина. Во время проверки DNSSEC не была найдена запись MX, которая разрешалась в запись A с защитой DNSSEC (запись A для значения "hostname" записи MX).
   Необходимые действия: повторите попытку запуска командлета после проверки конфигурации записей MX для домена. Распространение DNS может занимать до 48 часов для некоторых поставщиков DNS.

6. Сообщение: "EX002: значение записи MX не соответствует ожидаемому."
   Причина. Во время проверки MX не была найдена запись MX, соответствующая ожидаемой.
   Необходимые действия: проверьте записи MX в вашем домене. Убедитесь, что одна запись MX совпадает с ожидаемой записью, выводимой после выполнения Enable-DnssecForVerifiedDomain или Get-DnssecStatusForVerifiedDomain.

7. Сообщение: 'EX003: приоритет записи MX не соответствует ожидаемому.'
   Причина. Во время проверки MX ожидаемая запись MX была найдена, но ее приоритет не был установлен равным 0.
   Необходимые действия: Установите для записи MX (содержащей значение, возвращаемое при запуске Enable-DnssecForVerifiedDomainили Get-DnssecStatusForVerifiedDomain) приоритет 0.

8. Сообщение: 'EX004: Существует другая запись MX с теми же предпочтениями, что и ожидаемая.'
   Причина: во время проверки MX запись MX с наивысшим приоритетом не была ожидаемой записью MX.
   Необходимые действия: Если вы выполнили шаги с 1 по 4 раздела "Настройка входящего сигнала SMTP DANE с помощью DNSSEC", выполните шаги 5 и 6, изменив приоритеты записей MX так, чтобы ожидаемый MX был равен 0 (наивысший приоритет), проверив конфигурацию, а затем удалив устаревшую запись MX.

9. Сообщение: 'EX005: Существует другая запись MX с меньшим приоритетом, чем ожидаемая.'
   Причина: во время проверки MX запись MX для домена не совпадала с ожидаемой записью MX.
   Необходимые действия: Если вы выполнили шаги с 1 по 5 статьи "Настройка входящего трафика SMTP DANE с помощью DNSSEC", то выполните шаг 6, удалив устаревшую запись MX.

10. Сообщение: «EX006: Существует другая запись MX с более высоким приоритетом, чем ожидаемая».
    Причина: во время проверки MX другая запись MX имела более высокий приоритет, чем ожидаемая.
    Необходимые действия: установите для устаревшей записи MX (заканчивающейся на mail.protection.outlook.com, mail.eo.outlook.com или mail.protection.outlook.de) приоритет 20.

11. Сообщение: "EX007: запись MX не найдена".
    Причина. Во время проверки MX не была найдена запись MX, соответствующая ожидаемой.
    Необходимые действия: проверьте записи MX в вашем домене. Убедитесь, что одна запись MX совпадает с ожидаемой записью, которая выводится после выполнения Enable-DnssecForVerifiedDomain или Get-DnssecStatusForVerifiedDomain.

12. Сообщение: 'EX008: найдена правильная запись MX, но с меньшими предпочтениями, чем ожидалось.'
    Причина: во время проверки MX ожидаемая запись MX имела неверный приоритет.
    Необходимые действия: Установите запись MX (содержащую значение, возвращаемое при запуске Enable-DnssecForVerifiedDomain или Get-DnssecStatusForVerifiedDomain) с приоритетом 0.

13. Сообщение: "EX009: найдена правильная запись MX, но с более высоким приоритетом, чем ожидалось".
    Причина: во время проверки MX ожидаемая запись MX имела неверный приоритет.
    Необходимые действия: Установите запись MX (содержащую значение, возвращаемое при запуске Enable-DnssecForVerifiedDomain или Get-DnssecStatusForVerifiedDomain) с приоритетом 0.

14. Сообщение: "EX010: неизвестная ошибка при поиске записей MX для домена [{domain}]".
    Причина: во время проверки MX произошла общая ошибка DNS.
    Необходимые действия: повторите попытку запуска командлета после проверки конфигурации записей MX для домена. Распространение DNS может занимать до 48 часов для некоторых поставщиков DNS.

15. Сообщение: "EX012: записи MX не найдены для домена [{domain}]".
    Причина. Во время проверки MX не была найдена запись MX, соответствующая ожидаемой.
    Необходимые действия: проверьте записи MX в вашем домене. Убедитесь, что одна запись MX совпадает с ожидаемой записью, которая выводится после выполнения Enable-DnssecForVerifiedDomain или Get-DnssecStatusForVerifiedDomain.

16. Сообщение: 'EX013: неизвестная ожидаемая запись MX для домена [{domain}].'
    Причина. Во время проверки MX не была найдена запись MX, соответствующая ожидаемой.
    Необходимые действия: проверьте записи MX в вашем домене. Убедитесь, что одна запись MX совпадает с ожидаемой записью, которая выводится после выполнения Enable-DnssecForVerifiedDomain или Get-DnssecStatusForVerifiedDomain.

17. Сообщение: 'ES001: в политике отсутствует ожидаемая запись MX в режиме ''enforced'''.
    Причина. Во время проверки MTA-STS не найдено значение mx, соответствующее ожидаемой записи.
    Действие, которое необходимо предпринять: Установите режим вашей политики MTA-STS для тестирования; затем добавьте значение mxhostname (возвращается при запуске Enable-DnssecForVerifiedDomain или Get-DnssecStatusForVerifiedDomain) в виде строки в политике MTA-STS.

18. Сообщение: 'ES002: Не найдена ожидаемая запись MX для сравнения политики. Сначала включите функцию DNSSEC для домена [{domain}].
    Причина: MTA-STS обнаружен, но состояние DNSSEC домена не было восстановлено.
    Необходимые действия: Выполните шаги, описанные в разделе "Настройка входящего трафика SMTP DANE с DNSSEC".

Устранение проблем с потоком обработки почты с помощью входящего трафика SMTP DANE с DNSSEC

Существуют три основных сценария возникновения проблем с потоком обработки почты после включения входящего трафика SMTP DANE с DNSSEC:

1. Проблема с ошибкой проверок SMTP DANE: Сведения о том, как устранить эту проблему, см. в разделе Устранение сбоев проверок SMTP DANE.
2. Проблема с ошибкой проверок DNSSEC: Сведения о том, как устранить эту проблему, см. в разделе Устранение сбоев проверок DNSSEC.
3. Проблема со значением MX: Сведения о том, как устранить эту проблему, см. в разделе Устранение проблем со значением MX.

Устранение сбоев проверок SMTP DANE

Чтобы смягчить влияние проверок SMTP DANE, выполните следующую команду:

Disable-SmtpDaneInbound -DomainName <DomainName>

Устранение ошибок проверок DNSSEC

1. Чтобы устранить влияние сбоя проверок DNSSEC, необходимо отключить DNSSEC в домене (contoso.com) через поставщика услуг DNS.

   Примечание.

   Если отключение DNSSEC не устраняет проблему, возможно, проблема связана со значением MX.

2. Отключите DNSSEC в своем домене через своего поставщика услуг DNS. Затем отправьте запрос в службу поддержки у своего поставщика услуг DNS, чтобы узнать, как безопасно повторно включить DNSSEC для вашего домена.

Устранение проблем со значением MX

1. Убедитесь, что значение MX совпадает со значением в Центре> администрирования Microsoft 365 - Параметры -> Домены.

2. Выберите домен, выберите DNS-записи и запустите "Проверка работоспособности".

3. Убедитесь, что запись MX отображается как "ОК". Если это не так, обновите значение до того, которое представлено в Центре администрирования.

4. Перейдите к своему регистратору DNS и найдите запись MX для своего домена. Значение имени узла:

   <MX token>.<subdomain>.mx.microsoft

5. Создайте вторую запись MX со следующим значением имени узла и установите приоритет 20:

   <MX token>.mail.protection.outlook.com

   Примечание.

   Замените значение "Маркер MX" маркером MX из текущей записи MX для вашего домена, найденной на шаге 4. Например, маркером MX для contosotest.com является contosotest-com.

6. Убедитесь, что запись MX, созданная на шаге 5, работает.

   Важно!

   Один из способов убедиться, что вторая запись MX работает, — использовать анализатор удаленного подключения Microsoft Remote Connectivity Analyzer.

   1. Введите домен (например, contoso.com) в тест; и выберите "Выполнить тест".
   2. Откройте Шаги теста.
   3. Откройте статью "Шаги тестированиявходящей почты SMTP для домена "admin@(домен)".
   4. Откройте раздел "Дополнительные сведения" в разделе "Попытка получить записи DNS MX для домена "(домен)".
   5. Убедитесь, что запись MX (маркер MX).mail.protection.outlook.com работоспособна.

7. Если поток обработки почты работает с записями MX token.mail.protection.outlook.com MX, выполните следующую команду:

   Disable-DnssecForVerifiedDomain -DomainName <DomainName>

8. Удалите запись DNSSEC MX, которая соответствует приведенным ниже значениям.

   <MX token>.<subdomain>.mx.microsoft

9. Убедитесь, что запись MX, созданная на шаге 5, является единственной записью MX и ей присвоен приоритет 0 (наивысший приоритет).

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

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

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

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

1. Портал Центра администраторов Exchange в представлении "Сведения о трассировке сообщений".

2. Отчеты о недоставке создаются, когда сообщение не отправляется из-за сбоя DANE или DNSSEC.

3. Средство анализа удаленного подключения 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 не создает ошибку dnssec-invalid 4/5.7.324. Он генерирует общую ошибку DNS:

   4/5.4.312 DNS query failed

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

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

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

1. Проверьте правильность ввода целевого адреса электронной почты.
2. Сообщите администратору целевой электронной почты о получении этого кода ошибки, чтобы он мог определить, правильно ли настроен конечный сервер для получения сообщений с использованием TLS.
3. Повторите отправку сообщения и просмотрите сведения трассировки сообщения на портале Центра администратор Exchange.

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

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

1. Сообщите администратору целевой электронной почты, что вы получили этот код ошибки, и введите строку с кодом ошибки.
2. Подождите время, пока сертификат сервера назначения будет обновлен и запись TLSA будут ссылаться на новый сертификат. Затем повторите попытку отправки сообщения и просмотрите сведения трассировки сообщения на портале Центра администраторов Exchange.

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

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

1. Сертификат конечного почтового сервера не соответствует тому, что ожидает подлинная запись TLSA.
2. Подлинная запись TLSA настроена неправильно.
3. Домен назначения подвергается атаке.
4. Любой другой сбой DANE.

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

1. Сообщите администратору целевой электронной почты о получении этого кода ошибки и предоставьте строку с кодом ошибки.
2. Подождите время для администратора электронной почты получателя, чтобы проверить свою конфигурацию DANE и действительность сертификата почтового сервера. Затем повторите попытку отправки сообщения и просмотрите сведения трассировки сообщения на портале Центра администраторов Exchange.

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

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

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

1. Сообщите администратору целевой электронной почты о получении этого кода ошибки и предоставьте строку с кодом ошибки.
2. Подождите время, пока администратор целевой электронной почты проверит конфигурацию DNSSEC своего домена. Затем повторите попытку отправки сообщения и просмотрите сведения трассировки сообщения на портале Центра администраторов Exchange.

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

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

1. Внедрение SMTP TLS-RPT (Transport Layer Security Reporting), введенного в RFC8460
2. Использование средства Remote Connectivity Analyzer Microsoft Remote Connectivity Analyzer

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

В следующей таблице показан пример записи.

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

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

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

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

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

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

1. Проверьте адрес электронной почты.
2. Чтобы можно было определить почтовый сервер, связанный с оператором об ошибке, найдите IP-адрес, связанный с оператором об ошибке.
3. Проверьте параметры почтового сервера, чтобы убедиться, что он настроен на прослушивание SMTP-трафика (обычно это порты 25 и 587).
4. Подождите несколько минут и повторите тест с помощью средства Remote Connectivity Analyzer.
5. Если ошибка по-прежнему не появляется, попробуйте удалить запись TLSA и снова запустите тест с помощью средства Remote Connectivity Analyzer.
6. Если сбои отсутствуют, это может означать, что почтовый сервер, используемый для получения почты, не поддерживает STARTTLS. Возможно, вам придется обновить систему до той, которая поддерживает STARTTLS, чтобы использовать DANE.

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

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

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

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

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

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

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

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

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

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

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

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

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

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 служат той же цели, но DANE требует DNSSEC для DNS-аутентификации, в то время как MTA-STS полагается на центры сертификации.

Почему оппортунистического TLS недостаточно?

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

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

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

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

• Поиск и устранение неполадок после добавления домена и записей DNS
• Обзор DNSSEC
• Использование протокола DMARC для проверки электронной почты и действий по настройке
• Использование DKIM для работы с электронной почтой в личном домене
• Как платформа политики отправителей (SPF) предотвращает спуфинг
• Транспорт Exchange Online Новости с Microsoft Ignite 2020
• RFC8461 (ietf.org)