В статье рассмотрим принцип работы и правила (none, quarantine) политики, алгоритм действий при внедрении и отчеты по результатам проверки политики DMARC.
3 декабря 2021
Зачем нужна политика DMARC и как ее внедрить
Зачем нужна политика DMARC и как ее внедрить
DMARC (domain-based message authentication, reporting & conformance) — правила проверки email-рассылок. Помогает компании:
— защитить клиентов от действий мошенников в email-рассылках;
— доставить письма. Благодаря DMARC провайдер клиента определяет, куда направить письмо от компании — во «Входящие» или в «Спам».
Три задачи, которые помогает решать DMARC
Защищать клиентов
DMARC защищает клиентов компании от действий мошенников в email-рассылках. Задача мошенников — получить персональные данные или деньги клиентов компании. Для этого они подделывают адрес отправителя письма (спуфинг) или отправляют в тексте сообщения ссылку на копию сайта компании (фишинг).
Пример фишингового письма от мошенников, которые выдают себя за Сбербанк. Когда пользователь перейдет по ссылке, на его компьютер скачается вирус
Количество фишинговых ресурсов постоянно растет. Например, ВТБ за первые полгода 2021 года заблокировал более 5,5 тысячи сайтов и мошеннических приложений, которые мимикрируют под ВТБ. Жертвами таких ресурсов становятся клиенты компаний всех сфер: от промышленности и торговли до IT.
Во втором квартале 2021 года 19,54% фишинговых атак совершалось от лица популярных интернет-магазинов. Спуфинг и фишинг сильно бьют по авторитету организации, клиенты — жертвы мошенников не доверяют компании и отказываются от ее услуг, в результате компания теряет прибыль.
DMARC помогает фильтровать рассылки, которые маскируются под подлинные письма компании.
При внедрении DMARC отправитель указывает провайдеру, например Gmail или Mail.ru, как поступить с сомнительными письмами. Это помогает избежать случаев, когда рассылки мошенников обходят спам-фильтры и вредят пользователям.
Получать обратную связь о проверках рассылок
Компания получает статистические (агрегированные) отчеты о том, сколько процентов писем не прошло проверку, и отчеты об ошибке по каждому письму, которое не прошло проверку. Отчеты помогают расследовать технические проблемы с цифровыми подписями и попытки подмены имени отправителя.
По-хорошему, DMARC-политики нужны всем клиентам. DMARC нужен для защиты от фишинга.
Когда, к примеру, приходит письмо noreplay.ssuport@gmail.com с призывом сменить пароль и ссылкой на s-mail-google.com, без политики DMARC высока вероятность, что пользователь раскроет свой доступ к почте. Если у вас сервис, к которому пользователь привязывает платежные данные или оставляет любую другую приватную информацию, то вам как поставщику услуг или продукта нужно использовать DMARC-политики.
Запускать AMP-рассылки
Это рассылки с интерактивными и динамическими элементами. DMARC — обязательное требование почтовиков для запуска таких рассылок.
Принцип работы политики DMARC
DMARC — это надстройка над двумя другими протоколами проверки писем — SPF и DKIM, которые помогают провайдеру, например Yahoo и Outlook, сортировать письма.
SPF и DKIM позволяют убедиться в подлинности отправителя: SPF проверяет, что с указанного IP-адреса можно делать рассылки от имени отправителя, а DKIM определяет, не было ли имя отправителя изменено при доставке.
SPF (sender policy framework)
DKIM (domain keys identified mail)
Отправитель указывает IP-адреса, которым разрешено делать рассылки от имени домена отправителя.
Сервера получателя проверяют, действительно ли письмо с указанным доменом отправлено с сервера, который одобрил владелец домена.
Сервера получателя проверяют, действительно ли письмо с указанным доменом отправлено с сервера, который одобрил владелец домена.
Получатель проверяет, не было ли письмо подделано или изменено при доставке.
При отправке письма из контента и приватного ключа автоматически генерируется подпись письма. Отправитель вносит эту подпись в служебный заголовок письма.
Сервер получателя запрашивает публичный ключ DKIM в DNS отправителя и проверяет письмо на подлинность.
При отправке письма из контента и приватного ключа автоматически генерируется подпись письма. Отправитель вносит эту подпись в служебный заголовок письма.
Сервер получателя запрашивает публичный ключ DKIM в DNS отправителя и проверяет письмо на подлинность.
Параллельно с проверками SPF и DKIM проводятся проверки SPF Alignment и DKIM Alignment.
SPF Alignment
DKIM Alignment
Проверяет подлинность домена, который отправляет письмо. Для этого сопоставляет два заголовка письма в поле From и в поле Return-path. Return-path — адрес, на который отправляются отчеты об ошибке, если письмо не доставлено получателю.
Проверяет подлинность домена, отправляющего электронное письмо. Для выполнения проверки сопоставляются две подписи сообщения: в поле From и в поле подписи DKIM d=.
По умолчанию (тег aspf=r) SPF alignment ищет частичное совпадение между двумя подписями, (домен / домен или домен / поддомен). Поэтому письмо пройдет проверку в двух случаях:
— домен в поле From — example.com и домен в Return-path — example.com
— домен в поле From — mail.example.com, а домен в Return-path — example.com.
— домен в поле From — example.com и домен в Return-path — example.com
— домен в поле From — mail.example.com, а домен в Return-path — example.com.
По умолчанию (тег adkim=r) DKIM alignment ищет частичное совпадение между двумя подписями, (домен / домен или домен / поддомен). Поэтому письмо пройдет проверку в двух случаях:
— домен в поле From — example.com и домен в d= — example.com
— домен в поле From — mail.example.com, а домен в d= — example.com.
— домен в поле From — example.com и домен в d= — example.com
— домен в поле From — mail.example.com, а домен в d= — example.com.
Если в записи DMARC указан тег aspf=s, то для успешного прохождения проверки подписи в поле From и в поле Return-path должны полностью совпадать.
Если в записи DMARC указан тег adkim=s, то для успешного прохождения проверки подписи в поле From и в поле d= должны полностью совпадать.
Если у писем настроены SPF и DKIM, но не введена политика DMARC, почтовый сервер получателя сам решает, какие меры применить к письмам, которые не прошли проверку или не были подписаны. Письма от мошенников могут быть доставлены получателям, а значит, SPF и DKIM не защищают от спуфинга в полной мере.
А DMARC явно указывает серверу получателя, что делать с письмами: принять, отклонить или отправить в спам.
Если политика DMARC внедрена, то алгоритм проверки сообщений выглядит так:
- Компания отправляет письмо.
- Почтовый сервер проверяет достоверность SPF, SPF Alignment, DKIM и DKIM Alignment в письме.
- К письмам, не прошедшим проверку по SPF, SPF Alignment и DKIM, DKIM Alignment, применяется политика DMARC. В зависимости от выбранной политики DMARC письмо не будет доставлено получателю или уйдет в спам. Если выбрано правило none и письмо не прошло проверку, то, как с ним поступать, решит сервер получателя.
- Отправитель получает отчет по результатам проверки. Он нужен, чтобы компания знала обо всех источниках, которые отправляют электронные письма от ее имени.
- Письма, которые прошли проверку, доставляются получателю.
Правила политики DMARC: none, quarantine, reject
В политике DMARC предусмотрено три правила работы с подозрительными письмами — none, quarantine и reject. Настраивая DMARC, отправитель выбирает один из вариантов, это обязательный этап.
None. Все письма — даже те, которые не прошли проверку, проходят фильтры на стороне получателя. В результате они направляются в его почтовый ящик или в спам (в зависимости от условий, которые установил получатель). Отправитель рассылки получает отчет на почту.
Эта политика подходит для отслеживания — компания видит, кто отправил от ее имени письма и прошли ли они проверку DMARC. Если значительная часть писем попадает в спам, то стоит проверить SPF и DKIM.
Quarantine. Письма, которые не прошли проверку, отправляются в спам или помечаются как подозрительные для пользователя.
Reject. Самая сильная защита пользователя. Если компания выбрала правило reject, то почтовый провайдер блокирует все письма, которые не прошли проверку, — они не попадут в спам получателя и будут отклонены.
Если сразу ввести строгие правила DMARC, то появляется риск, что из-за неправильной подписи DKIM или отправки писем поддоменом они будут признаны непригодными и не дойдут до пользователя.
Сначала лучше задать для правил значение none, чтобы изучить статистические (агрегированные) отчеты и отследить поток сообщений. После этого можно постепенно вводить более строгую политику. Чтобы перевести на эту политику только часть сообщений, нужно использовать в записи DMARC дополнительный параметр pct (Percentage). Например, если pct=10, то проверке будут подвергаться только 10 процентов сообщений.
Как внедрить политику DMARC — алгоритм действий
Процесс состоит из трех этапов: подготовка к настройке, формулирование записи и добавление записи DMARC в DNS домена (систему доменных имен).
Подготовиться к настройке DMARC
1. Настроить SPF и DKIM для домена. Если у компании несколько доменов, SPF, DKIM и DMARC настраивают отдельно для каждого. Некоторые платформы для рассылок автоматически обеспечивают корректность настройки SPF-подписи — в этом случае самостоятельно настраивать ее не нужно. Обычно это указано в инструкции по настройке цифровых подписей.
2. Убедиться, что письма, которые отправляются через сервис рассылок, проходят проверки. Результаты проверки отмечены в служебном заголовке письма.
Формулировать запись DMARC
Запись DMARC — определяет, что делать с письмами, не прошедшими SPF и DKIM: отклонить, пометить как спам или принять.
Пример записи DMARC: v=DMARC1; p=reject; rua=mailto: example@mindbox.ru, mailto: dmarc@mindbox.ru; pct=100; adkim=s; aspf=s
Чтобы политика работала корректно, нужно поставить теги в правильном порядке:
1. Указать версию записи — DMARC1. Этот тег позволяет понять, что это DMARC-запись.
2. Прописать теги, которые обозначают выбранное правило для политики. Примеры тега: p=none, p=quarantine, p=reject.
3. Прописать теги, которые определяют, какие отчеты будут отправляться по результатам проверки и на какие email-адреса.
- rua (aggregate reports, статистические отчеты) — отвечает за отправку статистических (агрегированных) отчетов. Благодаря им отправитель изучает текущую ситуацию с отправкой писем и проверяет, корректно ли доставляются рассылки. Формат параметра — rua=mailto: email@domain.com. Если компания не хочет получать агрегированные отчеты, то из записи нужно убрать тег rua.
- ruf (forensic reports, отчет об ошибках) — определяет адрес для отправки отчетов о непройденных проверках.
4. Указать в перечне необязательных тегов, какой процент писем будет проходить проверку DMARC (например, pct=10) и как часто будут отправлять отчеты (ri=86400).
Необязательные параметры aspf и adkim определяют жесткость проверки соответствия между адресом отправителя в SPF/DKIM и адресом в поле From:. Значения s (strict) и r (relaxed) задают разные уровни строгости. В большинстве случаев рекомендуется использовать s для обоих параметров, чтобы обеспечить максимальную безопасность. Если компания только внедряет политику DMARC, рекомендуется начать с легкого режима: aspf=r; adkim=r.
Добавить запись DMARC в DNS домена
Чтобы добавить запись DMARC в настройки DNS домена отправителя, нужно:
1. Войти в панель управления регистратора домена компании.
2. Перейти в раздел управления записями DNS необходимого домена.
3. Добавить в поле параметра _dmarc новую TXT-запись. Состоять она должна из двух полей — TXT record name и TXT record value:
- TXT record name (название записи TXT). В этом поле в имени хоста DNS нужно ввести строку _dmarc.mindbox.ru (вместо mindbox.ru должен быть указан домен отправителя).
- TXT record value (значение записи TXT). В этом поле нужно ввести ранее составленную запись DMARC, например:
4. Сохранить запись.
Главная трудность при использовании DMARC — согласованность со всей компанией. У вас может быть много отделов и все используют разные системы для отправки писем. В отделе маркетинга используют ESP, продажи используют CRM, а в бухгалтерии подключили модуль 1С. Если неправильно настроить политики, кто-то не сможет коммуницировать с клиентами или часть процессов застопорится. Поэтому тут важна согласованность как на уровне бизнеса, так и на техническом уровне.
Отчеты по результатам проверки DMARC
Статистические (агрегированные) отчеты проверки DMARC позволяют отправителю отследить источники рассылок и показывают:
- какие серверы или сторонние отправители отправляют сообщения от имени домена компании;
- какой процент писем компании успешно проходит проверку;
- какие серверы отправляют сообщения, которые не проходят DMARC;
- что сервер получателя делает с письмами, которые не прошли проверку.
Статистические (агрегированные) отчеты составляются принимающим сервером и отправляются автоматически один раз в сутки. Если компания выбрала правило quarantine или reject и письмо не прошло проверку, то будет сформирован отчет о негативном срабатывании политики DMARC.
Заголовок письма с отчетом формируется по следующему принципу:
Заголовок письма = Получатель письма!Домен, проходящий проверку DMARC!Отметка времени начала проверки!Отметка времени окончания проверки!Уникальный идентификатор.расширение
Например, заголовок письма с отчетом, отправленным домену example.com от почтового приемника mail.receiver.example:
mail.receiver.example!example.com!1013662812!1013749130.gz
Также возможен заголовок письма, который состоит из таких частей:
- Subject, имя домена DNS отправителя рассылки.
- Submitter, доменное имя получателя, сервер которого формирует отчет.
- Поле Report-ID: предназначено для выявления и игнорирования повторяющихся отчетов.
Например, владельцу домена example.com отправляется отчет от почтового приемника mail.receiver.example. Вот как будет выглядеть заголовок письма:
Report Domain: example.com Submitter: mail.receiver.example Report-ID: <2002.02.15.1>
Пример такого формата заголовка письма:
Адрес, с которого приходит отчет, состоит из доменного имени почтового сервера (Submitter, в примере выше — rolandberger.com) и названия почтового сервера получателя (в примере — DMARC_muc-mta-1), которое выбирает системный администратор.
Рекомендации для внедрения и использования DMARC
1. Начать с простых политик, которые ничего не будут делать — только отправлять отчеты. Так вы сможете составить карту — кто рассылает письма, используя ваш домен. Это поможет обнаружить мошеннические отправки. Срок этого этапа зависит от объема коммуникаций.
2. Исходя из данных первого этапа переходить к более строгим политикам и помещать письма в карантин, если они не от вас.
3. С каждым разом делать политики строже и строже, чтобы в конечном счете письма не от вас не доходили до клиентов.
Главное о DMARC
1. DMARC — политика проверки подлинности отправителя электронного письма, основана на протоколах SPF и DKIM.
2. Внедрение DMARC позволяет избежать спуфинговых и фишинговых атак (маскировки мошенников под подлинных отправителей почты), сохранить репутацию компании и персональные данные пользователей.
3. Отправитель указывает в TXT-записи DMARC правила, которые будет выполнять сервер получателя в случае, если проверки SPF и DKIM были провалены. Если отправитель указал правило none, то как поступить с письмом, решит сервер получателя. Если выбрано правило quarantine, то письмо, которое не прошло проверку, будет отправлено в спам. При выборе правила reject письмо не будет доставлено получателю.
4. По результатам проверки писем отправитель получает отчеты, которые помогают выявить ошибки в подписи писем и случаи подделки сообщений мошенниками.
