В статье рассмотрим принцип работы и правила (none, quarantine) политики, алгоритм действий при внедрении и отчеты по результатам проверки политики DMARC.
3 декабря 2021
Зачем нужна политика 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-политики.
Антон Капшуль, techlead Out of Cloud
Запускать 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 отправителя и проверяет письмо на подлинность. |
Схема проверки сообщений по SPF. Если письмо не прошло проверку, то, скорее всего, оно не подлинно и сервер не примет его
Схема проверки письма по DKIM. Почтовый сервер получателя запрашивает публичный ключ в DNS отправителя, чтобы узнать, было ли письмо изменено при передаче
Параллельно с проверками SPF и DKIM проводятся проверки SPF Alignment и DKIM Alignment.
| SPF Alignment | DKIM Alignment |
|
Проверяет подлинность домена, который отправляет письмо. Для этого сопоставляет два заголовка письма в поле From и в поле Return-path. Return-path — адрес, на который отправляются отчеты об ошибке, если письмо не доставлено получателю. |
Проверяет подлинность домена, отправляющего электронное письмо. Для выполнения проверки сопоставляются две подписи сообщения: в поле From и в поле подписи DKIM d=. |
|
По умолчанию (тег aspf=r) SPF alignment ищет частичное совпадение между двумя подписями, (домен / домен или домен / поддомен). Поэтому письмо пройдет проверку в двух случаях:
Если в записи DMARC указан тег aspf=s, то для успешного прохождения проверки подписи в поле From и в поле Return-path должны полностью совпадать. |
По умолчанию (тег adkim=r) DKIM alignment ищет частичное совпадение между двумя подписями, (домен / домен или домен / поддомен). Поэтому письмо пройдет проверку в двух случаях:
Если в записи DMARC указан тег adkim=s, то для успешного прохождения проверки подписи в поле From и в поле d= должны полностью совпадать. |
Если у писем настроены SPF и DKIM, но не введена политика DMARC, почтовый сервер получателя сам решает, какие меры применить к письмам, которые не прошли проверку или не были подписаны. Письма от мошенников могут быть доставлены получателям, а значит, SPF и DKIM не защищают от спуфинга в полной мере.
А DMARC явно указывает серверу получателя, что делать с письмами.
Если политика 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-подписью, политика DMARC проверяет DKIM, сверяет SPF и решает, будет ли сообщение доставлено получателю
Если сразу ввести строгие правила DMARC, то появляется риск, что из-за неправильной подписи DKIM или отправки писем поддоменом они будут признаны непригодными и не дойдут до пользователя.
Сначала лучше задать для правил значение none, чтобы изучить статистические (агрегированные) отчеты и отследить поток сообщений. После этого можно постепенно вводить более строгую политику. Чтобы перевести на эту политику только часть сообщений, нужно использовать в записи DMARC дополнительный параметр pct (Percentage). Например, если pct=10, то проверке будут подвергаться только 10 процентов сообщений.
Внедрение политики DMARC — алгоритм действий
Внедрение политики DMARC состоит из трех этапов: подготовка к настройке, формулирование записи и добавление записи DMARC в DNS домена (систему доменных имен).
Подготовка к настройке DMARC
1. Настроить SPF и DKIM для домена. SPF — нужно добавить соответствующую TXT-запись DNS в панели управления на сайте регистратора домена. Подпись DKIM — создать ключ DKIM в записи DNS на сайте регистратора домена.
Если у компании несколько доменов, то отдельно включают SPF, DKIM и DMARC для каждого.
2. Убедиться, что письма, которые отправляются через сервис рассылок, проходят проверки. Результаты проверки отмечены в служебном заголовке письма.
Формулирование записи DMARC
Запись DMARC — текстовая запись в DNS. Это набор тегов (параметров), которые указывают, насколько строго политика будет проверять письма и какие действия с ними будет совершать сервер получателя.
Пример записи 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, отчет об ошибках) — определяет адрес для отправки отчетов о непройденных проверках. Каждая выявленная ошибка при проверке запускает отправку письма с отчетом. Поэтому на указанный email могут сыпаться сотни и тысячи писем. Такое происходит, если на отправителя совершена фишинговая атака или у него произошел сбой в DNS-системе и проверка была провалена. Формат параметра — rua=mailto:email@domain.com. Если компания выбрала правило p=none, то она не будет получать отчеты об ошибках.
4. Указать в перечне необязательных тегов, какой процент писем будет проходить проверку DMARC (например, pct=10) и как часто будут отправлять отчеты (ri=86400). Необязательные параметры задаются по умолчанию, если не выбран конкретный вариант.
Рассмотрим функции необязательных параметров и подробно разберем, как выбрать значение для параметров aspf и adkim, о которых говорили выше:
| Необязательные параметры | Расшифровка | ||||||||||||||||||||||||
|
aspf (SPF identifier alignment) |
Жесткая (aspf=s) или мягкая (aspf=r) проверка SPF alignment. Тег aspf позволяет установить, совпадает ли адрес в заголовке From с адресом в заголовке Return-path. В Return-path указывается адрес, на который будут отправляться отчеты об ошибке, если письмо не было доставлено получателю. Адрес Return-path обычно совпадает с адресом в заголовке From, если при отправке рассылки используется сервер компании и отчеты об ошибке отправляются на него же. Если в рассылке участвует сторонний сервис, например Mindbox, то появляется необходимость получать отчеты на адрес сервиса (например, return-path@mindbox.ru), а в заголовке From показывать электронный адрес компании (например, sender@domain.ru). Это нужно, чтобы система автоматически обрабатывала отчеты об ошибке, а получатель видел в письме электронный адрес бренда, который он ожидал увидеть. По умолчанию aspf принимает значение relaxed (aspf=r). Если выбран параметр aspf=r, то допустимо, чтобы адрес был как из одного домена, так и из поддомена. Например, проверка будет пройдена, если адрес в Return-path example.com, а адрес в поле From subdomain.example.com. Если выбран параметр aspf=s, то допустимо только строгое соответствие адреса в заголовке Return-path и адреса в заголовке From. Компания может использовать aspf=r, если владеет всеми доменами и поддоменами. Если компания не владеет поддоменами или у нее есть сомнения в легитимности их использования, то рекомендуется использовать aspf=s. Relaxed (может быть неточное совпадение заголовков, допустимо использование поддоменов):
Strict (требуется точное совпадение заголовков, поддомены не пройдут проверку):
|
||||||||||||||||||||||||
| adkim (DKIM identifier alignment) |
Жесткая (adkim=s) или мягкая (adkim=r) проверка DKIM alignment. Проверяется соответствие домена из DKIM-подписи (d=) домену из заголовка Return-path. По умолчанию принимает значение relaxed (adkim=r). Если выбран параметр adkim=s, то допустимо, чтобы домен в поле d= точно соответствовал домену в поле Return-path или соответствовал поддомену. Например, проверка будет пройдена, если адрес в Return-path example.com, а адрес в поле d= subdomain.example.com. Если выбран параметр adkim=r, то допустимо только строгое соответствие. Выбор, когда использовать adkim=s, а когда adkim=r, аналогичен ситуации с aspf. Компания может использовать adkim=r, если владеет всеми доменами и поддоменами. Если компания не владеет поддоменами или у нее есть сомнения в легитимности их использования, то рекомендуется использовать adkim=s. Relaxed (может быть неточное совпадение заголовков, допустимо использование поддоменов)
Strict (точное совпадение домена, поддомены не пройдут проверку)
|
||||||||||||||||||||||||
| rf (report format) | Формат отчета о проваленной проверке. По умолчанию принимает значение AFRF (authentication failure reporting format). | ||||||||||||||||||||||||
| ri (reporting interval) | Интервал между отправкой статистических отчетов указывается в секундах. По умолчанию равен 86 400 секундам (раз в сутки). | ||||||||||||||||||||||||
| pct (percentage) | Процент сообщений, к которым будет применяться политика DMARC. Используется для постепенного внедрения или тестирования политики DMARC — можно включить политику только для 10% писем и посмотреть по результатам, не будут ли отклоняться какие-то нужные письма. | ||||||||||||||||||||||||
| sp (subdomain policy) | Задается для проверки DMARC-поддоменов. Можно использовать разные политики для основного домена и поддоменов. По умолчанию остается такой же, как и для основного домена. | ||||||||||||||||||||||||
| fo (failure reporting options) | Определяет, при каких типах непройденных проверок будут отправляться отчеты владельцу домена. Принимает значения 0 — отправлять отчет, если не пройдены проверки и SPF, и DKIM (используется по умолчанию); 1 — отправлять отчет, если не пройдена одна из проверок — или SPF, или DKIM; D — отправлять отчет при каждой проваленной проверке ключа DKIM; S — отправлять отчет при каждой проваленной проверке SPF. |
Добавление записи 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, например:
v=DMARC1; p=reject; rua=mailto:example@mindbox.ru, mailto:dmarc@mindbox.ru; pct=100; adkim=s; aspf=s.4. Сохранить запись.
Мнение
Главная трудность при использовании DMARC — cогласованность со всей компанией. У вас может быть много отделов и все используют разные системы для отправки писем. В отделе маркетинга используют ESP, продажи используют CRM, а в бухгалтерии подключили модуль 1С. Если неправильно настроить политики, кто-то не сможет коммуницировать с клиентами или часть процессов застопорится. Поэтому тут важна согласованность как на уровне бизнеса, так и на техническом уровне.
Антон Капшуль, techlead Out of Cloud
Отчеты по результатам проверки 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. С каждым разом делать политики строже и строже, чтобы в конечном счете письма не от вас не доходили до клиентов.
Антон Капшуль, techlead Out of Cloud
Главное о DMARC
1. DMARC — политика проверки подлинности отправителя электронного письма, основана на протоколах SPF и DKIM.
2. Внедрение DMARC позволяет избежать спуфинговых и фишинговых атак (маскировки мошенников под подлинных отправителей почты), сохранить репутацию компании и персональные данные пользователей.
3. Отправитель указывает в TXT-записи DMARC правила, которые будет выполнять сервер получателя в случае, если проверки SPF и DKIM были провалены. Если отправитель указал правило none, то как поступить с письмом, решит сервер получателя. Если выбрано правило quarantine, то письмо, которое не прошло проверку, будет отправлено в спам. При выборе правила reject письмо не будет доставлено получателю.
4. По результатам проверки писем отправитель получает отчеты, которые помогают выявить ошибки в подписи писем и случаи подделки сообщений мошенниками.
