В статье рассмотрим принцип работы и правила (none, quarantine) политики, алгоритм действий при внедрении и отчеты по результатам проверки политики 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 отправителя и проверяет письмо на подлинность. |

Схема проверки сообщений по 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С. Если неправильно настроить политики, кто-то не сможет коммуницировать с клиентами или часть процессов застопорится. Поэтому тут важна согласованность как на уровне бизнеса, так и на техническом уровне.
Отчеты по результатам проверки 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. По результатам проверки писем отправитель получает отчеты, которые помогают выявить ошибки в подписи писем и случаи подделки сообщений мошенниками.