Dmarc record published настроить

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

Стал доступен улучшенный портал Microsoft 365 Defender. Этот новый интерфейс Центра безопасности Microsoft 365 объединяет Defender для конечной точки, Defender для Office 365, Microsoft 365 Defender и другие решения. Узнайте о новых возможностях.

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

Протокол DMARC (Domain-based Message Authentication, Reporting, and Conformance) используется в сочетании с инфраструктурой политики отправителей (SPF) и механизмом DKIM (DomainKeys Identified Mail) для проверки подлинности отправителей и подтверждения того, что сообщения, отправленные в конечные почтовые системы из вашего домена, являются доверенными. Использование технологии DMARC вместе с SPF и DKIM обеспечит дополнительную защиту от поддельной электронной почты. DMARC помогает получающим почтовым системам определить, что делать с сообщениями, отправленными из вашего домена, которые не прошли проверки SPF или DKIM.

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

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

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

«Mail From» address — указывает отправителя и адрес, на который следует отправлять уведомления о возврате, если возникнут проблемы с доставкой сообщения. Этот адрес задан в конверте сообщения и обычно не отображается почтовым приложением. Он иногда называется адресом 5321.MailFrom или адресом reverse-path.

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

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

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

Адрес отправителя (5321.MailFrom): phish@phishing.contoso.com

Адрес «От» (5322.From): security@woodgrovebank.com

Если вы настроили SPF, то принимающий сервер проверяет адрес «Отправитель» phish@phishing.contoso.com. Если сообщение получено из допустимого источника для домена phishing.contoso.com, то проверка SPF проходит успешно. Поскольку в почтовом клиенте отображается только адрес «От», пользователь видит, что это письмо отправлено с адреса 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 сторонней компании Agari. Эта компания собирает и анализирует полученные отчеты. Посетите каталог MISA, чтобы просмотреть других сторонних поставщиков, предлагающих услуги отчетности DMARC для Microsoft 365.

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

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

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

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

Если у вас есть личный домен или помимо Microsoft 365 вы также используете локальные серверы Exchange, необходимо вручную реализовать 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 будет выглядеть следующим образом:

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

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

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

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

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

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

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

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

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

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

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

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

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

Параметру «policy» присвоено значение «quarantine»

Параметру «policy» присвоено значение «reject»

Создав запись, необходимо обновить ее у регистратора доменных имен.

Почта DMARC (общедоступная предварительная версия)

Сообщения могут рассылаться не ежедневно, а сам отчет может измениться во время общедоступной предварительной версии. Электронные сообщения сводного отчета DMARC можно ожидать от учетных записей потребителей (таких как учетные записи hotmail.com, outlook.com или live.com).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как 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 домен contoso.com указывает сам на себя и использует EOP в качестве вспомогательной записи MX, тогда запись MX для домена contoso.com будет выглядеть следующим образом:

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

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

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

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

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

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

Источник