DMARC — один из механизмов защиты компании от фишинга с использованием имени её домена. Эта проблема актуальна для любого бренда, работающего с личными данными пользователей и платёжными аккаунтами, но наиболее часто с ней сталкиваются банки, платежные системы, сотовые операторы, социальные сети и крупные интернет-магазины. Мошенники отправляют от лица известной компании письмо, чтобы обманом вызвать доверие и получить доступ к логину и паролю, платежным картам, номеру телефона и другим личным данным пользователя или заставить его перейти по ссылке на вредоносный сайт. Сами письма маскируются под легальные рассылки, и важную роль тут играет использование основного домена атакуемой компании.
DMARC проверяет, действительно ли письмо было отправлено с домена компании, указанной в качестве отправителя, а также контролирует прохождение письмом протоколов аутентификации SPF и DKIM. Ключевые функции DMARC — аутентификация и отправка отчётов.
Что проверяется:
- Отправляющий IP-адрес емейла указан в разрешенных в записи SPF.
- Проверка DKIM имеет статус pass, то есть пройдена удачно.
По результатам проверки обновляется информация в отчётах:
- Добавляются данные о факте и результате проверки в агрегированный отчёт, который по умолчанию отправляется раз в сутки.
- В случае негативного срабатывания (проверка по протоколу SPF и/или DKIM провалена) отправляется емейл-уведомление. Обратите внимание: оно уходит при каждой проваленной проверке. Например, если проверку не пройдут 1000 писем, то вы получите 1000 отчетов, поэтому имеет смысл использовать для этой цели отдельный емейл-адрес.
DMARC позволяет отправителю указать, как поступать с письмом по результатам проверки. Это делается через указание политики DMARC, которая бывает трёх видов:
- none — политика для мониторинга. Используется, когда вы только начинаете работу с DMARC и хотите понять, от имени каких доменов отправляется почта.
- quarantine — политика карантина, с ней письма в зависимости от почтового провайдера будут отправлены в спам, направлены на более строгую проверку или помечены как подозрительные для пользователя.
- reject — самая строгая политика, обеспечивающая высочайший уровень защиты. При политике reject отправитель указывает почтовому провайдеру блокировать все письма, которые не прошли проверки SPF и/или DKIM.
Таким образом, при использовании DMARC получатель может быть уверен, что письмо действительно отправлено емейла, указанного в поле From.
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. Работает аналогично проверке DKIM, значение по умолчанию — 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) — определяет, в каких случаях владельцу домена будут отправляться отчеты. Можно указать один из 4 вариантов:
- 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