Как попасть в 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 — проверка аутентификации и отправка отчётов.

Что проверяется:

  • Отправляющий IP-адрес емейла указан в разрешенных в записи SPF.
  • Проверка DKIM имеет статус pass — то есть пройдена удачно.

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

  • Добавляются данные о факте и результате проверки в агрегированный отчёт, который по умолчанию отправляется раз в сутки.
  • В случае негативного срабатывания (проверка DMARC провалена) отправляется письмо с уведомлением о проваленной проверке. Такое уведомление уходит при каждой проваленной проверке — то есть 1000 писем, которые не прошли проверку, генерируют тысячу отправок отчёта вам на почту. Поэтому имеет смысл использовать отдельный адрес для получения этих отчётов, их может быть очень много ☺

Схема использования политики DMARC

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

  1. none — политика для мониторинга. Используется, когда вы только начинаете работу с DMARC и нужно понять, от имени каких доменов отправляется почта.
  2. quarantine — политика карантина, с ней письма в зависимости от почтового провайдера будут отправлены в спам, отмечены к более строгой проверке или помечены как подозрительные для пользователя.
  3. reject — самая строгая политика и высочайший уровень защиты. При политике reject отправитель указывает почтовому провайдеру блокировать все письма, которые не прошли проверки SPF и/или DKIM.

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

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

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

Обязательные параметры:

  • v (version) — версия протокола, должен быть равен DMARC1. Используется для указания, что именно эта TXT-запись определяет политику DMARC. Этот параметр должен идти первым в записи, иначе почтовый провайдер не распознает запись в целом.
  • p (Requested Mail Receiver Policy) — политика обработки писем, которую вы указываете для почтового провайдера. Три возможных варианта описаны в статье выше — none/quarantine/reject.

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

v=DMARC1; p=none

Дополнительные параметры:

  • rua — определяет адрес для отправки агрегированных отчётов. Указывается в формате rua=mailto:email@domain.com.
  • ruf — определяет адрес для отправки отчётов о непройденных проверках аутентификации. Каждая ошибка при проверке аутентификации генерирует отправку письма с отчётом об ошибке, поэтому на этот емейл могут сыпаться десятки, сотни и тысячи писем, если на вас будет совершена фишинговая атака или произойдёт сбой в ваших DNS/системе рассылок и аутентификация писем будет провалена. Формат параметра — rua=mailto:email@domain.com.

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

  • adkim (DKIM identifier alignment) — жёсткая (strict) или мягкая (relaxed) проверка по DKIM. При значении параметра strict проваленная проверка ключа DKIM приведёт к провалу всей проверки DMARC в целом. По умолчанию значение relaxed.
  • aspf (SPF identifier alignment) — жёсткая (strict) или мягкая (relaxed) проверка SPF. Работает аналогично проверке ADKIM, значение по умолчанию — relaxed.
  • rf (Report Format) — формат отчёта о проваленной проверке. По умолчанию принимает значение AFRF (Authentication Failure Reporting Format).
  • ri (Reporting Interval) — интервал между отправкой агрегированных отчётов, указывается в секундах. По умолчанию равен 86400 секунд (раз в сутки).
  • pct (Percentage) — процент сообщений, к которым будет применяться политика DMARC. Используется для постепенного внедрения или тестирования политики DMARC — можно включить политику только для 10% писем и посмотреть по результатам отчётов, не будут ли отклоняться какие-то нужные письма.
  • sp (Subdomain Policy) — политика DMARC, которая будет работать для поддоменов. Можно использовать разные политики для основного домена и поддоменов. По умолчанию остаётся такой же, как и для основного домена.
  • fo (Failure reporting options) — определяет, при каких типах непройденных проверок будут отправляться отчёты владельцу домена. Могут быть следующие значения:
    • 0 — отправлять отчёт, если не пройдены проверки и SPF, и DKIM. Используется по умолчанию.
    • 1 — отправлять отчёт, если не пройдена одна из проверок — или SPF, или DKIM.
    • d — отправлять отчёт при каждой проваленной проверке ключа DKIM.
    • s — отправлять отчёт при каждой проваленной проверке механизма SPF.

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

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

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

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

Формат файла — .zip-архив, в котором находится XML-файл. Читать его можно через любую программу-блокнот (Notepad++, TextWrangler для Mac) или даже просто браузер, но для простоты анализа рекомендуем использовать сервис Dmarcian — он приводит отчёт к человеческому виду, простому для восприятия.

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

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

  • report_metadata — общая информация, в неё входят:
    • Название почтового провайдера;
    • Контактная информация провайдера;
    • Уникальный ID отчёта;
    • Промежуток времени, который охвачен в отчёте.
    защита от спама

    Блок report_metadata

  • policy_published — информация об опубликованной политике DMARC для этого домена, включает в себя:
    • Имя домена;
    • Саму политику DMARC — none/quarantine/reject;
    • Политики проверки SPF и DKIM — жёсткая или мягкая проверка;
    • Процентное количество писем, к которым применяется данная политика;
    • Политика, применяемая для поддоменов.

    Блок policy_published

  • Результаты проверки по каждому из IP-адресов:
    • IP-адрес, с которого были отправлены письма;
    • Количество писем;
    • Домен, указанный в поле From-email;
    • Отдельно результаты проверки по SPF и DKIM;
    • Итоговая политика, применённая к этим письмам.

    Блок record

Как правильно переходить на использование политики reject?

При переходе на политику reject следует учитывать следующие моменты:

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

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

Искать источники вам помогут агрегированные отчёты — в них видно, с каких IP-адресов и доменов уходят письма.

Также в отчётах вы увидите структуру отправляемых писем:

  • Письма, соответствующие политике DMARC;
  • Письма-форварды;
  • Письма, не проходящие по DMARC, — они могут быть мошенническими сообщениями.

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

Когда вы найдёте все источники почты, нужно заняться корректной аутентификацией этих сообщений. Настройте SPF и DKIM там, где это возможно. Там, где SPF и DKIM прописать нельзя, можно попробовать изменить емейл отправителя и использовать другой адрес и домен. Либо настроить отправку с отдельного поддомена, на который не будет распространяться политика reject.

Отличную техническую справку по корректной аутентификации для DMARC можно найти в FAQ официального сайта dmarc.org.

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

Поделиться статьёй
Подписаться на рассылку