Политика DMARC: что это и как её прописать правильно

Содержание

• Что такое DMARC и зачем она нужна
• Как работает DMARC
• Политики DMARC: что значит none, quarantine, reject
• Как настроить DMARC
• Примеры записей DMARC для разных случаев
• Подробный синтаксис записи DMARC
• Отчёты DMARC: что в них и как с ними работать
• Пример успешного применения DMARC

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

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

• кража учетных данных через поддельные формы авторизации

• получение доступа к корпоративным системам
• компрометация персональных данных клиентов (за их утечку для юрлиц установлены миллионные штрафы!)
• BEC-атаки (Business Email Compromise): рассылка поддельных счетов, взлом учётных записей и пр.

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

Далее получатели письма либо попадаются на удочку и теряют деньги, либо перестают доверять вашим настоящим письмам. В любом случае страдает репутация компании.

Частые последствия отсутствия защиты от подделки писем для бизнеса:

• потеря средств компании и клиентов
• репутационные потери: подрыв доверия клиентов к бренду, ухудшение имиджа компании

• блокировка доменов и IP-адресов после массовых рассылок спама
• снижение доставляемости настоящих писем из-за испорченной репутации
• финансовые потери из-за невозможности проводить email-коммуникации
• юридические риски при компрометации данных клиентов

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

Злоумышленники могут с лёгкостью подделать адрес отправителя и направить письмо с якобы корпоративного email, чтобы выдать себя за компанию. Отсутствие встроенной защиты в протоколе SMTP создаёт лазейку для злоумышленников, которые могут использовать домен в своих мошеннических схемах.

Именно поэтому в борьбе с подменой адресов отправителей необходимы современные  системы защиты, такие как DMARC.

DMARC (Domain-based Message Authentication, Reporting and Compliance — «аутентификация, отчётность и соответствие на основе домена») — специальный протокол безопасности, интегрированный с двумя ключевыми технологиями верификации писем.

В основе работы DMARC лежат два важных компонента:

• SPF (Sender Policy Framework) — система проверки подлинности отправителя
• DKIM (DomainKeys Identified Mail) — механизм цифровой подписи сообщений

Эти инструменты в комплексе позволяют не только верифицировать легитимность отправителя, но и устанавливать чёткие правила обработки писем с сомнительной аутентичностью.

Система предлагает три варианта реагирования на сомнительные сообщения:

1. Мониторинг — интеллектуальный механизм, который осуществляет постоянный анализ всех входящих электронных сообщений.
2. Карантин — эффективный механизм фильтрации, который автоматически направляет письма с признаками подозрительности в специальный раздел почтового ящика «Спам».
3. Блокировка — обеспечение максимальной безопасности путём автоматического отсечения всех писем, вызывающих подозрения в подлинности.

Представьте, что вы можете сказать почтовым сервисам: «Если кто-то пытается выдавать себя за меня и рассылает письма от моего имени без моего ведома — немедленно остановите их!». 

Грамотная реализация протокола DMARC становится надёжным щитом для бизнеса, который:

• Автоматически блокирует подозрительные сообщения.
• Эффективно блокирует любые попытки злоумышленников использовать название вашей организации в преступных целях.
• Сохраняет безупречную репутацию бренда и домена.
• Защищает от фишинговых атак и несанкционированного доступа.

• Предоставляет отчёты о подозрительной активности.
• Обеспечивает соответствие современным стандартам безопасности.

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

Как работает DMARC

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

Система:

1. Проводит комплексную верификацию сообщений
2. Сверяет соответствие установленным критериям
3. Применяет заданные правила обработки

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

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

• SPF-протокол следит за тем, чтобы только авторизованные серверы имели право рассылать сообщения от имени вашего домена

Создаётся список доверенных отправителей для домена. Он хранится в системе DNS и содержит перечень серверов, которым официально разрешено рассылать письма от вашего имени. 

При получении письма почтовый сервер сверяет IP-адрес отправителя. Затем система автоматически проверяет, входит ли этот адрес в список разрешённых. При совпадении с указанным списком — проверка SPF считается успешной.

Настройка SPF — это первый шаг к созданию комплексной системы безопасности электронной почты.

• Технология DKIM ставит на каждое письмо особую цифровую метку, гарантирующую его подлинность и целостность

DKIM обеспечивает криптографическую защиту: для каждого отправляемого письма автоматически генерируется уникальная цифровая подпись. 

Для этого используются два взаимосвязанных ключа: закрытый ключ для создания подписи и открытый ключ для верификации (открытый ключ безопасно хранится в специальной записи DNS домена — это называется DNS-интеграция).

Как это работает на практике:

1. Отправитель формирует и подписывает письмо
2. Сервер добавляет специальную цифровую метку
3. Получатель проверяет подлинность подписи
4. Система подтверждает, что:
   • Письмо действительно отправлено с указанного домена
   • Содержание не было изменено при пересылке
   • Отправитель является законным владельцем домена

Важное уточнение: SPF-протокол анализирует адрес в техническом заголовке Return-Path, DKIM-подпись верифицирует домен отправителя.

Поле «От» может содержать поддельный адрес, видимый пользователю. Именно здесь помогает DMARC и его концепция согласованности (alignment). DMARC требует, чтобы домен, указанный в видимом поле «От», соответствовал тому домену, который успешно прошёл проверку как SPF, так и DKIM. Если есть несоответствие — письмо автоматически попадает в категорию подозрительных.

DMARC анализирует результаты проверок SPF и DKIM и выносит окончательное решение о доверии к письму. DMARC не заменяет SPF и DKIM, а дополняет их. Для работы DMARC нужно сначала настроить SPF и DKIM. Только потом добавлять политику DMARC.

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

Пример: получателю пришло письмо от якобы менеджера компании с адресом. SPF проверил домен в заголовке Return-Path — всё в порядке. Но видимый адрес и проверенный домен не совпадают.

В строгом режиме работы DMARC такое письмо будет автоматически отклонено. А в более мягком режиме (relaxed) оно всё равно будет помечено как подозрительное, но может быть пропущено, если  является частью основной доменной структуры компании.

Механизм защиты DMARC можно описать так:

1. Первичная проверка — письмо поступает на почтовый сервер.
2. Аутентификация сообщений — проводится комплексная проверка через SPF и DKIM.
3. Верификация доменов — система анализирует совпадение доменных адресов.
4. Политика безопасности — сервер запрашивает DMARC-правила из DNS отправителя.
5. Финальное решение — определяется судьба письма:

• Доставка в почтовый ящик
• Перемещение в папку спама
• Отклонение сообщения

Отчётность системы предоставляет владельцу домена детальную информацию о результатах мониторинга безопасности.

Политики DMARC: что значит none, quarantine, reject

DMARC предоставляет три уровня защиты для управления подозрительными письмами. Каждый режим предназначен для определенного этапа внедрения системы безопасности.

1. Политика мониторинга (p=none) 

Это базовый режим для начинающих. Возможности:

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

Преимущества режима:

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

Когда применять:

• Идеален для начального этапа внедрения DMARC
• Позволяет оценить эффективность системы
• Помогает выявить проблемные зоны
• Дает время на корректировку настроек

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

Переходить к более строгим режимам (quarantine и reject) следует только после тщательного анализа собранных данных и устранения всех выявленных проблем.

2. Политика p=quarantine 

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

Переходить на quarantine лучше после анализа отчетов с политикой none. Убедитесь, что все легитимные источники почты правильно настроили SPF и DKIM. Иначе ваши собственные письма будут попадать в спам.

3. Политика p=reject 

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

Используйте reject только когда уверены в настройках. Проверьте, что все сервисы рассылки, CRM-системы и другие источники почты корректно настроены. Одна ошибка — и важные письма перестанут доходить.

Правильная последовательность внедрения:

1. Мониторинг (none) — 2-4 недели. Изучаете отчёты, выявляете все источники почты.
2. Тестирование (quarantine) — 2-4 недели. Смотрите, какие письма попадают в спам, корректируете настройки.
3. Защита (reject) — финальная политика для максимальной безопасности.

Есть ещё один важный параметр — pct (процент). Он позволяет применять политику только к части писем. Например, pct=30 означает, что политика действует на 30% сообщений. Остальные 70% обрабатываются, как при политике none.

Это обеспечивает плавный переход. Можно установить p=quarantine; pct=10 и постепенно увеличивать процент, наблюдая за результатами.

Для поддоменов можно задать отдельную политику через параметр sp. Например, основной домен использует p=none, а поддомены — sp=reject. Это удобно, когда с поддоменов почта не отправляется.

Как настроить DMARC

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

1. Подготовка: проверка SPF и DKIM

Без SPF и DKIM политика DMARC бесполезна. Сначала настройте эти технологии и убедитесь, что они работают минимум 48 часов.

Проверьте SPF-запись в DNS:

v=spf1 include:_spf.google.com ~all

Эта запись разрешает серверам Google отправлять почту с вашего домена. Если используете другие сервисы (Mail.ru, Yandex, SendGrid) — добавьте их тоже.

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

selector._domainkey.yourdomain.com TXT “v=DKIM1; k=rsa; p=MIGfMA0…”

Протестируйте отправку писем. Отправьте себе email и проверьте заголовки — там должны быть записи о прохождении SPF и DKIM проверок.

2. Формирование записи DMARC

Начните с простейшей записи для мониторинга:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Где:

• v=DMARC1 — версия протокола (обязательно)
• p=none — политика мониторинга без блокировки
• rua=mailto:dmarc@yourdomain.com — адрес для получения отчетов

Создайте почтовый ящик для отчётов заранее. Туда будут приходить XML-файлы со статистикой. Если не хотите разбираться с XML — используйте сервисы вроде DMARCLY или PowerDMARC.

3. Добавление записи в DNS

Интеграция DMARC осуществляется через простую настройку DNS-записей вашего домена.

Как добавить:

1. Доступ к DNS-управлению: войдите в панель управления вашего DNS-провайдера и найдите раздел управления DNS-записями.
2. Создание TXT-записи:

• Тип записи: TXT
• Имя хоста: _dmarc (или _dmarc.yourdomain.com)
• Значение записи: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com 
• TTL: используйте значение по умолчанию

Важные параметры настройки:

• Версия протокола (v=DMARC1) — текущая актуальная версия.
• Политика (p=none) — начальный режим мониторинга.
• Адрес отчетов (rua) — email для получения агрегированной статистики.

Важно:

• Сохраняйте настройки TTL стандартными для стабильной работы.
• Проверьте корректность введенных данных перед сохранением.
• Дождитесь обновления DNS-записей (обычно 24-48 часов).

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

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

После добавления запись начнет работать в течение нескольких часов. Максимум — 24 часа из-за кеширования DNS.

Проверить корректность записи можно онлайн-инструментами: dmarcian.com, mxtoolbox.com , Google Admin Toolbox.

4. Мониторинг отчётов и корректировка политики

Через сутки после добавления записи начнут приходить первые отчеты[17][18]. Обычно это XML-файлы с данными за день.

В отчётах можно увидеть:

• Какие IP-адреса отправляют почту с вашего домена
• Проходят ли письма проверки SPF и DKIM
• Есть ли неизвестные источники отправки

Проблемы, которые могут возникать:

• Письма из CRM или системы уведомлений не проходят SPF
• Пересылка писем через корпоративный Exchange ломает DKIM
• Маркетинговые рассылки отправляются с неправильными настройками

Что делать: исправьте все проблемы. Добавьте недостающие сервисы в SPF-запись. Настройте DKIM для всех источников почты.

Через 2-4 недели мониторинга переходите к политике quarantine:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com

Следите за отчетами еще 2-4 недели. Если проблем нет — переходите к финальной политике reject.

Примеры записей DMARC для разных случаев

Вот готовые конфигурации DMARC для разных сценариев. Их можно скопировать и адаптировать под свои потребности.

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

v=DMARC1; p=none;

При такой конфигурации:

• Система не осуществляет никаких активных действий
• Отчёты о работе не формируются
• Происходит только базовый мониторинг

Такая запись идеально подходит для:

• Первоначальной проверки работоспособности системы
• Тестирования базовых функций
• Оценки общей картины без вмешательства в почтовые процессы.

Мониторинг с отчетами. В этом варианте добавлены агрегированные отчеты. Используйте эту запись на старте внедрения.

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

Заменяйте yourdomain.com на свой домен и создайте почтовый ящик для отчетов.

Частичная защита. Это комбинированный вариант обработки писем.

v=DMARC1; p=quarantine; pct=30; rua=mailto:dmarc-reports@yourdomain.com

30% подозрительных писем попадает в спам, остальные доставляются как обычно. Параметр pct позволяет плавно переходить к строгой политике. Начните с 10-20%, а затем постепенно увеличивайте.

Строгая защита. Отклоняет все письма, не прошедшие проверку.

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

Используйте только после тщательного тестирования других политик. Убедитесь, что все легитимные источники почты настроены правильно.

Максимальные настройки защиты. Это полный уровень защиты с детальным мониторингом.

v=DMARC1; p=reject; rua=mailto:aggregate@yourdomain.com; ruf=mailto:forensic@yourdomain.com; pct=100; adkim=s; aspf=s

Особенности данной конфигурации:

• Строгий контроль через параметры adkim=s и aspf=s
• Точное совпадение доменных имен без допуска поддоменов
• Полная проверка 100% писем (pct=100)
• Автоматическое отклонение подозрительных сообщений
• Двухуровневая отчетность через агрегированные и форензик-отчеты.

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

v=DMARC1; p=none; sp=reject; rua=mailto:dmarc-reports@yourdomain.com

Преимущества конфигурации:

• С поддоменов не ведется рассылка
• Существует риск злоупотребления поддоменами
• Нужна дополнительная защита от мошенников

Конфигурация для корпоративного сегмента. Это оптимальный вариант для крупных компаний с развитой инфраструктурой, организаций с активным email-трафиком и требующих детального контроля безопасности.

v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc-rua@yourdomain.com; ruf=mailto:dmarc-ruf@yourdomain.com; fo=1; ri=3600

Особенности:

• Умеренная защита с политикой карантина (p=quarantine)
• Поэтапный подход — проверка только 50% писем (pct=50)
• Двухуровневая отчетность: агрегированные отчеты (rua) и форензик-отчеты (ruf)
• Детальный мониторинг через fo=1 — уведомления о каждом сбое
• Частая отчётность — обновления каждые 60 минут (ri=3600)

Этот вариант позволяет:

• Плавно внедрить систему защиты
• Отслеживать потенциальные угрозы в режиме реального времени
• Собирать детальную статистику для оптимизации безопасности
• Обеспечить баланс между защитой и производительностью

Настройка для сервиса рассылок. Подходит для компаний, которые используют сторонние сервисы рассылок.

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; pct=100; adkim=r; aspf=r

Мягкий режим выравнивания (adkim=r; aspf=r) позволяет отправлять почту с поддоменов. 

При выборе конфигурации важно учитывать:

Сложность почтовой инфраструктуры

Количество источников отправки почты

Критичность надежной доставки

Ресурсы на мониторинг отчетов

Помните: лучше всегда начинать с мониторинга (p=none) и постепенно ужесточать политику.

Подробный синтаксис записи DMARC

Структура DMARC представляет собой набор параметров в формате ключ=значение, разделённых точкой с запятой.

Обязательные компоненты для функционирования системы:

1. Версия протокола (v)

Ключевой параметр — всегда указывается первым

Фиксированное значение: DMARC1

Пример записи: v=DMARC1

Важно: без этого тега система не распознает запись как DMARC

2. Основная политика (p)

Определяет действия с письмами, не прошедшими проверку

Доступные опции:

• none — режим мониторинга без действий
• quarantine — отправка в спам/карантин
• reject — полное отклонение сообщений

Пример: p=reject

Дополнительные параметры для расширенной настройки:

• Агрегатная отчетность (rua)

Назначение: сбор статистических отчетов

Формат указания: mailto:email@domain.com

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

Пример: rua=mailto:dmarc-reports@example.com

• ruf (форензик-отчеты)

Назначение: содержат полную информацию о проблемных письмах

Формат указания: mailto:email@domain.com

Пример настройки: ruf=mailto:dmarc-forensic@example.com 

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

• pct (процент охвата писем)

Назначение: определяет долю писем под действием политики.

Диапазон значений: от 0 до 100%.

Стандартное значение: 100% (все сообщения)

Пример использования: pct=25 (политика применяется к 25% писем).

Особенности: идеально для постепенного внедрения строгих правил.

• sp (политика для поддоменов)

Назначение:  устанавливает правила безопасности для поддоменов.

Доступные опции: none, quarantine, reject.

При отсутствии настройки применяется основная политика.

Пример: sp=reject

Особенности: обеспечивает усиленную защиту поддоменов.

• aspf (режим выравнивания SPF)

Особенности: определяет правила сопоставления SPF-записей, важный элемент для корректной работы системы верификации.

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

Пример: aspf=s 

• adkim (режим выравнивания DKIM)

Точное соответствие домена в подписи DKIM и поля «От». Система предлагает два уровня контроля соответствия доменных имен:

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

Строгий режим (s). Обеспечивает максимальную точность проверки, требует полного совпадения доменов, даёт повышенный уровень защиты.

Пример настройки: adkim=s

В мягком режиме система допускает: использование поддоменов, определённую гибкость в сопоставлении, более простой переход к защите.

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

• fo (условия формирования отчётов)

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

0 — отчёт, если и SPF, и DKIM провалились

1 — отчёт, если провалился SPF или DKIM

d — отчёт при сбое DKIM

s — отчёт при сбое SPF

По умолчанию: 0

Пример: fo=1

• rf (формат отчётов)

afrf — единственный поддерживаемый формат

По умолчанию: afrf

Пример: rf=afrf

Этот параметр встречается нечасто, что обусловлено отсутствием альтернативных вариантов.

• ri (интервал отчётов)

Значения: количество секунд

По умолчанию: 86400 (24 часа)

Пример: ri=3600 (отчеты каждый час)

Некоторые провайдеры игнорируют этот параметр и отправляют отчеты по своему расписанию.

Пример полной записи со всеми тегами:

v=DMARC1; p=quarantine; rua=mailto:rua@example.com; ruf=mailto:ruf@example.com; pct=50; sp=reject; aspf=s; adkim=r; fo=1; rf=afrf; ri=3600

Важно: порядок тегов не важен, кроме v=DMARC1, который должен быть первым. Пробелы после точки с запятой опциональны, но улучшают читаемость.

Отчёты DMARC: что в них и как с ними работать

DMARC генерирует два типа отчётов — агрегированные (RUA) и форензик (RUF). Они помогают понять, кто отправляет почту с вашего домена, и какие письма блокируются.

Подробно о видах отчётов

Агрегированные отчеты (RUA). Приходят ежедневно в формате XML. Содержат обобщённую статистику за сутки:

• Общее количество писем с домена
• Результаты проверок SPF и DKIM
• IP-адреса отправителей
• Процент прохождения DMARC

Пример структуры отчета:

<record>

  <row>

<source_ip>203.0.113.1</source_ip>

<count>142</count>

<policy_evaluated>

   <disposition>none</disposition>

   <dkim>pass</dkim>

   <spf>pass</spf>

</policy_evaluated>

  </row>

</record>

Расшифровка: с IP-адреса 203.0.113.1 отправлено 142 письма, все прошли проверки SPF и DKIM, применена политика none.

Форензик-отчеты (RUF). Отправляются немедленно при сбое аутентификации. Содержат детальную информацию о конкретном письме:

• Полные заголовки письма
• IP-адрес и домен отправителя
• Причину сбоя SPF/DKIM
• Иногда — тело письма

Форензик-отчёты приходят гораздо реже. Многие почтовые провайдеры их вообще не отправляют из соображений приватности.

Как читать отчеты

XML-файлы сложно анализировать вручную. Большинство компаний используют специальные сервисы:

• DMARCLY
• PowerDMARC
• Postmark DMARC Digests
• Valimail

Эти платформы преобразуют XML в понятные графики и таблицы.

При самостоятельной работе с аналитикой особое внимание уделите следующим аспектам:

1. Подозрительная активность IP:

• Обнаружение неизвестных адресов отправителей
• Потенциальные источники спам-рассылок
• Признаки фишинговых атак
• Неавторизованные попытки отправки писем

2. Проблемы аутентификации:

• Сбои в работе SPF-протокола
• Нарушения в системе DKIM-подписей
• Ошибки настройки механизмов верификации
• Некорректная работа систем проверки

3. Критические сигналы:

• Массовое количество неудачных проверок
• Аномально высокий процент отказов
• Признаки целенаправленных атак
• Попытки компрометации домена

Сложности при работе с DMARC-отчётами и рекомендации

Типичные проблемы с отчётами и их решения:

1. Проблемы с корпоративной CRM

Симптом: письма от CRM не проходят SPF-проверку

Причина: отсутствие IP-адреса CRM в SPF-записи

Решение: добавьте IP-адрес вашего CRM-сервиса в SPF-запись домена

2. Сложности с пересылкой писем

Проблема: при пересылке нарушается DKIM-подпись

Причина: изменение заголовков письма при пересылке

Решение: внедрите SRS (Sender Rewriting Scheme) для корректной обработки пересланных сообщений

3. Ошибки в маркетинговых рассылках

Симптом: письма отправляются с некорректного домена

Причина: неправильные настройки в сервисе email-рассылок

Решение: проверьте и скорректируйте настройки домена в вашем сервисе массовых рассылок

Рекомендации:

1. Регулярно проверяйте настройки всех используемых сервисов
2. Ведите актуальный список разрешённых IP-адресов
3. Отслеживайте изменения в работе почтовых систем
4. Проводите аудит настроек безопасности

Мониторинг атак

Отчеты помогают засечь атаки на ранней стадии. Признаки атаки:

• Резкий рост количества писем с вашего домена
• Множество новых IP-адресов в отчетах
• Высокий процент сбоев DMARC

При обнаружении подозрительной активности быстро переходите к политике quarantine или reject.

Автоматизация анализа

Для крупных компаний ручной анализ отчётов невозможен — ежедневно приходят тысячи записей. Используйте:

• API сервисов DMARC для автоматической загрузки отчетов
• Интеграцию с SIEM-системами для мониторинга аномалий
• Алерты при обнаружении новых источников отправки

Хранение отчетов

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

• Расследование угроз — оперативное выявление и устранение инцидентов безопасности
• Мониторинг активности — отслеживание динамики изменений в почтовом трафике
• Аудит соответствия — выполнение нормативных требований по безопасности

Важные меры предосторожности

При работе с отчётностью необходимо учитывать, что:

• Материалы могут содержать конфиденциальную информацию
• Требуется внедрение системы контроля доступа
• Рекомендуется использовать шифрование для форензик-отчётов
• Необходимо соблюдать политику конфиденциальности

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

Пример успешного применения DMARC

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

Ситуация до внедрения DMARC:

• Массовые жалобы клиентов на подозрительные письма
• Риск потери репутации бренда
• Возможный ущерб от компрометации данных клиентов
• Падение доверия к электронной почте компании

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

• Строгая политика проверки доменов
• Система автоматической блокировки подозрительных писем
• Механизм отправки отчетов о нарушениях
• Мониторинг входящего трафика

Результаты внедрения:

• 100% блокировка фишинговых писем от имени компании
• Полное устранение случаев фишинга через корпоративную почту
• Восстановление доверия клиентов
• Значительное улучшение показателей доставляемости легитимных писем
• Снижение количества жалоб клиентов на 95%
• Повышение безопасности клиентских данных
• Сохранение репутации бренда
• Экономия средств на устранении последствий возможных утечек

Дополнительные преимущества, которые получила компания:

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

Система DMARC не только предотвратила потенциальные убытки, но и укрепила позиции компании на рынке, продемонстрировав заботу о безопасности клиентов.

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