Dmarc policy not enabled что это

18.04.202218.04.2022 admin 0 Comments

Как попасть в Inbox: всё о DMARC

Рассказываем о протоколе DMARC (Domain-based Message Authentication Reporting and Conformance) — зачем он нужен, как настраивать, какие есть особенности в использовании и как читать отчёты. Это третья статья цикла о доставляемости, и в ней мы используем понятия предыдущих публикаций, поэтому перед чтением рекомендуем вспомнить про SPF и DKIM.

Что такое DMARC и зачем он нужен?

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

На примере ниже — скриншот фишингового письма, маскирующегося под рассылку от Сбербанка. Оно оформлено полностью корректно и использует почту отправителя fomin.s@sberbank.ru — что похоже на реальный корпоративный адрес сотрудника Сбербанка. В действительности при клике по ссылке юзера уводит на сайт, где скачивается zip-архив с вирусом.

Результат такой атаки — заражённые компьютеры пользователей, украденные личные данные и репутационный ущерб для компании, чьим именем домена пользуются мошенники.

Уберечься от такой рассылки Сбербанк мог, настроив политику reject для DMARC, — тогда почтовый провайдер отклонит фишинговое письмо ещё на этапе анализа на спам и письмо просто не попадёт в ящики пользователей.

Как это работает?

DMARC работает на основе протоколов аутентификации SPF и DKIM и проверяет корректность прохождения письмом проверок на SPF и DKIM, а также факт, что данные письма действительно были отправлены с доменов под контролем организации. Ключевые функции DMARC — проверка аутентификации и отправка отчётов.

По результатам проверки обновляется информация в отчётах:

DMARC позволяет отправителю указать, как поступать с письмом по результатам проверки. Это делается через указание политики DMARC, которая бывает трёх видов:

Если совсем кратко — то при использовании DMARC получатель может быть уверен, что письмо действительно отправлено именно с того емейла, который указан в поле From-email.

Синтаксис записи

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

На основе этих параметров мы получаем минимально рабочую запись:

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

Как итог, у вас может получиться следующая запись, если использовать все доступные параметры:

Как читать агрегированные отчёты?

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

Отчёты отправляются на емейл, указанный вами в параметре rua=mailto:email@domain.com.

Сам отчёт состоит из нескольких стандартных блоков.

Источник

Как исправить «Политика DMARC не включена»?

Если вы постоянно сталкиваетесь с подсказкой » DMARC policy not enabled» для вашего домена, это означает, что ваш домен не защищен от подделки и выдачи себя за другого с помощью DMARC аутентификации электронной почты. Вы можете часто сталкиваться с этой подсказкой во время обратного поиска DNS для вашего домена. Тем не менее, это часто легко исправить. В этой статье мы рассмотрим различные шаги, которые необходимо выполнить для настройки DMARC и установки правильной политики для вашего домена, чтобы вы больше никогда не сталкивались с подсказкой «Политика DMARC не включена»!

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

Для того чтобы начать внедрение DMARC для вашего домена:

Как исправить «Политика карантина/отклонения DMARC не включена»

Когда вы получаете предупреждение «Политика DMARC карантина/отклонения не включена» или иногда просто «Политика DMARC не включена» или » Нет защиты DMARC», это просто указывает на то, что ваш домен настроен с политикой DMARC, не позволяющей только мониторинг.

Если вы только начинаете свой путь аутентификации электронной почты и хотите контролировать свои домены и почтовый поток, чтобы обеспечить бесперебойную доставку почты, то мы рекомендуем вам начать с политики DMARC «none». Однако политика «нет» обеспечивает нулевую защиту от подделки, и поэтому вы будете часто сталкиваться с запросом: «Политика DMARC не включена», где вам напоминают, что ваш домен не защищен должным образом от злоупотреблений и самозванства.

Чтобы исправить это, достаточно изменить механизм политики (p) в вашей записи DMARC с p=none на p=reject/quarantine, и таким образом перейти к применению DMARC. Если ваша DMARC-запись ранее была:

Ваша оптимизированная запись DMARC будет иметь следующий вид:

v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected];

Или, v=DMARC1; p=карантин; rua=mailto:[email protected]; ruf=mailto:[email protected];

Я исправил «Политика DMARC не включена», что дальше?

После устранения ошибки «Политика DMARC не включена» мониторинг доменов должен быть непрерывным процессом, чтобы убедиться, что развертывание DMARC не влияет на доставляемость электронной почты, а наоборот, улучшает ее. Отчеты DMARC помогут вам получить видимость всех ваших каналов электронной почты, чтобы вы никогда не упускали из виду происходящее. После выбора политики внедрения DMARC, PowerDMARC поможет вам просмотреть результаты проверки подлинности электронной почты в сводных отчетах DMARC с легко читаемыми форматами, понятными каждому. Благодаря этому вы сможете увидеть 10-процентное увеличение коэффициента доставляемости электронной почты с течением времени.

Сделайте процесс развертывания DMARC максимально беспроблемным, подписавшись на наш бесплатный DMARC-анализатор уже сегодня!

Поделиться этой записью

Защита электронной почты

Прекратить подделку электронной почты и улучшить доставку электронной почты.

14-дневный бесплатный пробный период!

Последние блоги

Знания

Инструменты

Продукт

Попробуйте нас

Этот сайт использует куки-файлы. Продолжая просмотр сайта, вы соглашаетесь с нашим использованием cookie-файлов.

Настройки cookie-файлов и конфиденциальности

PowerDMARC использует куки-файлы для улучшения работы пользователей, запоминая предпочтения пользователей и устраняя необходимость повторного ввода информации при повторном посещении сайта или повторном использовании платформы. Используя услуги PowerDMARC, Вы даете согласие на использование cookie-файлов на наших сервисах.

Как мы используем cookie-файлы?

PowerDMARC использует куки-файлы для следующих целей:
— Чтобы сохранить предпочтения пользователей
— Включение определенных функций предоставляемых услуг
— Отслеживайте, как услуга предназначена для анализа данных.

Типы используемых печенья:

Куки-файлы анализа/производительности: Используя эти файлы cookie, мы можем идентифицировать и отслеживать посетителей нашего сайта. Они также помогают нам оценить активность нашего сайта и понять закономерности трафика, что позволяет нам улучшить функциональность сайта и повысить удобство работы с ним.

Функциональное печенье: Это файлы cookie, которые используются для распознавания посетителей при повторном посещении нашего сайта или повторном использовании наших услуг.

Нацеливание на печенье: Это файлы cookie, которые используются для отслеживания посещенных страниц и ссылок, за которыми следуют наши посетители.

Необходимые печенья: Файлы cookies используются для аутентификации пользователей и предотвращения мошеннического использования учетных записей пользователей.

Cookie-файлы предпочтений. Cookie-файлы настроек используются для хранения информации, которая изменяет определенные аспекты Услуги. Сюда входит информация о таких языковых предпочтениях или обо всем, что покрывается функцией «запомнить меня» пользователя.

Печенье третьих лиц: Это файлы cookie, используемые службами третьих сторон, которые устанавливают файлы cookie через наш сайт.

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

Последняя измененная дата: 20 января 2020 года

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

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

1. Что включает в себя эта Политика?
Данная информация о конфиденциальности объясняет, как мы используем Ваши персональные данные: как они собираются, как они хранятся и как они обрабатываются. Она также объясняет Ваши права в соответствии с законом, касающиеся Ваших личных данных.

2. Что такое Личные данные?
Личные данные определяются Общим Положением о защите данных (Постановление ЕС 2016/679) («GDPR») как «любая информация, относящаяся к идентифицируемому лицу, которое может быть прямо или косвенно идентифицировано, в частности, путем ссылки на идентификатор».

Личные данные, которые мы используем, приведены ниже в разделе 4.

3. Каковы мои права?
В соответствии с GDPR, если вы являетесь резидентом ЕЭЗ, у вас есть следующие права, которые мы всегда будем работать, чтобы поддержать:

Право на получение информации о сборе и использовании Ваших персональных данных. В данном Уведомлении о конфиденциальности должно быть сказано все, что вам необходимо знать, но вы всегда можете связаться с нами, чтобы узнать больше или задать любые вопросы, используя детали в Разделе 10.

Право доступа к имеющимся у нас персональным данным о Вас. В разделе 9 вам расскажут, как это сделать.

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

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

Право на возражение против использования Ваших личных данных для определенной цели или целей.

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

Права, связанные с автоматизированным принятием решений и профилированием. Мы не используем Ваши персональные данные таким образом.

Для получения более подробной информации об использовании нами ваших личных данных или осуществлении ваших прав, как указано выше, пожалуйста, свяжитесь с нами, используя данные, указанные в Разделе 10.

4. Какие личные данные вы собираете?
Мы можем собирать некоторые или все из следующих личных данных (они могут варьироваться в зависимости от ваших отношений с нами:

Имя;
Адрес;
Адрес электронной почты;
Номер телефона;
Название фирмы;
Название должности;
Профессия;
Информация об оплате;
Информация о местонахождении;
Информация, предоставленная третьими лицами;
Информация о том, как вы получаете доступ и пользуетесь нашими услугами (например: посещенные страницы, реферальный сайт);
Информация о вашем устройстве (например: анонимизированный IP-адрес, тип устройства);
Комментарии и мнения, которые вы выражаете, связываясь с нами по электронной почте, телефону или чату.

5. Как используются мои личные данные?
В соответствии с GDPR мы всегда должны иметь законное основание для использования персональных данных. Это может быть связано с тем, что данные необходимы для выполнения нами договора с вами, с тем, что вы дали согласие на использование нами ваших персональных данных, или с тем, что их использование отвечает нашим законным деловым интересам. Ваши персональные данные будут использованы в следующих целях:

Предоставление и управление вашим счетом (юридическое основание: договорное).
Предоставление вам наших продуктов и услуг. Ваши личные данные необходимы для того, чтобы мы могли заключить с вами договор (юридическое основание: договорное).

Персонализация, совершенствование и адаптация наших продуктов и услуг для вас (правовая основа: законные интересы).

Общаюсь с тобой. Сюда могут входить ответы на ваши электронные письма или звонки (правовая основа: договорные и законные интересы).

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

С вашего разрешения и/или в случаях, когда это разрешено законом, мы также можем использовать ваши персональные данные в маркетинговых целях, которые могут включать в себя контакт с вами по электронной почте или телефону или отправку по почте информации, новостей и предложений о наших продуктах и услугах. Вам не будут отправляться незаконные маркетинговые материалы или спам. Мы всегда будем работать над тем, чтобы полностью защитить ваши права и выполнить наши обязательства в соответствии с GDPR и Положением о конфиденциальности и электронной связи (Директива ЕС) 2003 года, и у вас всегда будет возможность отказаться от этого.

6. Как долго вы будете хранить мои личные данные?
Мы не будем хранить Ваши персональные данные дольше, чем это необходимо в связи с причиной(ами), по которой(ым) они были впервые собраны. Таким образом, ваши персональные данные будут храниться в течение следующих периодов (или, если нет фиксированного периода, следующие факторы будут использованы для определения того, как долго они будут храниться):

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

если вы не являетесь нашим клиентом и у нас есть ваши личные данные для связи с вами, мы будем использовать и хранить их до тех пор, пока вы не сообщите нам, что вы больше не хотите получать от нас сообщения, или в течение периода до 24 месяцев;

7. Как и где вы храните мои личные данные?
Мы можем хранить или передавать некоторые или все Ваши персональные данные в странах, не входящих в Европейскую экономическую зону (в «ЕЭЗ» входят все страны-члены ЕС, а также Норвегия, Исландия и Лихтенштейн). Они известны как «третьи страны» и могут не иметь законов о защите данных, которые были бы столь же строгими, как в Великобритании и/или ЕЭЗ. Это означает, что мы предпримем дополнительные меры для обеспечения того, чтобы ваши личные данные обрабатывались так же безопасно и надежно, как это было бы в Великобритании и в соответствии с GDPR в том числе:

Наличие приложения для обработки данных, совместимого с GDPR, с подпроцессорами в третьих странах;
Убедиться, что такие подпроцессоры имеют адекватные процедуры безопасности.
Безопасность Ваших персональных данных является для нас существенной, и для защиты Ваших данных мы принимаем ряд важных мер, в том числе следующие:

— Шифрование ваших данных во время транспортировки;
— где это возможно, шифрование ваших данных во время их хранения;
— Ежегодные независимые обзоры наших процессов и процедур безопасности с помощью нашего сертификата ISO27001.

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

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

Иногда мы можем заключать договоры с третьими сторонами (как описано выше), которые находятся за пределами Европейской экономической зоны («ЕЭЗ» состоит из всех государств-членов ЕС, а также Норвегии, Исландии и Лихтенштейна). В случае передачи каких-либо персональных данных третьим лицам, находящимся за пределами ЕЭП, мы предпримем соответствующие меры для того, чтобы Ваши персональные данные обрабатывались так же безопасно и надежно, как это было бы в соответствии с GDPR, как описано выше в разделе 7.

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

9. Как я могу получить доступ к своим личным данным?
Если Вы хотите узнать, какие персональные данные о Вас у нас есть, Вы можете запросить у нас информацию об этих персональных данных и их копию (где хранятся такие персональные данные). Это называется «запрос на доступ к субъекту».

Все запросы на доступ к теме должны быть сделаны в письменном виде и отправлены на электронный или почтовый адрес, указанный в разделе 10.

Обычно за запрос доступа к объекту не взимается плата. Если ваш запрос является «явно необоснованным или чрезмерным» (например, если вы делаете повторные запросы), может взиматься плата для покрытия наших административных расходов на ответ.

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

10. Как я могу с вами связаться?
Чтобы связаться с нами по любому вопросу, связанному с Вашими персональными данными и защитой данных, в том числе, чтобы сделать запрос на доступ к теме, посетите страницу «Свяжитесь с нами».

11. Изменения в данном Уведомлении о конфиденциальностиМы можем время от времени изменять данное Уведомление о конфиденциальности. Это может быть необходимо, например, в случае изменения законодательства или изменения нашего бизнеса таким образом, что это повлияет на защиту персональных данных.

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

Источник

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

Стал доступен улучшенный портал Microsoft 365 Defender. Этот новый интерфейс портала Microsoft 365 Defender объединяет 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 корпорации Майкрософт имеет примерно следующий вид:

Посетите каталог 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).

В этом примере записи DMARC TXT 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).

Как 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

Такая конфигурация 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.

Источник

Для чего мы создаем…

Dmarc policy not enabled что это

Как попасть в Inbox: всё о DMARC

Что такое DMARC и зачем он нужен?

Как это работает?

Синтаксис записи

Как читать агрегированные отчёты?

Как исправить «Политика DMARC не включена»?

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

Для того чтобы начать внедрение DMARC для вашего домена:

Как исправить «Политика карантина/отклонения DMARC не включена»