Как правильно настроить DMARC в Office 365

Начиная с февраля 2024 года, требования Gmail к отправке массовых рассылок предусматривают обязательное наличие опубликованной записи DMARC для каждого домена, через который осуществляется отправка. 5,000 электронные письма ежедневно для пользователей Gmail. Yahoo применяет то же правило в своих сервисах. лучшие практики отправителя, По состоянию на Май 2025Компания Microsoft начала отклонять не соответствующие требованиям письма от отправителей, отправляющих большое количество сообщений в почтовые ящики Outlook, Hotmail и Live.

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

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

Предварительные условия перед настройкой DMARC в Office 365

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

Перед публикацией записи DMARC необходимо подтвердить выполнение всех четырех указанных ниже предварительных условий:

• Утвержден и пройдена проверка SPF: Для клиентов Microsoft 365 запись SPF должна включать include:spf.protection.outlook.com, а также любые дополнительные сторонние отправители (SendGrid, Mailchimp, HubSpot и т. д.), которые отправляют сообщения от имени вашего домена.
• Подписание DKIM включено для каждого пользовательского домена: Microsoft 365 не включает DKIM для пользовательских доменов автоматически. Откройте портал Microsoft Defender, перейдите на страницу DKIM в разделе «Электронная почта и совместная работа» → «Политики и правила» → «Политики угроз» и убедитесь, что подписание включено для пользовательского домена.
• Доступ глобального администратора или администратора безопасности. Для проверки в портале Defender обратитесь к клиенту Microsoft 365.
• Доступ к DNS для пользовательского домена Чтобы опубликовать запись DMARC TXT по адресу _dmarc.yourdomain.com в панели управления вашего DNS-провайдера.

Как настроить DMARC в Office 365: пошаговая инструкция

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

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

Шаг 1: Убедитесь, что SPF и DKIM работают.

Отправьте тестовое письмо со своего собственного домена на внешний адрес Gmail или Yahoo. Откройте письмо и просмотрите полный заголовок сообщения (в Gmail: меню с тремя точками → «Показать оригинал»).

В заголовке Authentication-Results подтвердите:

• spf=pass — SPF авторизован и проходит проверку
• dkim=pass — Подпись DKIM корректна, и подпись проверена.

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

Шаг 2: Определите начальную политику DMARC.

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

Переход непосредственно к p=quarantine или p=reject — это самая распространенная причина потери легитимных писем во время внедрения DMARC. Если платформа отправки сторонних отправителей еще не согласована, строгая политика немедленно поместит в карантин или отклонит реальные письма от этого источника. Этап p=none существует специально для предотвращения этого.

Шаг 3: Создание записи DMARC

Базовая запись DMARC для нового развертывания выглядит следующим образом:

v = DMARC1; p = нет; rua = mailto:[электронная почта защищена]; процент=100;

Вот что означает каждый тег:

• v = DMARC1 — версия протокола. Обязателен в качестве первого тега в каждой записи DMARC.
• не р = нет — политика, применяемая к сообщениям, не прошедшим проверку соответствия DMARC. Начните с отсутствия проверки, затем переходите к карантину и отклонению по мере стабилизации соответствия.
• rua=mailto:address — почтовый ящик, куда отправляются сводные отчеты. Используйте выделенный почтовый ящик, например, такой: [электронная почта защищена]или же направлять отчеты стороннему анализатору DMARC, если вам удобнее просматривать их в виде панели мониторинга.
• процент = 100 — Процент сообщений, к которым применяется политика, но которые не проходят проверку. Установите это значение равным 100 с самого начала. Постепенное внедрение политики в зависимости от процента ошибок редко требуется в современных системах DMARC и добавляет ненужную сложность.

Полный справочник по тегам, включая необязательные теги, такие как ruf (отчеты о расследованиях), sp (политика поддоменов), adkim и aspf, см. в разделе DMARC.orgОфициальная протокольная документация.

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

Войдите в DNS-сервер вашего домена. Создайте новую TXT-запись со следующими значениями:

• Имя хоста: _dmarc (некоторые провайдеры запрашивают _dmarc.yourdomain.com; введите точно то, что требует интерфейс DNS)
• Ценность / Содержание: Полная запись DMARC, созданная на шаге 3, в точности так, как она написана.
• Срок жизни: 3600 (один час) — это стандартное значение; более низкие значения распространяются быстрее во время тестирования.

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

Шаг 5: Убедитесь, что запись DMARC активна.

После распространения записи проверьте её двумя способами:

• Поиск DNS: Воспользуйтесь инструментом проверки DMARC в MXToolbox, введите свой домен и убедитесь, что запись корректно обработана и действительна. Если проверка не удалась или выдала ошибку, проверьте форматирование вашей DNS-записи, так как обычно причиной является отсутствие точки с запятой или неправильное имя хоста.
• Проверка заголовка аутентификации: Отправьте еще одно тестовое письмо со своего пользовательского домена на Gmail, Yahoo или внешний адрес Outlook. Откройте заголовки и убедитесь, что в разделе Authentication-Results теперь отображается dmarc=pass для отправляющего домена.

Сводные отчеты DMARC начинают поступать в почтовый ящик rua= в течение 24–72 часов после активации записи. Внимательно изучите первую партию отчетов, прежде чем рассматривать возможность перехода к более строгим правилам.

Понимание параметров политики DMARC: Нет, Карантин и Отклонить

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

Режим мониторинга: p=нет

v = DMARC1; p = нет; rua = mailto:[электронная почта защищена]; процент=100;

При p=none принимающие почтовые серверы собирают результаты DMARC и отправляют их обратно на ваш адрес rua=, но сообщения, доставленные с ошибкой, всё равно доставляются в обычном режиме. Ничего не помещается в карантин и не отклоняется.

Оставайтесь в режиме p=none как минимум 2–4 недели. Используйте это время, чтобы изучить сводные отчеты и убедиться, что каждый легитимный источник отправки, такой как Microsoft 365, маркетинговые платформы, отправители транзакционных сообщений и CRM-системы, проходит проверку соответствия DMARC. Любой источник, демонстрирующий сбои, должен быть исправлен до ужесточения политики.

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

Мягкое обеспечение соблюдения: p=карантин

v=DMARC1; р=карантин; rua=mailto:[электронная почта защищена]; процент=100;

При использовании режима карантина (p=quarantine) почтовые серверы перенаправляют сообщения, не прошедшие проверку, в папку «Спам» или «Нежелательная почта», а не во входящие. Легитимные, но не соответствующие установленным правилам, письма всё равно доходят, просто попадают в некорректное место, где получатели с меньшей вероятностью их увидят.

Этот этап разработки политики является полезным промежуточным контрольным пунктом. Он предусматривает последствия для неправильно доставленных писем без жестких отказов, которые возникают при использовании параметра p=reject. Оставайтесь на этом этапе еще 2–4 недели и внимательно отслеживайте отчеты на предмет неправильной доставки законных писем.

Переходите к параметру p=reject только тогда, когда отчеты DMARC подтвердят согласованность во всех источниках и отсутствие помещенных в карантин легитимных писем.

Полное применение: p=отклонить

v=DMARC1; р=отклонить; руа = почта:[электронная почта защищена]; процент=100;

При значении p=reject принимающие почтовые серверы отклоняют сообщения, которые полностью не соответствуют требованиям DMARC. Несоответствующие сообщения возвращаются отправителю; они вообще не доходят до получателя.

Это цель каждой реализации DMARC. Полное применение p=reject обеспечивает полную защиту от подмены домена и соответствует требованиям Gmail, Yahoo и Microsoft для отправителей с большим объемом сообщений. Это также защищает ваши репутация домена и IP-адреса предотвращая использование вашего доменного имени неавторизованными отправителями для доставки почты.

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

Распространенные ошибки настройки DMARC в Office 365 и способы их устранения

В большинстве случаев ошибки DMARC в средах Microsoft 365 связаны с проблемами выравнивания, а не с ошибками протокола. Это означает, что запись технически действительна, но отправляемое электронное письмо не соответствует домену подписи DKIM или IP-адресам, авторизованным SPF.

Отчеты DMARC пусты.

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

Fix: Убедитесь, что почтовый ящик rua= существует, принимает внешние письма и не фильтруется агрессивным правилом спама. Отправьте несколько тестовых писем с этого домена на адреса Gmail и Yahoo; эти провайдеры обычно генерируют отчеты в течение 24–48 часов, если DMARC настроен правильно.

Подлинные электронные письма помещаются в карантин или отклоняются.

Клинический диагноз: Сторонняя платформа для отправки писем не соответствует требованиям. Наиболее распространенная причина — это маркетинговый инструмент, CRM-система или поставщик транзакционных электронных писем, который не добавлен в SPF или не настроен на подписание с помощью DKIM для пользовательского домена.

Fix: Просмотрите сводные отчеты DMARC, чтобы определить, какой источник не работает. Либо добавьте источник в свою запись SPF (include:thirdparty.com), либо настройте подписание DKIM для этого источника через параметры платформы, либо временно вернитесь к значению p=none, пока не будет исправлена ​​ошибка согласования. Никогда не оставляйте политику в значении p=reject, если известные источники не работают.

Сбои выравнивания DMARC после пересылки.

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

Fix: Убедитесь, что DKIM корректно подписывает сообщение для отправителя. Почта, подписанная с помощью DKIM, проходит проверку DMARC, даже если SPF не проходит из-за пересылки. Если DKIM также не проходит проверку после пересылки, значит, система пересылки изменяет содержимое сообщения и нарушает подпись DKIM. В такой ситуации обычно требуется поддержка ARC (Authenticated Received Chain) со стороны сервера пересылки для решения проблемы.

Ошибки формата записей DMARC

Клинический диагноз: Опечатки в записи DMARC TXT могут привести к аннулированию всей политики. К распространенным проблемам относятся отсутствие префикса v=DMARC1, отсутствие точек с запятой между тегами или некорректное разделение записи на несколько DNS-записей.

Fix: Проверьте опубликованную запись с помощью валидатора DMARC в MXToolbox и убедитесь, что она обработана и действительна. Убедитесь, что запись существует как единая TXT-запись в каталоге _dmarc.yourdomain.com, а не разделена на две записи, и что каждый тег разделен точкой с запятой.

Правильно настроенная система DMARC защищает ваш домен.

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

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

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

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