DMARC для Office 365: Пошаговая настройка и лучшие практики

Компания Microsoft поддерживает и рекомендует пользователям Microsoft 365 (также известного как Office 365 или M365) настраивать DMARC, что позволяет им единообразно применять протоколы аутентификации электронной почты на всех своих зарегистрированных доменах. В этом блоге мы рассказываем о том, как настроить DMARC для Office 365, чтобы проверять все письма Office 365, которые:

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

Что такое DMARC и почему это важно для Microsoft 365

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

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

Поддерживает ли Microsoft 365 протокол DMARC?

Одно из самых распространенных заблуждений среди администраторов заключается в том, что Microsoft 365 автоматически настраивает DMARC за вас.

Microsoft 365 действительно выполняет проверку DMARC, но только для входящих писем. Exchange Online Protection (EOP) автоматически проверяет SPF, DKIM и DMARC в сообщениях, которые получает ваша организация. Это означает, что ваши пользователи в определенной степени защищены от поддельных писем.

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

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

Необходимые условия: Настройка SPF и DKIM для Microsoft 365

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

Шаг 1: Настройка SPF для Microsoft 365

SPF (Sender Policy Framework) определяет, какие почтовые серверы имеют право отправлять электронные письма от имени вашего домена. В конфигурации Microsoft 365 к ним обычно относятся собственные почтовые серверы Microsoft и любые сторонние службы, которые вы используете.

Ручная настройка SPF (метод DNS)

Чтобы настроить SPF вручную:

1. Перейдите на сайт вашего провайдера услуг DNS-хостинга (например, GoDaddy, Cloudflare и т. д.)
2. Создайте или обновите запись TXT для вашего корневого домена

Используйте следующую стандартную запись SPF для Microsoft 365:

v=spf1 include:spf.protection.outlook.com -all

Если вы используете дополнительные сервисы (такие как Mailchimp или Salesforce), их также необходимо указать. Например:

v=spf1 include:spf.protection.outlook.com include:_spf.mailchimp.com -all

Автоматическая настройка SPF (с помощью PowerDMARC)

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

Использование инструментов SPF от PowerDMARC упрощает этот процесс. Генератор SPF автоматически создает действительную запись на основе ваших источников отправки.

Шаг 2: Включение DKIM для Microsoft 365

DKIM (DomainKeys Identified Mail) добавляет криптографическую подпись к вашим электронным письмам. Это позволяет серверам-получателям убедиться, что сообщение не было изменено и действительно отправлено с вашего домена.

В отличие от SPF, для DKIM в Microsoft 365 требуется как настройка DNS, так и активация в центре администрирования.

Ручная настройка DKIM (DNS + Центр администрирования)

Чтобы включить DKIM вручную:

1. Перейти на портал Microsoft 365 Defender
2. Перейдите в раздел «Электронная почта и совместная работа» → «Политики и правила» → «Политики защиты от угроз» → «DKIM»
3. Выберите домен

Источник изображения

Прежде чем включить DKIM, Microsoft предложит вам добавить две записи CNAME в ваш DNS.

Обычно они выглядят следующим образом:

selector1._domainkey.yourdomain.com → selector1-yourdomain-com._domainkey.yourdomain.onmicrosoft.com

selector2._domainkey.yourdomain.com → selector2-yourdomain-com._domainkey.yourdomain.onmicrosoft.com

После публикации этих настроек вернитесь на портал администрирования и нажмите «Включить» для DKIM. После активации Microsoft начнёт подписывать все исходящие письма с помощью DKIM.

Автоматическая настройка DKIM (с помощью PowerDMARC)

Настройка DKIM может вызвать затруднения, особенно у администраторов, не знакомых с записями CNAME и форматами селекторов.

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

Как настроить DMARC для Office 365?

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

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

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

К источникам отправки обычно относятся:

• Microsoft 365 (Exchange Online)
• Маркетинговые платформы (Mailchimp, HubSpot и др.)
• Системы CRM (Salesforce)
• Инструменты поддержки (Zendesk, Freshdesk)
• Внутренние приложения или серверы

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

Шаг 2: Создайте запись DMARC

Запись DMARC — это запись типа TXT, размещаемая в вашей системе DNS. Она определяет вашу политику и указывает принимающим серверам, как обрабатывать письма, не прошедшие аутентификацию. Вы можете создать уникальную запись DMARC для Office 365 для своего домена с помощью инструмента PowerDMARC для мгновенного создания записей DMARC.

Базовая запись DMARC выглядит следующим образом: v=DMARC1; p=none; rua=mailto:[email protected]; fo=1

Давайте разберемся в этом:

v=DMARC1 — Указывает версию DMARC
p=none — Режим мониторинга (без принудительного применения)
rua=mailto:[email protected] — Адрес, на который отправляются сводные отчеты
fo=1 — Включает отчетность о сбоях

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

Шаг 3: Опубликуйте запись DMARC в DNS

Как только запись будет готова, вам нужно добавить её в настройки DNS.

Используйте следующие настройки:

Тип записи: TXT
Хост/Имя: _dmarc
Значение: Ваша запись DMARC
TTL: 1 час (или значение по умолчанию)

Шаг 4: Отслеживание отчетов DMARC

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

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

Шаг 5: Постепенный переход к принудительному исполнению

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

Типичный ход событий выглядит следующим образом:

Начните с мониторинга: v=DMARC1; p=none; rua=mailto:[email protected]

↓

Переместить в карантин (подозрительные письма отправляются в папку «Спам»): v=DMARC1; p=quarantine; rua=mailto:[email protected];

↓

Наконец, принудительно применить отклонение: v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=r; aspf=r

Шаг 6: Настройка DMARC для различных типов доменов

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

Шаг 7: Проверка и обслуживание настроек DMARC в Microsoft 365

Настройка DMARC — это не разовая процедура. По мере изменения вашей почтовой экосистемы необходимо обновлять настройки. Даже после достижения значения p=reject постоянный мониторинг остается крайне важным для обеспечения доставки и безопасности.

Вам следует регулярно:

• Просмотр отчетов DMARC
• Обновляйте SPF при добавлении новых отправителей
• Убедитесь, что DKIM остается включенным и настроенным
• Мониторинг несанкционированной деятельности

Внедрение политики DMARC: почему важно постепенное введение

Один из самых распространённых ошибок при внедрении DMARC — это немедленное переход к политике отклонения. Без надлежащего контроля над потоками электронной почты применение таких мер может привести к сбоям в легитимной коммуникации.

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

Как Exchange Online обрабатывает входящие сообщения DMARC

Exchange Online Protection автоматически проверяет соответствие DMARC всех входящих сообщений, и с июля 2023 года Microsoft по умолчанию соблюдает опубликованную политику отправителя. Если запись MX домена получателя указывает непосредственно на Microsoft 365, сообщения, не прошедшие проверку DMARC в соответствии с политикой p=reject, отклоняются на шлюзе. Аналогичным образом, сообщения, не прошедшие проверку по политике p=quarantine, отправляются в карантин. Это контролируется настройкой«Соблюдать политику записи DMARC, если сообщение распознано как поддельное»в антифишинговой политике, которая включена по умолчанию.

Источник изображения

Объяснение поведения «oreject»

До июля 2023 года компания Microsoft применяла внутреннее переопределение с именем action=oreject (отклонение по источнику) к входящим сообщениям, которые не соответствовали политике p=reject отправителя. Вместо того чтобы сразу отклонять почту на шлюзе, EOP перенаправлял её в папку «Спам» получателя и помечал заголовок с помощью действия oreject.

Компания Microsoft поступила так намеренно, поскольку пересылаемая почта и сообщения из списков рассылки часто нарушают правила SPF и DKIM при прохождении через сеть. Это означает, что легитимное сообщение, прошедшее аутентификацию у первоначального отправителя, может не пройти её к моменту получения вторичным адресатом. Жесткий отказ с параметром p=reject привёл бы к отбрасыванию значительного объёма легитимной почты наряду с поддельными сообщениями. Папка «Спам» стала компромиссным решением: при необходимости получатели всё равно могли восстановить письмо, а политика отправителя технически соблюдалась.

Проблема заключалась в том, что поддельные сообщения, которые должны были отклоняться, по-прежнему попадали в почтовые ящики пользователей (в папку «Спам»), где невнимательный получатель мог их открыть. Для служб безопасности это означало, что применение DMARC никогда не казалось столь строгим, как того требовала политика.

Когда вы сегодня всё равно увидите отказ

Поскольку значение по умолчанию изменилось: теперь EOP рассматривает p=reject как действительный отказ для потоков прямых запросов MX. Однако прежнее поведение не исчезло полностью. Вы по-прежнему будете сталкиваться с oreject в следующих трех случаях:

1. В вашей антифишинговой политике отключена функция «Honor DMARC».

Чтобы устранить эту проблему, проверьте настройки в разделе «Microsoft 365 Defender» → «Электронная почта и совместная работа» → «Политики защиты от угроз» → «Защита от фишинга» → «Настройки защиты от подделки». По умолчанию этот переключатель включен, однако у клиентов, перешедших с более старых конфигураций, он может быть отключен.

2. Почта проходит через шлюз стороннего поставщика, прежде чем поступает в Microsoft 365.

Если ваш MX-запись указывает на устройство безопасности (Proofpoint, Mimecast и т. д.), которое затем перенаправляет почту в EOP, Microsoft не сможет повторно оценить DMARC, пока вы не включите «Расширенную фильтрацию для коннекторов» в портале Defender. Без этой настройки EOP доверяет решению вышестоящего шлюза и по умолчанию отклоняет почту, не прошедшую проверку.

3. Правило разрешения на уровне арендатора обходит фильтрацию.

Сообщения от отправителей, включенных в белый список, из надежных входящих шлюзов или по правилам транспорта, которым присвоен уровень вероятности спама (SCL) -1, полностью обходят проверку DMARC, и попадают в папку «Входящие» независимо от настроек политики.

Для более строгой проверки включите функцию Spoof Intelligence на портале Defender наряду с параметром «Honor DMARC». Функция Spoof Intelligence оценивает репутацию отправителя независимо от DMARC и помещает в карантин сообщения, которые выглядят как попытки подделки, даже если аутентификация технически проходит успешно.

Ужесточение мер по контролю ввозимых грузов с помощью транспортных правил

Для организаций, которым требуется гарантированный отказ в доставке писем, не прошедших проверку DMARC, наиболее надежным механизмом является правило транспорта Exchange Online.

Как создать правило:

1. Перейдите в Центр администрирования Exchange → Потоки почты → Правила и создайте новое правило.
2. Установите условие: заголовок сообщения содержит любое из этих слов. Название заголовка: Authentication-Results. Значение заголовка: dmarc=fail action=oreject.
3. Укажите действие: «Отклонить сообщение с объяснением» — введите что-нибудь вроде «Сообщение не прошло проверку DMARC и было отклонено в соответствии с политикой организации».
4. (Необязательно) Добавьте исключение для доверенных внутренних отправителей или известных легитимных пересылающих адресов, чтобы избежать ложных срабатываний.
5. На первую неделю установите для правила режим «Тестирование с подсказками по политике». Перед переходом в режим «Принудительное применение» просмотрите сообщения, по которым сработало правило, в журнале трассировки сообщений.

Дополнительную информацию можно найти в подробной документации Microsoft по правилам прохождения почты.

Когда следует применять этот подход:

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

Введение Microsoft в силу политики DMARC в мае 2025 года: что изменилось

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

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

Основные изменения, внедренные компанией Microsoft

• Обязательное использование DMARC для массовых отправителей: домены , отправляющие более 5 000 писем в день на потребительские службы Microsoft, теперь должны иметь действующую запись DMARC.
• Применимо к Outlook.com, Hotmail.com и Live.com: эти меры направлены конкретно на экосистему почтовых ящиков Microsoft для частных пользователей, а не только на корпоративных клиентов.
• Минимальное требование: DMARC с параметром p=none: допустима даже политика мониторинга, но отсутствие записи DMARC больше не допускается при масштабном развертывании.
• Больший акцент на согласованности доменов: одной аутентификации недостаточно — для успешной проверки DMARC домены SPF и DKIM должны совпадать с доменом, указанным в поле «От».
• Отказ по причине несоответствия требованиям: письма, не отвечающие требованиям, могут быть заблокированы с кодом ошибки: 550 5.7.515 Доступ запрещен, домен отправителя [SendingDomain] не соответствует требуемому уровню аутентификации.

Это изменение приводит политику Microsoft в соответствие с политикой Google и Yahoo, которые ввели аналогичные требования в феврале 2024 года, а это означает, что все три крупнейших поставщика почтовых услуг теперь требуют аутентификации от массовых отправителей.

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

Почему одного Microsoft 365 недостаточно

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

Отсутствие отчётов, понятных для человека

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

Отсутствие руководящих указаний по обеспечению соблюдения

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

Не подходит для текущего управления

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

Устранение типичных проблем с DMARC в Office 365

1. Запись DMARC не опубликована

Это самая распространённая проблема. Сообщение «No DMARC record published» означает, что в DNS вашего домена отсутствует запись DMARC TXT, поэтому получатели не имеют никаких инструкций, по которым можно было бы действовать.

Чтобы устранить эту проблему, сначала

• Проверьте это с помощью инструмента проверки DMARC.
• Если инструмент выдает ошибку «Отсутствует запись DMARC», для устранения этой проблемы необходимо опубликовать запись, начинающуюся со строки v=DMARC1; p=none; rua=mailto:[email protected], чтобы можно было начать сбор отчетов до ужесточения политики.
• Как только вы освоите настройку, можете постепенно переходить к внедрению, одновременно отслеживая отчеты.

2. Пересылка нарушает правила SPF и DKIM

Пересылка электронной почты является основной причиной отклонения вполне легитимных писем. Когда посредник (список рассылки, сервис пересылки или устройство безопасности) изменяет заголовок, включенный в подпись DKIM, подпись перестает проходить проверку, и DKIM выдает ошибку. Обычно одновременно нарушается и SPF, поскольку IP-адрес сервера пересылки отсутствует в вашей записи.

Вот три возможных рекомендации по устранению этой проблемы:

• Предпочтительно использовать подпись с поддержкой DKIM на стороне источника, поскольку DKIM лучше сохраняет свои свойства при пересылке, чем SPF, когда заголовки не переписываются
• Не следует использовать схему перезаписи отправителя (SRS) в качестве решения проблемы, поскольку она исправляет SPF, но не восстанавливает соответствие домена «From», в результате чего DMARC по-прежнему выдает ошибку
• Настройте доверенные устройства печати ARC (Authenticated Received Chain) в Microsoft Defender для всех служб пересылки, которые правомерно изменяют вашу почту. Microsoft будет учитывать результат аутентификации, полученный по цепочке ARC, вместо того, чтобы сразу отклонять сообщение.

3. Постоянная ошибка SPF из-за слишком большого количества запросов DNS

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

Это может быть вызвано двумя вероятными причинами:

• Во-первых, вы превысили ограничение в 10 запросов, установленное SPF для механизмов include, a, mx, redirect, exists и ptr. Вложенные запросы внутри записей include сторонних поставщиков также учитываются, поэтому запись, которая на первый взгляд выглядит нормально, может на самом деле содержать 12 или 13 запросов. Когда это ограничение превышается, каждый получатель возвращает ошибку permerror, и согласованность DMARC на основе SPF сразу же нарушается для всего домена.

Что делать: для начала проверьте свои записи с помощью инструмента проверки SPF и удалите поставщиков, услугами которых вы больше не пользуетесь. Однако это лишь временное решение. Долгосрочным решением станет использование хостингового решения SPF, такого как PowerSPF, с оптимизацией макросов SPF для динамического управления запросами SPF.

• Второй причиной, если вы сталкиваетесь с ошибкой «temperror» именно при подключении к ресурсам Microsoft, могут быть таймауты DNS. Если таймауты возникают при подключении к конкретному ресурсу, следует исключить этого поставщика из списка или удалить его из записи.

4. Политики «p=reject» не соблюдаются

С июля 2023 года Microsoft по умолчанию применяет политику «p=reject», то есть сообщение с ошибкой должно быть сразу отклонено. Если этого не происходит, то причиной может быть одно из следующих четырех обстоятельств:

• В вашей антифишинговой политике может быть отключена поддержка DMARC: убедитесь, что параметр «Соблюдать политику записи DMARC, если сообщение распознано как поддельное» включен, а для параметра p=reject выбрано действие «Отклонить» (а не «Поместить в карантин»).
• Перед Microsoft 365 установлен шлюз стороннего производителя: если ваш MX-сервер указывает на шлюз безопасности стороннего производителя, Microsoft не будет применять DMARC, пока вы не включите расширенную фильтрацию для коннекторов.
• Композитная аутентификация переопределила результат: Microsoft накладывает сигналы репутации поверх DMARC. Сообщение может не пройти проверку DMARC, но все равно быть доставленным, если compauth=pass
  (Подробнее об этом можно узнать в учебном сообществе Microsoft).
• Правило разрешения арендатора обходит фильтрацию: отправитель из списка разрешенных, доверенный входящий коннектор или правило, присваивающее уровень вероятности спама SCL-1, полностью обходят принудительное применение DMARC.

Внедрение DMARC в Microsoft 365

DMARC в Microsoft 365 представляет собой проблему с двумя аспектами. Exchange Online Protection автоматически выполняет проверку входящих писем, однако защита исходящих писем полностью лежит на вас. Изменения в правилах применения, вступающие в силу в мае 2025 года, делают эту задачу крайне актуальной для всех, кто отправляет большие объемы писем.

Самый безопасный путь — это медленный путь: сначала установите параметр p=none, в течение двух–четырех недель следите за отчётами, устраняйте проблемы с отправителями, которые выявятся, а затем перейдите к параметру p=quarantine и, в конечном итоге, к p=reject. Пропуск этапов — это самая распространённая причина сбоев в работе легитимной почты во время внедрения.

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

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

Часто задаваемые вопросы

Настраивает ли Microsoft 365 протокол DMARC автоматически?

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

Требует ли Microsoft использование DMARC?

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

Что такое ошибка 550 5.7.515?

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

Почему письма по-прежнему доставляются с пометкой «p=reject»?

Компания Microsoft традиционно применяла внутреннюю настройку под названием «oreject» (отклонение по источнику), которая перенаправляет сообщения, не прошедшие проверку DMARC, в папку «Спам», вместо того чтобы сразу отклонять их на шлюзе. Это было сделано для защиты легитимных отправителей от случайной потери сообщений, однако при этом поддельные сообщения остаются видимыми для получателей.

Две вещи, о которых стоит знать:

1) С момента вступления в силу изменений в мае 2025 года компания Microsoft переходит к более строгому подходу, предусматривающему полный отказ в обслуживании отправителей с большим объемом рассылок.

2) Если вы хотите обеспечить гарантированный отказ от доставки внутри своего собственного арендатора Microsoft 365, создайте правило транспорта Exchange, которое обеспечивает жесткий отказ от доставки сообщений.

Что выбрать: «Карантин» или «Отклонить»?

Начните с режима мониторинга (p=none), чтобы отслеживать источники отправки и каналы электронной почты, затем перейдите к режиму карантина и прибегайте к отклонению только после того, как убедитесь, что все легитимные источники настроены правильно.

• О сайте
• Последние сообщения

Юнес Тарада

Эксперт по безопасности доменов и электронной почты в PowerDMARC

Юнес - руководитель группы операций в PowerDMARC, обладающий экспертными знаниями в области аутентификации и безопасности электронной почты. Юнес имеет сертификат Microsoft Azure Administrator Associate, а также сертификаты CompTIA A+ и многие другие.

Последние сообщения Юнеса Тарады (см. все)

• Объяснение DMARCbis — что меняется и как подготовиться - 16 апреля 2026 г.
• Неверный формат серийного номера SOA: причины и способы устранения - 13 апреля 2026 г.
• Как отправлять защищенные письма в Gmail: пошаговое руководство - 7 апреля 2026 г.