Прочитать на английском

Поделиться через


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

Протокол 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 часов повтора, срок действия сообщения истечет, и отправителю будет создан отчет об ошибке с информацией об ошибке.

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

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

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

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

Снимок экрана: пример записи TLSA.

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

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

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

1 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 Сертификат Используйте полный сертификат.
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 сведений открытого ключа субъекта из сертификата целевого сервера.

В соответствии с рекомендациями по реализации 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 не поддерживается целевым сервером.

    Снимок экрана: поток почты Exchange Online с SMTP DANE.

Технология Дополнительные сведения
Агент передачи почты — строгая транспортная безопасность (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 с DNSSEC

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

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

  1. Домен должен быть добавлен как "Принятый домен", а состояние домена должно быть "Исправно" в центре Microsoft 365 Admin. В документации предполагается, что запись MX домена имеет приоритет 0 или 10 и что отсутствует резервная или вторичная запись MX. Если у вас есть резервная запись MX, необходимо тесно сотрудничать с администратором Exchange Online, чтобы обеспечить правильное выполнение изменений.
  2. Чтобы получить полные преимущества этой функции в области безопасности, убедитесь, что вы включили DNSSEC для вашего домена.
  3. У вас должен быть доступ к Exchange Online PowerShell и разрешения на выполнение командлетов, описанных в Exchange Online PowerShell.
  4. Если домен, который вы хотите защитить с помощью входящего SMTP DANE с DNSSEC, указан в любой конфигурации smarthost или в соединителях, необходимо переключить имя tenantname.mail.protection.outlook.com smarthost на , прежде чем выполнять действия.

Примечание

Если вы хотите включить DNSSEC для домена, использующего сторонний шлюз, это можно сделать, выполнив шаги 1–3, следуя примечаниям в конце шага 3 для сторонних шлюзов.

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

Если вы хотите настроить входящий SMTP DANE с DNSSEC для принятого домена contoso.com, а ваши бизнес-партнеры используют соединители к вашей contoso-com.mail.protection.outlook.com конечной точке, необходимо поработать с партнерами, чтобы они обновили свои соединители для ссылки на tenantname.onmicrosoft.com конечную точку или конечную точку tenantname.mail.protection.outlook.com , прежде чем настраивать входящий SMTP DANE с DNSSEC. В противном случае после завершения включения соединители ваших бизнес-партнеров завершаются ошибкой. После завершения включения партнеры могут использовать новую contoso-com.<random>.mx.microsoft конечную точку для повторного создания исходного соединителя.

Настройка входящего SMTP DANE с DNSSEC

Примечание

Подготовка и обновление записей DNS может занять некоторое время. Изменения DNS могут занять больше времени, чем ожидалось, чтобы стать видимыми из-за нескольких уровней кэширования.

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

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

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

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

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

  3. Для домена, для которого требуется включить SMTP DANE с DNSSEC, необходимо сначала включить DNSSEC в домене, выполнив следующую команду (замените "domain" именем выбранного домена, например 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])" в анализаторе удаленного подключения Майкрософт: тестовые входные данные". Если почта течет должным образом, вам НЕ нужно продолжать выполнять приведенные ниже действия. Если вы хотите включить SMTP DANE для этого домена, перейдите к шагу 7.

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

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

  5. Убедитесь, что новый MX работает через тест входящего SMTP Email (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". Затем обновите срок жизни для записи MX, заканчивающегося в mx.microsoft, до 3600 секунд. При необходимости можно убедиться, что все работает должным образом с помощью теста DNSSEC (убедитесь, что вы выбрали "Проверка DNSSEC" во время тестового ввода, а не "Проверка DANE [включая DNSSEC])" в анализаторе удаленного подключения. Возможно, потребуется повторить этот тест в зависимости от кэширования DNS и TCL.

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

    Снимок экрана: пример выходных данных, уведомляющих о том, что домены успешно прошли проверку DNSSEC.

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

    Enable-SmtpDaneInbound -DomainName <DomainName>
    
    Результат ErrorData
    Успешно
  9. Убедитесь, что запись TLSA была распространена (что может занять 15–30 минут) с помощью выбранного онлайн-средства и анализатора удаленного подключения Майкрософт: тестовый ввод.

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

    Снимок экрана: пример выходных данных, уведомляющих о том, что домены успешно прошли тест проверки Dane.

    Exchange Online размещает несколько записей TLSA для повышения надежности успешной проверки SMTP DANE. Ожидается, что проверка некоторых записей TLSA может завершиться ошибкой. Если 1 запись 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, созданный во время включения функции. Стороннему поставщику НЕ СЛЕДУЕТ использовать старое имя узла записи MX.> contoso-com.mail.protection.outlook.com так как Exchange Online удалит запись A примерно в течение 2 дней (48 часов) после включения функции после достижения общедоступной версии.
  5. Полностью делегированные домены: домены, размещенные корпорацией Майкрософт и использующие делегирование NS, чтобы серверы имен Майкрософт были полномочными для домена, поддерживаются входящей поддержкой SMTP DANE с DNSSEC. Мы намерены поддерживать входящий SMTP DANE с DNSSEC для этих доменов; однако ETA неизвестен.

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

Проблемы с включением и отключением DnssecForVerifiedDomain и включением и отключением smtpDane входящего трафика
  1. DomainNotFound

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

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

    DNSSEC

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

    SMTP DANE

    Результат ErrorData
    Error ErrorCode: 'DomainNotFound' ErrorDetails 'SMTP DANE включение...
  2. DnsSecOperationFailed

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

    DNSSEC

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

    SMTP DANE

    Результат ErrorData
    Error ErrorCode: "DnssecOperationFailed" ErrorDetails 'SMTP DANE включает ...
  3. PartitionNotFound

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

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

    Сообщение (DNSSEC): "Указанный домен является доменом onmicrosoft: 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 для домена [{domain}].
    Причина. При проверке конфигурации домена в Exchange Online мы обнаружили, что домен не был добавлен в Exchange Online. Если вы думаете, что вы уже добавили этот домен в Exchange Online, повторите попытку выполнения командлета, так как это может быть временной проблемой.
    Действия для выполнения: повторите командлет. Если сбой продолжается, перейдите в центр Microsoft 365 Admin и завершите процесс настройки для этого домена.

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

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

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

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

  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 с более высокими предпочтениями, чем ожидалось.
    Действия для выполнения. Задайте приоритет 20 для устаревшей записи MX (оканчивающейся на mail.protection.outlook.com, mail.eo.outlook.com или mail.protection.outlook.de).

  11. Сообщение: "EX007: запись MX не найдена".
    Причина. Во время проверки MX мы не нашли запись MX, соответствующую ожидаемой.
    Действия, которые нужно выполнить: просмотрите записи MX в домене. Убедитесь, что одна запись MX соответствует ожидаемой записи, которая выводится после выполнения или Enable-DnssecForVerifiedDomainGet-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 для домена [{домен}].
    Причина. Во время проверки MX возникла общая ошибка DNS.
    Действия для выполнения. Повторите выполнение командлета после проверки конфигурации записей MX для домена. Для некоторых поставщиков DNS распространение DNS может занять до 48 часов.

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

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

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

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

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

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

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

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

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

    Примечание

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

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

Устранение проблем со значением MX
  1. Убедитесь, что значение MX совпадает со значением в центре Microsoft 365 Admin —> параметры —> домены.

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

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

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

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

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

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

    Примечание

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

  6. Убедитесь, что mx, созданный на шаге 5, работает.

    Важно!

    Один из способов убедиться, что вторая запись MX работает, — использовать анализатор удаленного подключения (Майкрософт).

    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 и используется, когда целевой домен объявляет о поддержке DANE. Чтобы воспользоваться преимуществами отправки электронной почты с помощью проверок DNSSEC и DANE, сообщите своим деловым партнерам, с которыми вы обмениваетсяе электронной почтой, что они должны реализовать DNSSEC и DANE, чтобы они могли получать электронную почту с помощью этих стандартов.

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

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

  1. На портале Exchange Администратор Center в представлении Сведения о трассировки сообщений.

  2. NDR, создаваемые, если сообщение не отправляется из-за сбоя 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 не создает ошибку 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. Внедрение ПРОТОКОЛА SMTP TLS-RPT (отчеты о безопасности транспортного уровня), появилось в RFC8460
  2. Использование средства анализатора удаленного подключения 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.

Данные следующей таблицы являются примером записи:

Тип Доменное имя TTL Запись
TXT _smtp._tls.microsoft.com 3600 v=TLSRPTv1; rua=https://tlsrpt.azurewebsites.net/report

Второй способ — использовать анализатор удаленного подключения 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.

Примечание

В настоящее время, когда домен сигнализирует о том, что он поддерживает 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

Примечание

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

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

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

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

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

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

Примечание

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

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

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

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

Примечание

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

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

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

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

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

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

Примечание

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

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

Примечание

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

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

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

При отправке исходящего сообщения электронной почты, если в принимающем домене включен 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)