Использование протокола DMARC для проверки электронной почты

Совет

Знаете ли вы, что вы можете попробовать функции в Microsoft 365 Defender для Office 365 план 2 бесплатно? Используйте 90-дневную пробную версию Defender для Office 365 в центре пробных версий портала Microsoft 365 Defender. Сведения о том, кто может зарегистрироваться и условия пробной версии , см. здесь.

Область применения

Проверка подлинности, отчетность и соответствие сообщений на основе домена (DMARC) работает с Sender Policy Framework (SPF) и DomainKeys Identified Mail (DKIM) для проверки подлинности отправителей почты.

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

Совет

Посетите каталог Ассоциации информационной безопасности Майкрософт (MISA), чтобы просмотреть сторонних поставщиков, предлагающих услуги отчетности DMARC для Microsoft 365.

Совет

Вы видели наши пошаговые руководства? Конфигурация 1-2-3s и без излишеств, для администраторов в спешке. См. инструкции по включению отчетов DMARC для Microsoft Online Email адреса маршрутизации (MOERA) и припаркованные домены.

Как SPF в сочетании с протоколом DMARC обеспечивают защиту электронной почты в Microsoft 365?

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

  • Адрес Mail From: идентифицирует отправителя и указывает, куда отправлять обратные уведомления, если есть проблема с доставкой сообщения (например, уведомления о недоставке). Адрес Mail From отображается в конверте сообщения электронной почты и не отображается вашим почтовым приложением. Иногда его называют адресом 5321. Mail From или адресом обратного пути.

  • "From" address — адрес, который указывается в почтовом приложении как адрес отправителя. Адрес From идентифицирует автора электронного письма. Этот адрес указывает автора сообщения, вернее, почтовый ящик человека или систему, где оно было создано. Адрес From иногда называется адресом отправителя 5322. From.

SPF использует запись DNS TXT для перечисления авторизованных отправляющих IP-адресов для данного домена. Как правило, проверки SPF выполняются только для адреса 5321.MailFrom. Адрес 5322.From не проходит проверку подлинности, когда вы используете SPF сам по себе, что допускает сценарий, когда пользователь получает сообщение, прошедшее проверку SPF, но имеет поддельный адрес отправителя 5322.From. Например, рассмотрим следующую запись SMTP:

S: Helo woodgrovebank.com
S: Mail from: phish@phishing.contoso.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 User,
S:
S: We need to verify your banking details.
S: Please click the following link to verify that Microsoft has the right information for your account.
S:
S: https://short.url/woodgrovebank/updateaccount/12-121.aspx
S:
S: Thank you,
S: Woodgrove Bank
S: .

В этой записи имеются следующие адреса отправителей:

  • Почта с адреса (5321.MailFrom): phish@phishing.contoso.com

  • С адреса (5322.From): security@woodgrovebank.com

Если вы настроили SPF, принимающий сервер выполняет проверку почты с адреса phish@phishing.contoso.com. Если сообщение получено из допустимого источника для домена phishing.contoso.com, то проверка SPF проходит успешно. Так как почтовый клиент отображает только адрес From, пользователь видит, что это сообщение пришло от security@woodgrovebank.com. Ввиду того, что использовалась лишь одна инфраструктура SPF, проверка допустимости адреса woodgrovebank.com никогда не выполнялась.

Если используется DMARC, принимающий сервер также проверяет адрес "От". В приведенном выше примере при наличии записи DMARC TXT для woodgrovebank.com проверка адреса отправителя завершается неудачей.

Что такое запись DMARC TXT?

Аналогично записям DNS для SPF, запись для DMARC представляет собой текстовую запись DNS (TXT), которая позволяет предотвратить спуфинг и фишинг. Записи DMARC TXT публикуются в DNS. Записи DMARC TXT позволяют проверить происхождение сообщения электронной почты путем сверки IP-адреса автора письма с предполагаемым владельцем отправляющего домена. Запись DMARC TXT позволяет определить уполномоченные серверы исходящей электронной почты. Конечные почтовые системы в свою очередь проверяют, были ли получаемые сообщения отправлены уполномоченными серверами исходящей электронной почты.

Запись DMARC TXT корпорации Майкрософт имеет примерно следующий вид:

_dmarc.microsoft.com.   3600    IN      TXT     "v=DMARC1; p=none; pct=100; rua=mailto:d@rua.contoso.com; ruf=mailto:d@ruf.contoso.com; fo=1"

Посетите каталог MISA, чтобы просмотреть других сторонних поставщиков, предлагающих услуги отчетности DMARC для Microsoft 365.

Настройка протокола DMARC для входящей почты

Вам не нужно ничего делать, чтобы настроить протокол DMARC для почты, которую вы получаете в Microsoft 365. Все выполняется автоматически. Если хотите узнать, что происходит с почтой, которая не прошла наши проверки DMARC, ознакомьтесь c разделом Как Microsoft 365 обрабатывает входящую почту, не прошедшую проверки DMARC.

Настройка DMARC для исходящей почты из Microsoft 365

Если вы пользуетесь Microsoft 365 без личного домена (вы используете onmicrosoft.com), инфраструктура политики отправителей уже автоматически настроена и в Microsoft 365 автоматически создается подпись DKIM для вашей исходящей почты (дополнительные сведения об этой подписи см. в разделе Настройка по умолчанию для DKIM и Microsoft 365). Чтобы настроить DMARC для организации, необходимо сформировать запись DMARC TXT для домена onmicrosoft.com и опубликовать ее в DNS с помощью Администратор Office 365 Center> Settings Domains > (Домены > onmicrosoft.com добавить запись домена>).

Если у вас есть личный домен или вы используете локальные серверы Exchange вместе с Microsoft 365, вам необходимо вручную настроить DMARC для исходящей почты. Настройка DMARC для личного домена включает следующие шаги:

Шаг 1. Определение допустимых источников почты для домена

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

  • Какие IP-адреса используются для отправки почты из моего домена?

  • Будут ли совпадать домены в адресах 5321.MailFrom и 5322 в сообщениях, отправляемых третьими сторонами от моего имени?

Шаг 2. Настройка SPF для вашего домена

Теперь, когда у вас есть список всех допустимых отправителей, можно приступать к выполнению инструкций из статьи Настройка SPF для предотвращения спуфинга.

Например, предположим, что для отправки почты с домена contoso.com используются Exchange Online, локальный сервер Exchange с IP-адресом 192.168.0.1 и веб-приложение с IP-адресом 192.168.100.100. Тогда запись SPF TXT будет выглядеть следующим образом:

contoso.com  IN  TXT  " v=spf1 ip4:192.168.0.1 ip4:192.168.100.100 include:spf.protection.outlook.com -all"

Рекомендуется, чтобы в записи SPF TXT учитывались сторонние отправители.

Шаг 3. Настройка DKIM для вашего личного домена

После настройки SPF, вам нужно настроить DKIM. DKIM позволяет добавлять цифровую подпись в заголовки сообщений электронной почты. Если вы не настроите DKIM и вместо этого разрешите Microsoft 365 использовать конфигурацию DKIM по умолчанию для своего домена, DMARC может завершиться сбоем. Этот сбой может произойти из-за того, что конфигурация DKIM по умолчанию использует исходный домен onmicrosoft.com в качестве адреса 5321.MailFrom, а не личный домен. Это создает несоответствие между адресами 5321.MailFrom и 5322.From во всех электронных письмах, отправляемых с этого домена.

Если у вас имеются сторонние отправители, которые отправляют почту от вашего имени, и адреса 5321.MailFrom и 5322.From в такой почте не совпадают, то проверки DMARC для такой почты будут завешаться сбоем. Чтобы избежать этого, необходимо настроить DKIM для своего домена с учетом сведений о таких сторонних отправителях. Благодаря этому Microsoft 365 сможет проверять подлинность электронной почты из таких сторонних служб. Кроме того, с помощью этого метода другие почтовые системы, такие как Yahoo, Gmail и Comcast, могут проверять почту, отправляемую в эти системы сторонними почтовыми службами, так, будто она была отправлена вами. Преимущество этого заключается в том, что ваши клиенты могут устанавливать отношения доверия с вашим доменом, независимо от расположения вашего почтового ящика. В то же время Microsoft 365 не будет отмечать сообщения как спам из-за спуфинга, поскольку почта будет проходить проверку подлинности для вашего домена.

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

Шаг 4. Создание записи DMARC TXT для вашего домена

Хотя есть и другие параметры синтаксиса, которые здесь не упоминаются, это наиболее часто используемые параметры для Microsoft 365. Создайте запись DMARC TXT для вашего домена в следующем формате:

_dmarc.domain  TTL  IN  TXT  "v=DMARC1; p=policy; pct=100"

Где:

  • domain — домен, который нужно защитить. По умолчанию запись защищает почту из домена и всех его поддоменов. Например, если указать "_dmarc.contoso.com", то DMARC будет обеспечивать защиту из этого домена и всех его поддоменов, таких как housewares.contoso.com или plumbing.contoso.com.

  • TTL — этот параметр всегда должен быть равен одному часу. Срок жизни (TTL) измеряется либо в часах (1 час), либо в минутах (60 минут) или в секундах (3 600 секунд). Это зависит от регистратора доменных имен.

  • pct=100 — обозначает, что это правило следует применять в отношении абсолютно всей почты.

  • policy — определяет политику, которой должен руководствоваться принимающий сервер в случае, если почта не прошла проверки DMARC. Для этого параметра можно задать значение "none", "quarantine" или "reject".

Чтобы узнать больше о параметрах, которые следует использовать, ознакомьтесь с понятиями, изложенными в разделе Рекомендации по реализации протокола DMARC в Microsoft 365.

Примеры:

  • Параметру "policy" присвоено значение "none"

    _dmarc.contoso.com 3600 IN  TXT  "v=DMARC1; p=none"
    
  • Параметру "policy" присвоено значение "quarantine"

    _dmarc.contoso.com 3600 IN  TXT  "v=DMARC1; p=quarantine"
    
  • Параметру "policy" присвоено значение "reject"

    _dmarc.contoso.com  3600 IN  TXT  "v=DMARC1; p=reject"
    

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

Почта DMARC

Предостережение

Сообщения не могут отправляться ежедневно.

В этом примере запись DMARC TXT: dmarc.microsoft.com. 3600 IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:d@rua.example.com; ruf=mailto:d@ruf.example.com; fo=1", вы можете увидеть адрес rua . Этот адрес используется для отправки "совокупной обратной связи" для анализа, который используется для создания отчета.

Совет

Посетите каталог MISA, чтобы просмотреть других сторонних поставщиков, предлагающих услуги отчетности DMARC для Microsoft 365. Дополнительные сведения об адресах rua DMARC см. в статье Доменная проверка подлинности сообщений, создание отчетов и соответствие IETF.org (DMARC).

Рекомендации по реализации протокола DMARC в Microsoft 365

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

  1. Организуйте отслеживание влияния реализации DMARC

    Начните с простой записи режима отслеживания для поддомена или домена, запрашивающих у получателей DMARC отправку статистики о сообщениях, которые, как им видно, используют ваш домен. Запись режима отслеживания — это запись DMARC TXT, в которой параметру политики присвоено значение "none" (p=none). Многие компании публикуют запись DMARC TXT со значением p=none, потому что они не уверены в том, сколько электронной почты они могут потерять, опубликовав более строгую политику DMARC.

    Это можно сделать даже до реализации SPF или метода DKIM в своей инфраструктуре обмена сообщениями. Однако вы не сможете организовать эффективное помещение почты в карантин или ее отклонение с помощью DMARC, пока также не реализуете SPF и DKIM. При введении SPF и DKIM, отчеты, созданные с помощью DMARC, будут показывать количество и источники сообщений, прошедших эти проверки, по сравнению с теми, которые не прошли. Можно с легкостью увидеть, какой объем допустимого трафика подвергается проверкам, а какой — нет. После чего можно устранить любые возникшие проблемы. Вы также сможете увидеть объем отправляемых мошеннических сообщений и источники отправки.

  2. Запросите у внешних почтовых систем помещение на карантин почты, не прошедшей проверки DMARC

    Если вы полагаете, что весь или почти весь ваш допустимый трафик защищен с помощью инфраструктуры SPF и DKIM, а также понимаете последствия реализации протокола DMARC, можно внедрить политику карантина. Политика карантина — это запись DMARC TXT, в которой параметру политики присвоено значение "quarantine" (p=quarantine). Таким образом вы просите получателей DMARC помещать сообщения из этого домена, которые не прошли проверки DMARC, в локальный аналог папки нежелательной почты, а не в папки входящей почты клиентов.

  3. Запросите у внешних почтовых систем не принимать сообщения, не прошедшие проверки DMARC

    Последним шагом является реализация политики отклонения. Политика отклонения — это запись DMARC TXT, в которой параметру политики присвоено значение "reject" (p=reject). Таким образом вы просите получателей DMARC не принимать сообщения, которые не прошли проверки DMARC.

  4. Как настроить DMARC для поддомена?

    DMARC реализуется путем публикации политики в виде записи TXT в DNS и является иерархической (например, политика, опубликованная для contoso.com, будет применяться к sub.domain.contoso.com, если для поддомена явно не определена другая политика). Это удобно, так как организации могут указывать меньшее число записей DMARC верхнего уровня для большего покрытия. Следует соблюдать осторожность при настройке явных записей DMARC поддоменов, если вы не хотите, чтобы поддомены наследовали запись DMARC домена верхнего уровня.

    Кроме того, вы можете добавить политику с подстановочным знаком для DMARC, если поддомены не должны отправлять почту, добавив значение sp=reject. Например:

    _dmarc.contoso.com. TXT "v=DMARC1; p=reject; sp=reject; ruf=mailto:authfail@contoso.com; rua=mailto:aggrep@contoso.com"
    

Как Microsoft 365 обрабатывает исходящую почту, не прошедшую проверку DMARC

Если исходящее из Microsoft 365 сообщение не прошло проверки DMARC, а вы реализовали политику карантина (p=quarantine) или политику отклонения (p=reject), то такое сообщение перенаправляется через Пул доставки сообщений с более высокой степенью опасности для исходящих сообщений. Для исходящей электронной почты нет переопределения.

Если вы опубликуете политику отклонения DMARC (p=reject), другой клиент в Microsoft 365 не сможет подделать этот домен, поскольку сообщения не смогут передавать SPF или DKIM для этого домена при ретрансляции исходящего сообщения через службу. Однако, если вы опубликуете политику отклонения DMARC, но не проверите подлинность всей своей электронной почты через Microsoft 365, некоторые из них могут быть помечены как спам для входящей электронной почты (как описано выше) или отклонены, если вы этого не сделаете. Не публикуйте SPF и не пытайтесь ретранслировать его через службу. Это может произойти, например, если при создании записи DMARC TXT вы забыли включить в нее ряд IP-адресов серверов и приложений, отправляющих почту от имени вашего домена.

Как Microsoft 365 обрабатывает входящую почту, не прошедшую проверку DMARC

Если политика DMARC отправляющего сервера имеет значение p=reject, Exchange Online Protection (EOP) будет отмечать сообщения как поддельные, а не отклонять их. Другими словами, в случае исходящей почты служба Microsoft 365 рассматривает политики p=reject и p=quarantine как одинаковые. Администраторы могут настроить действия для сообщений, классифицированных как поддельные, в политике защиты от фишинга.

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

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

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

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

Дополнительные сведения см. в статье Создание списков надежных отправителей.

Как Microsoft 365 использует Authenticated Received Chain (ARC)

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

В настоящее время Microsoft 365 использует ARC для подтверждения результатов проверки подлинности, если корпорация Майкрософт является подтверждающим центром ARC, но в будущем планируется добавить поддержку сторонних подтверждающих центров.

Устранение неполадок реализации DMARC

Если вы настроили записи MX своего домена, где EOP не является первой записью, сбои DMARC не будут применяться для вашего домена.

Если вы являетесь клиентом и основная запись MX вашего домена не указывает на EOP, вы не сможете воспользоваться преимуществами DMARC. Например, DMARC не будет работать, если вы настроите запись MX таким образом, чтобы она указывала на локальный почтовый сервер, а затем перенаправите почту в EOP с помощью соединителя. В этом сценарии принимающий домен является одним из ваших обслуживаемых доменов, но EOP не является основным MX. К примеру, допустим, что в записи MX домен contoso.com указывает сам на себя и использует EOP в качестве вспомогательной записи MX, тогда запись MX для домена contoso.com будет выглядеть следующим образом:

contoso.com     3600   IN  MX  0  mail.contoso.com
contoso.com     3600   IN  MX  10 contoso-com.mail.protection.outlook.com

Вся или почти вся электронная почта сначала будет перенаправляться в домен mail.contoso.com, поскольку это основная система обмена электронной почтой, а затем в домен EOP. В некоторых случаях вы можете даже не указать EOP в записи MX и просто воспользоваться соединителями для перенаправления почты. EOP не обязательно должен быть первой записью для проверки DMARC. Просто это обеспечивает проверку того, что все локальные серверы и серверы, не связанные с Office 365, выполняют проверки DMARC. DMARC может быть применен для домена клиента (не сервера), когда вы настроите запись DMARC TXT, но фактическое принудительное выполнение зависит от принимающего сервера. Если настроить EOP как сервер-получатель, EOP принудительно применит DMARC.

Изображение устранения неполадок для DMARC

Дополнительные сведения

Хотите узнать больше о протоколе DMARC? Эти ресурсы помогут вам.

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

  • Пройдите курс обучения DMARC, предлагаемый компанией M3AAWG (Messaging, Malware, Mobile Anti-Abuse Working Group).

  • Воспользуйтесь контрольным списком, представленным на сайте dmarcian.

  • Посетите сайт источника по адресу DMARC.org.

См. также

Как Microsoft 365 использует инфраструктуру политики отправителей (SPF) для предотвращения спуфинга

Настройка SPF в Microsoft 365 для предотвращения спуфинга

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

Использование проверенных отправителей ARC для допустимых почтовых потоков