Руководство по развёртыванию DMARC в Microsoft 365: от none до reject без сбоев в доставке почты

By Mirko Peters · 2026-10-21

Узнайте, как безопасно перейти к DMARC в Microsoft 365: от режима мониторинга до строгого отклонения писем, не нарушая доставку легитимной почты вашей организации.

Automatically translated with AI from the original post. Read the English original

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

Главное

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

Золотое правило порядка внедрения

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

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

Шаг первый: настройка SPF и опасность ограничений на количество запросов

Первое действие — опубликовать запись Sender Policy Framework (SPF) в корне вашего домена. Представьте её как список гостей у входа в эксклюзивный клуб. Она явно сообщает, каким серверам разрешено отправлять письма с вашим доменным именем.

При составлении начальной записи SPF для Microsoft 365 завершите её мягким отказом (~all) вместо жёсткого отказа (-all). Это указывает принимающим серверам относиться к неавторизованной почте с подозрением, а не отклонять её сразу. Такой переходный период даёт возможность выявить сервисы, которые вы могли пропустить.

Избегание ловушки десяти запросов

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

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

Шаг второй: активация DKIM в Microsoft 365

Как только список получателей опубликован, нужно обеспечить защиту сообщений от подмены в пути. DomainKeys Identified Mail (DKIM) работает как цифровая восковая печать, которая ставится на каждое исходящее сообщение. Она включает криптографическую подпись, которая охватывает тему письма, текст и видимый адрес отправителя (From).

В Microsoft 365 письма, отправленные с вашего домена по умолчанию onmicrosoft.com, подписываются автоматически. Однако ваш собственный корпоративный домен остаётся без подписи, пока вы явно не настроите DKIM в центре администрирования. Чтобы сделать это правильно, нужно создать два селектора (selector1 и selector2) в публичной DNS. Такая схема с двумя указателями позволяет Microsoft позже без простоев сменять ключи подписи.

Google и другие крупные провайдеры рекомендуют дать SPF и DKIM поработать без сбоев не менее 48 часов, прежде чем трогать DMARC. Этот период стабилизации гарантирует, что базовые проверки работают надёжно, прежде чем на сцену выйдет «судья».

Шаг третий: развёртывание DMARC в режиме мониторинга

Domain-Based Message Authentication, Reporting, and Conformance (DMARC) выступает в роли судьи. Он не проводит собственной проверки содержимого письма, а анализирует результаты проверок SPF и DKIM и определяет, совпадают ли они с видимым доменным именем в поле From.

Когда вы впервые публикуете TXT-запись DMARC по адресу _dmarc.yourdomain.com, параметр политики должен быть строго установлен в режим мониторинга: p=none. Если читать эту запись слева направо, она сообщает принимающим серверам: «Это запись DMARC. Пока никаких мер при неудачных проверках не принимать, а агрегированные отчёты отправлять на этот адрес электронной почты».

Никогда не пропускайте этот этап мониторинга. Ежедневные агрегированные отчёты (RUA) в формате XML покажут каждый сервис, легитимный или вредоносный, который отправляет почту от имени вашего домена. Направляйте эти отчёты в контролируемый общий почтовый ящик, а не во входящие отдельного сотрудника, чтобы они не потерялись во время отпусков.

Шаг четвёртый: переход от карантина к отклонению

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

• None (p=none): Сторожевая башня. Чисто наблюдательный режим, используется для аудита и сбора агрегированных отчётов.
• Quarantine (p=quarantine): Предупреждающая метка. Указывает принимающим серверам помечать подозрительные или не прошедшие проверку письма, как правило, отправляя их прямо в папку «Нежелательная почта» или «Спам» получателя.
• Reject (p=reject): Запертая дверь. Указывает получателям полностью отбрасывать неаутентифицированные или подменённые письма до того, как они попадут во входящие.

Чтобы сделать этот переход максимально плавным, используйте регуляторы процента DMARC (pct=). Можно применять карантин или отклонение к небольшой доле неуспешной почты, например сначала к 10%, затем к 25% и 50%, прежде чем перейти к полной политике. Такое постепенное наращивание предотвращает внезапный сбой бизнес-процессов, если, например, сторонний инструмент рассылки новостей вдруг окажется не настроен.

Заключение

Защита почтовой инфраструктуры организации от компрометации деловой переписки (BEC) и подмены домена требует терпения и продуманной стратегии внедрения. Настроив SPF, включив DKIM и аккуратно наращивая политику DMARC от наблюдения до строгого отклонения, вы защитите имя своей компании и гарантируете, что ваши подлинные сообщения всегда будут доставлены по назначению.

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

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

Как долго в Microsoft 365 политика DMARC должна оставаться в режиме p=none?

Google и специалисты по безопасности электронной почты рекомендуют держать политику DMARC в режиме p=none не менее одной недели. Этого срока достаточно, чтобы собрать полные агрегированные отчёты, охватывающие еженедельные и циклические потоки деловой почты.

Зачем включать DKIM до включения DMARC?

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

Отправляет ли Microsoft 365 криминалистические отчёты DMARC (forensic reports)?

Нет. Хотя Microsoft 365 будет отправлять агрегированные отчёты (RUA) на указанный вами адрес для отчётов, она не будет формировать и отправлять криминалистические (RUF) отчёты, даже если они запрошены в вашей записи DMARC.

Что произойдёт, если я опубликую две записи DMARC для своего пользовательского домена?

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