проверка подлинности Email в облачных организациях

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

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

• Sender Policy Framework (SPF) — указывает исходные почтовые серверы, которым разрешено отправлять почту для домена.
• DomainKeys Identified Mail (DKIM): использует домен для цифровой подписи важных элементов сообщения, чтобы гарантировать, что сообщение остается неизменным при передаче.
• Проверка подлинности, отчеты и соответствие сообщений на основе домена (DMARC). Указывает действие для сообщений, которые не выполняют проверку SPF или DKIM на наличие отправителей в домене, и указывает, куда отправлять результаты DMARC (отчеты).
• Цепочка получения с проверкой подлинности (ARC): сохраняет исходные сведения о проверке подлинности электронной почты известными службами, которые изменяют сообщения при передаче. Конечный почтовый сервер может использовать эти сведения для проверки подлинности сообщений, которые в противном случае завершаются ошибкой DMARC.

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

Чтобы настроить проверку подлинности электронной почты для почты , отправляемой из организаций Microsoft 365 с облачными почтовыми ящиками, см. следующие статьи:

• Настройка SPF для определения допустимых источников электронной почты для пользовательских облачных доменов
• Настройка DKIM для подписывания почты из облачного домена
• Настройте DMARC для проверки домена адреса From для облачных отправителей

Чтобы предотвратить сбои проверки подлинности электронной почты из-за служб, которые изменяют входящие сообщения, отправляемые в организацию Microsoft 365, см. статью Настройка доверенных запечатывщиков ARC.

Сведения о диагностике и устранении ошибок проверки подлинности электронной почты см. в статье Устранение неполадок с проверкой подлинности электронной почты в Microsoft 365.

В этой статье также описывается, почему требуется проверка подлинности электронной почты в Интернете, как SPF, DKIM и DMARC работают вместе для проверки подлинности отправителей сообщений электронной почты, как Microsoft использовать неявную и составную проверку подлинности электронной почты для проверки подлинности в Microsoft 365 и как избежать сбоев проверки подлинности электронной почты при отправке почты в Microsoft 365.

Зачем нужна проверка подлинности электронной почты в Интернете

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

Стандартное smtp-сообщение электронной почты состоит из конверта сообщения и содержимого сообщения:

• Конверт сообщения содержит сведения для передачи и получения сообщения между SMTP-серверами. Конверт сообщения описан в документе RFC 5321. Получатели никогда не видят конверт сообщения, так как он создается в процессе передачи сообщения.
• Содержимое сообщения разделяется на поля заголовка сообщения, которые в совокупности называются заголовком сообщения, и текста сообщения. Заголовок сообщения описан в rfc 5322.

В связи с такой структурой сообщение имеет несколько значений отправителя:

• Адрес MAIL FROM (также известный как адрес 5321.MailFrom, отправитель P1 или отправитель конверта) — это адрес электронной почты, используемый при передаче сообщения между почтовыми SMTP-серверами. Этот адрес обычно записывается в поле Заголовок Return-Path в заголовке сообщения (хотя исходный почтовый сервер может назначить другой адрес электронной почты Return-Path ). Этот адрес электронной почты используется в отчетах о недоставке (также называемых NDR или сообщениями о возврате).
• Адрес From (также известный как адрес 5322.From или отправитель P2) — это адрес электронной почты в поле заголовка From, то есть адрес электронной почты отправителя, который отображается в почтовых клиентах.

В следующем примере показана упрощенная расшифровка допустимой передачи сообщений между двумя SMTP-серверами электронной почты:

S: HELO woodgrovebank.com
S: MAIL FROM: dubious@proseware.com
S: RCPT TO: astobes@tailspintoys.com
S: DATA
S: To: "Andrew Stobes" <astobes@tailspintoys.com>
S: From: "Woodgrove Bank Security" <security@woodgrovebank.com>
S: Subject: Woodgrove Bank - Action required
S:
S: Greetings,
S:
S: We need to verify your banking details.
S: Please click the following link to verify that we have the right information for your account.
S:
S: https://short.url/woodgrovebank/updateaccount/12-121.aspx
S:
S: Thank you,
S: Woodgrove Bank
S: .

В этом примере:

• Исходный почтовый сервер представляется как woodgrovebank.com целевому почтовому серверу tailspintoys.com в команде HELO.
• Получатель сообщения — astobes@tailspintoys.com.
• Адрес MAIL FROM в конверте сообщения (используется для передачи сообщения между SMTP-серверами электронной почты) имеет значение dubious@proseware.com.
• Адрес от, отображаемый в почтовом клиенте получателя, имеет значение security@woodgrovebank.com.

Хотя это сообщение допустимо в соответствии с SMTP, домен адреса MAIL FROM (proseware.com) не соответствует домену в адресе From (woodgrovebank.com). Это сообщение является классическим примером спуфингов, когда намерение, скорее всего, обманет получателя путем маскирования истинного источника сообщения для использования в фишинговой атаке.

Очевидно, что в электронной почте SMTP необходимо проверять, действительно ли отправители сообщений являются теми, за кого себя выдают!

Совместная работа SPF, DKIM и DMARC для проверки подлинности отправителей сообщений электронной почты

Домены Интернета нуждаются в SPF, DKIM и DMARC для совместной работы для эффективной проверки подлинности электронной почты.

• SPF. Как описано в разделе Настройка SPF для определения допустимых источников электронной почты для пользовательских облачных доменов, SPF использует запись TXT в DNS, чтобы:

  • Определите допустимые источники почты из домена MAIL FROM.
  • Что делать, если почтовый сервер получателя получает почту из неизвестного источника («жесткий отказ» — отклонить сообщение; «мягкий отказ» — принять и пометить сообщение).

  Проблемы с SPF:

  • SPF проверяет источники только для отправителей в домене MAIL FROM. SPF не учитывает ни домен в поле From, ни согласованность между доменами MAIL FROM и From:

    • Злоумышленник может отправить сообщение электронной почты, которое проходит проверку подлинности SPF (ложноотрицательный), выполнив следующие действия.
      • Зарегистрируйте домен (например, proseware.com) и настройте SPF для домена.
      • Отправьте электронное письмо из допустимого источника в зарегистрированном домене, при этом адреса электронной почты в поле «От» должны относиться к другому домену (например, woodgrovebank.com).
    • Допустимый почтовый сервис, который отправляет почту от имени других доменов, может управлять адресом MAIL FROM. Другие домены и домен MAIL FROM не совпадают, поэтому сообщения не могут пройти проверку подлинности SPF (ложноположительный результат).

  • SPF прерывается после того, как сообщения сталкиваются с серверной пересылкой электронной почты, которая перенаправляет или ретранслирует сообщения.

    • Серверная пересылка электронной почты изменяет источник сообщений с исходного сервера на сервер переадресации.
    • Сервер переадресации не авторизован для отправки почты из исходного домена MAIL FROM, поэтому сообщение не может пройти проверку подлинности SPF (ложноположительный результат).

  • Для каждого домена и поддоменов требуются собственные отдельные записи SPF. Поддомены не наследуют запись SPF родительского домена. Это поведение становится проблематичным, если вы хотите разрешить электронную почту из определенных и используемых поддоменов, но запретить электронную почту из неопределенных и неиспользуемых поддоменов.

• DKIM: как описано в разделе Настройка DKIM для подписывания почты из облачного домена, DKIM использует домен для цифровой подписи важных элементов сообщения (включая адрес from) и сохраняет подпись в заголовке сообщения. Целевой сервер проверяет, не были ли изменены подписанные элементы сообщения.

  Как DKIM помогает SPF: DKIM может проверять подлинность сообщений, которые не проходят проверку SPF. Например, вы можете:

  • Сообщения из службы размещения электронной почты, где один и тот же адрес MAIL FROM используется для почты из других доменов.
  • Сообщения, проходящие через пересылку электронной почты на стороне сервера.

  Так как подпись DKIM в заголовке сообщения не затрагивается или изменяется во время пересылки электронной почты или когда служба размещения использует один и тот же адрес MAIL FROM для нескольких доменов, эти сообщения могут передавать DKIM.

  Проблемы С DKIM. Домен, который DKIM использует для подписи сообщения, не должен соответствовать домену в адресе From в почтовых клиентах.

  Как и SPF, злоумышленник может отправить сообщение электронной почты, которое проходит проверку подлинности DKIM (ложноотрицательный), выполнив следующие действия:

  • Зарегистрируйте домен (например, proseware.com) и настройте DKIM для домена.
  • Отправка электронной почты с помощью адреса электронной почты from в другом домене (например, woodgrovebank.com).

• DMARC: как описано в разделе «Настройка DMARC для проверки домена адреса From для отправителей облачных почтовых ящиков», DMARC использует SPF и DKIM для проверки согласованности доменов в адресах MAIL FROM и From. DMARC также определяет, какие действия система электронной почты получателя должна выполнять с сообщениями, которые не проходят проверку DMARC, а также указывает, куда следует отправлять результаты DMARC (как успешных, так и неуспешных проверок).

  Как DMARC дополняет SPF и DKIM: как описано ранее, SPF не пытается сопоставить домен в MAIL FROM с доменом в адресе From. Для DKIM не имеет значения, совпадает ли домен, которым подписано сообщение, с доменом в поле From.

  DMARC устраняет проблему отсутствия проверок согласования доменов в SPF и DKIM, подтверждая, что домены в адресах MAIL FROM и From совпадают.

  Проблемы с DMARC: Легитимные сервисы, которые изменяют сообщения в процессе передачи до доставки, нарушают проверки SPF, DKIM и, следовательно, DMARC.

  При автоматической пересылке сообщений между доменами или организациями согласование DMARC может нарушаться даже для легитимных отправителей сервисов. Например, если домен службы Microsoft (например, voicemail.microsoft.com) не проходит проверку DMARC после пересылки, используйте разрешающую запись с ограниченной областью действия в списке разрешений и блокировок клиента или аутентифицированную ретрансляцию, а не разрешайте весь домен отправителя.

• ARC. Как описано в разделе Настройка доверенных запечатывщиков ARC, допустимые службы, изменяющие сообщения при передаче, могут использовать ARC для сохранения исходных сведений о проверке подлинности электронной почты измененных сообщений.

  Как ARC помогает DMARC: целевая система электронной почты может идентифицировать службу как доверенный запечатыватель ARC. Затем ARC может использовать сохраненные сведения о проверке подлинности электронной почты для проверки сообщения.

Проверка подлинности входящей электронной почты для почты, отправляемой в Microsoft 365

Из-за проблем фишинга и менее полного внедрения политик строгой проверки подлинности электронной почты отправителями электронной почты в Интернете Microsoft 365 использует неявную проверку подлинности электронной почты для проверка входящей электронной почты. Неявная проверка подлинности по электронной почте расширяет обычные проверки SPF, DKIM и DMARC с помощью сигналов из других источников для оценки входящих сообщений электронной почты. К этим источникам относятся:

• Репутация отправителя.
• История отправителей
• История получателя.
• Анализ поведения.
• Другие расширенные методы.

Чтобы просмотреть оригинальное объявление Майкрософт о неявной проверке подлинности, см. раздел Море фишинга, часть 2. Расширенная защита от спуфингов в Microsoft 365.

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

Многофакторная аутентификация

Результаты неявных проверок проверки подлинности Microsoft 365 объединяются и хранятся в одном значении с именем составной проверки подлинности или compauth сокращенно. Заголовок Authentication-Results — это поле заголовка сообщения, которое записывает результаты проверок проверки подлинности электронной почты. Значение compauth добавляется в заголовок Authentication-Results в заголовках сообщений. В заголовке Authentication-Results используется следующий синтаксис:

Authentication-Results:
   compauth=<fail | pass | softpass | none> reason=<yyy>

Эти значения описываются в разделе Заголовок сообщения Authentication-results.

Администраторы и пользователи могут проверить заголовки сообщений, чтобы узнать, как Microsoft 365 определил отправителя как подозрительного или допустимого отправителя.

В следующих примерах основное внимание уделяется только результатам проверки подлинности электронной почты ( compauth значение и причина). Другие технологии защиты Microsoft 365 могут определять сообщения, которые проходят проверку подлинности электронной почты как подделанные, или определять сообщения, которые не прошли проверку подлинности электронной почты, как допустимые.

• Сценарий. Домен в записи SPF или сигнатуре DKIM не соответствует домену в адресе From.

• Результат: Сообщение может не пройти составную аутентификацию. Несмотря на сбой составной проверки подлинности, сообщение по-прежнему может быть разрешено, если другие оценки не указывают на подозрительный характер:

  Authentication-Results: spf=none (sender IP is 192.168.1.8)
    smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
    (signature was verified) header.d=maliciousdomain.com;
    contoso.com; dmarc=none action=none header.from=contoso.com;
    compauth=fail reason=001
  From: chris@contoso.com
  To: michelle@fabrikam.com
  

• Сценарий. Домен fabrikam.com не содержит записей SPF, DKIM или DMARC.

• Результат: Сообщения от отправителей в домене fabrikam.com могут завершиться ошибкой комплексной проверки подлинности:

  Authentication-Results: spf=none (sender IP is 10.2.3.4)
    smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
    (message not signed) header.d=none; contoso.com; dmarc=none
    action=none header.from=fabrikam.com; compauth=fail reason=001
  From: chris@fabrikam.com
  To: michelle@contoso.com
  

• Сценарий. Домен fabrikam.com имеет запись SPF и не содержит записи DKIM. Домены в адресах MAIL FROM и From совпадают.

• Результат. Сообщение может пройти составную проверку подлинности, так как домен, который прошел SPF, соответствует домену в адресе From:

  Authentication-Results: spf=pass (sender IP is 10.2.3.4)
    smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
    (message not signed) header.d=none; contoso.com; dmarc=bestguesspass
    action=none header.from=fabrikam.com; compauth=pass reason=109
  From: chris@fabrikam.com
  To: michelle@contoso.com
  

• Сценарий. Домен fabrikam.com содержит запись DKIM без записи SPF. Домен, который DKIM подписал сообщение, соответствует домену в адресе From.

• Результат. Сообщение может пройти составную проверку подлинности, так как домен в подписи DKIM соответствует домену в адресе From:

  Authentication-Results: spf=none (sender IP is 10.2.3.4)
    smtp.mailfrom=fabrikam.com; contoso.com; dkim=pass
    (signature was verified) header.d=outbound.fabrikam.com;
    contoso.com; dmarc=bestguesspass action=none
    header.from=fabrikam.com; compauth=pass reason=109
  From: chris@fabrikam.com
  To: michelle@contoso.com
  

• Сценарий. Домен в записи SPF или сигнатуре DKIM не соответствует домену в адресе From.

• Результат: Сообщение может не пройти составную аутентификацию:

  Authentication-Results: spf=none (sender IP is 192.168.1.8)
    smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
    (signature was verified) header.d=maliciousdomain.com;
    contoso.com; dmarc=none action=none header.from=contoso.com;
    compauth=fail reason=001
  From: chris@contoso.com
  To: michelle@fabrikam.com
  

Как избежать сбоев проверки подлинности электронной почты при отправке почты в Microsoft 365

• Настройка записей SPF, DKIM и DMARC для доменов. Используйте сведения о конфигурации, предоставленные регистратором доменных имен или службой размещения DNS. Существуют также службы сторонних корпораций, предназначенные для настройки записей проверки подлинности электронной почты.

  Многие компании не публикуют записи SPF, так как не знают все источники электронной почты для сообщений в своем домене.

  1. Начните с публикации SPF-записи, содержащей все известные вам источники отправки электронной почты (особенно те, через которые проходит корпоративный почтовый трафик), и используйте значение политики применения "soft fail" (~all). Например, вы можете:

     fabrikam.com IN TXT "v=spf1 include:spf.fabrikam.com ~all"
     

     При создании этой записи SPF Microsoft 365 обрабатывает входящие сообщения электронной почты из корпоративной инфраструктуры как прошедшие проверку подлинности. Email из неопознанных источников по-прежнему могут быть помечены как поддельные, если не удается выполнить составную проверку подлинности. Однако это поведение по-прежнему является улучшением по сравнению со всеми письмами от отправителей в домене, помеченными Microsoft 365 как поддельные. Как правило, почтовая система получателя принимает сообщения, якобы отправленные с адресов данного домена, из неидентифицированных источников, если SPF настроен с политикой мягкого отказа.

  2. Обнаружение и включение дополнительных источников электронной почты для сообщений. Например, вы можете:

     • Локальные почтовые серверы.
     • Электронная почта, отправленная SaaS-поставщиком (программное обеспечение как услуга).
     • Электронная почта, отправленная службой размещения в облаке (Microsoft Azure, GoDaddy, Rackspace, Amazon Web Services и т. д.).

     Определив все источники электронной почты для домена, вы можете обновить запись SPF, чтобы использовать значение правила принудительного применения "hard fail" (-all).

  3. Настройка DKIM для цифровой подписи сообщений.

  4. Настройте DMARC для проверки соответствия доменов в адресах MAIL FROM и From, чтобы указать, что делать с сообщениями, которые не выполняют проверки DMARC (отклонение или карантин), а также определить службы отчетов для мониторинга результатов DMARC.

  5. Если вы используете массовых отправителей для отправки электронной почты от вашего имени, убедитесь, что домен в поле От адреса соответствует домену, который проходит SPF или DMARC.

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

  • Убедитесь, что у ваших клиентов есть документация, в которую показано, как настроить SPF для своих доменов.
  • Рассмотрите DKIM-подписывание исходящей почты, даже если клиент явно не настроил DKIM для своего домена (подписывая с использованием домена по умолчанию). Вы даже можете дважды подписать сообщение электронной почты с помощью подписей DKIM (с доменом вашей компании и доменом клиента, если или когда он доступен).

  Доставка в Корпорацию Майкрософт не гарантируется, даже если вы проверяете подлинность электронной почты, полученной с вашей платформы. Но проверка подлинности по электронной почте гарантирует, что корпорация Майкрософт автоматически не будет отправлять нежелательную почту из ваших доменов клиентов только потому, что она не проходит проверку подлинности.