
Как работает DMARC
DMARC разработан так, чтобы с минимальными усилиями внедрить его в любой процесс отправки почты.
Он помогает определить, соответствует ли сообщение тому, что получатель знает об отправителе. Или проще: можно ли доверять этому отправителю. Если да — подписчик получает сообщение. Если нет — срабатывает политика DMARC для неаутентифицированных сообщений.
Приведём пример.
Вот как выглядит полный цикл отправки-приёма email сообщений с включённой DMARC-политикой.
Пользу DMARC трудно переоценить. Не требуя специфических навыков для внедрения, DMARC позволяет полностью исключить нежелательный мошеннический трафик для отправителя, доставляя до получателя только аутентифицированные сообщения.
Важно отметить, что DMARC основывается на спецификациях DomainKeys Identified Mail (DKIM) и Sender Policy Framework (SPF), которые в настоящее время разрабатываются в IETF (Инженерный совет Интернета (англ. Internet Engineering Task Force, IETF) — открытое международное сообщество проектировщиков, учёных, сетевых операторов и провайдеров, созданное IAB в 1986 году и занимающееся развитием протоколов и архитектуры интернета).
Как добавить DMARC
Добавить DMARC для вашего домена довольно просто. Для этого надо найти панель управления DNS-записями на вашем хостинге и внести туда новую TXT-запись с хостом _dmarc.
Примерный порядок действий:
- Вспоминаем, на каком хостинге у нас сайт.
- Заходим на сайт хостинг-провайдера.
- Заходим в панель управления хостингом.
- В настройках находим управление DNS-записями.
- Вносим новую TXT-запись (ниже покажем, что именно надо написать).
- Сохраняем изменения.
Вот пример, как это выглядит в хостинге Fornex.
Рассмотрим пример записи DMARC TXT для домена «sender.example.com»:
В этом примере отправитель требует, чтобы получатель отклонил все неаутентифицированные сообщения и отправил агрегированный отчёт об отклонении по адресу postmaster@example.com.
Часто используемые записи DMARC
Чтобы вам не ломать голову, приведем ниже четыре самые распространенные DMARC-записи:
Самая простая DMARC-запись. По сути, она не призывает сервер получателя ни к каким действиям по отношению к неаутентифицированным письмам. Мы рекомендуем её внести, чтобы проверить, что всё работает исправно.
Показывает получателю, что не надо отклонять никаких писем, но вам на указанный адрес будет отправляться письмо. В письме — агрегированный отчёт об отправленных письмах и серверах, откуда они ушли. Такая запись нужна, если вы хотите увидеть, идёт ли от вас нежелательный трафик. Ещё это промежуточный вариант перед включением политики reject (полного отклонения неаутентифицированных сообщений).
Вариант-середнячок, один из самых распространённых. Письма, которые не аутентифицированы, будут помечаться вашим почтовым сервисом как спам или как нежелательные (зависит от сервиса).
Это уже строгая политика DMARC относительно неаутентифицированных сообщений. Мы рекомендуем вам постепенно наращивать процент отклонения таких писем: начиная с 25%, понемногу переходить к 100%. Например, когда мы в UniSender вводили DMARC, мы перешли на 100% за полтора месяца.
Ниже описываю синтаксис и значение тэгов.
Синтаксис DMARC и описание тэгов
Начну с таблицы тэгов. Потом подробнее расскажу о каждом из них.
Тэг | Назначение | Пример | Обязательный (да/нет) |
v | Версия протокола | v=DMARC1 | Да |
pct | Процент сообщений, подлежащих фильтрации | pct=20 | Нет |
ruf | URI для отправки отчетов | ruf=mailto:fail@example.com | Нет |
rua | URI для отправки агрегированных отчетов | rua=mailto:aggr@example.com | Нет |
p | Политика домена | p=quarantine | Да |
sp | Политика для субдомена | sp=reject | Нет |
adkim | Режим аутентификации для DKIM | adkim=s | Нет |
aspf | Режим аутентификации для SPF | aspf=r | Нет |
fo | Настройки отчетов об ошибках | fo=1 | Нет |
rf | Формат для отчетов об ошибках | rf=afrf | Нет |
rf | Интервал между отправкой агрегированных отчетов (в секундах). | ri=86400 | Нет |
Тэг: v | |
Назначение | Версия протокола |
Пример | v=DMARC1 |
Обязательный (да/нет) | Да |
Тэг: pct | |
Назначение | Процент сообщений, подлежащих фильтрации |
Пример | pct=20 |
Обязательный (да/нет) | Нет |
Тэг: ruf | |
Назначение | URI для отправки отчетов |
Пример | ruf=mailto:fail |
Обязательный (да/нет) | Нет |
Тэг: rua | |
Назначение | URI для отправки агрегированных отчетов |
Пример | rua=mailto:aggr |
Обязательный (да/нет) | Нет |
Тэг: p | |
Назначение | Политика домена |
Пример | p=quarantine |
Обязательный (да/нет) | Да |
Тэг: sp | |
Назначение | Политика для субдомена |
Пример | sp=reject |
Обязательный (да/нет) | Нет |
Тэг: adkim | |
Назначение | Режим аутентификации для DKIM |
Пример | adkim=s |
Обязательный (да/нет) | Нет |
Тэг: aspf | |
Назначение | Режим аутентификации для SPF |
Пример | aspf=r |
Обязательный (да/нет) | Нет |
Тэг: fo | |
Назначение | Настройки отчетов об ошибках |
Пример | fo=1 |
Обязательный (да/нет) | Нет |
Тэг: rf | |
Назначение | Формат для отчетов об ошибках |
Пример | rf=afrf |
Обязательный (да/нет) | Нет |
Тэг: ri | |
Назначение | Интервал между отправкой агрегированных отчетов (в секундах) |
Пример | ri=86400 |
Обязательный (да/нет) | Нет |
Как вы поняли, все тэги делятся на обязательные и нет. Начнём с обязательных.
Обязательные тэги
p
Политика для приёма сообщений. Обязательный тэг. Определяет политику приёма сообщений для домена и поддоменов (если отдельно не указана политика для поддоменов с помощью тега «sp»).
Принимаемые значения:
- none: никаких действий предпринимать не требуется.
- quarantine: владелец домена просит, чтобы сообщения, не прошедшие DMARC проверку, рассматривались как подозрительные. В зависимости от получателя это значит, что сообщения попадут в папку «спам», получат пометку о необходимости быть внимательным или помечены подозрительными.
- reject: владелец домена просит, чтобы сообщения, не прошедшие проверку DMARС, были отклонены. Отклонение должно производиться во время SMTP-транзакции.
v
Версия. Обязательный тэг. Обязательно должен принимать значение DMARC1. Если это не так, то запись будет проигнорирована.
Необязательные тэги
adkim
Проверка на аутентификацию DKIM-записи. Может принимать значение «r» — relaxed или «s» — strict. По умолчанию принимает значение «r».
В режиме relaxed, если проверяемая DKIM-запись относится к домену d=example.com, а отправка идет от адреса email@news.example.com, проверка будет пройдена. В случае strict проверка будет пройдена только в том случае, если отправка идет от адреса на домене example.com. Поддомены не пройдут проверку.
aspf
Проверка на аутентификацию SPF-записи. Не обязательный тэг. По аналогии с adkim, может принимать значение «r» — relaxed или «s» — strict. По умолчанию принимает значение «r».
fo
Настройки отчетов об ошибках. По умолчанию принимает значение «0».
Принимаемые значения:
- 0: генерировать отчёт об ошибках DMARC, если все основные механизмы аутентификации не пройдены.
- 1: генерировать отчёт об ошибках DMARC, если хотя бы один механизм аутентификации не пройден.
- d: генерировать отчёт об ошибке DKIM, если сообщение провалило проверку на DKIM, независимо от аутентификации.
- s: генерировать отчёт об ошибке SPF, если сообщение провалило проверку на SPF, независимо от аутентификации.
pct
Процент сообщений, к которым применяется политика DMARC. Любое целое число от 0 до 100. По умолчанию значение 100.
Это необходимо для постепенного развёртывания политики, чтобы избежать ошибок.
rf
Формат для отчётов об ошибках. По умолчанию значение afrf. На текущий момент поддерживается только это значение.
ri
Интервал между отправкой агрегированных отчетов (в секундах). Значение по умолчанию: 86400 (1 раз в сутки).
rua
Адреса для отправки агрегированных отчётов, разделенные запятой. Возможно указание mailto: ссылки для отправки отчетов по почте.
ruf
Адреса для отправки отчетов об ошибках, разделенные запятой. Указание этого тэга подразумевает, что владелец домена требует от серверов получателей отправлять детальные отчеты о каждом сообщении, не прошедшем проверку DMARC.
sp
Политика DMARC для поддоменов (по аналогии с тегом p).
История DMARC
Пара слов о создании и задачах политики DMARC.
Больше 10 лет назад для аутентификации отправителя были созданы технологии SPF и DKIM. Они помогали отследить мошеннические сообщения, отправленные от имени банков, социальных сетей, почтовых служб.
Казалось бы, SPF и DKIM позволяли легко отличить мошеннические сообщения от нормальных. Но это стало трудным по ряду причин:
- Многие отправители имеют сложную систему отправки сообщений. Например, используют сторонних поставщиков услуг. Например, сервисы рассылок.
- Если часть отправляемых сообщений аутентифицированы, а часть нет. Получатели вынуждены как-то различать неаутентифицированные и мошеннические сообщения. Иначе мошеннические могут попасть во «Входящие».
- Плохая обратная связь. Нет никакого способа определить, сколько неаутентифицированных или мошеннических сообщений отравлено. DMARC решает эту проблему.
- Если даже все сообщения аутентифицированы, получатели могут предположить, что неаутентифицированное сообщение — ошибка, а не способ мошенничества. Получатели не могут быть уверены, что не существует легитимных неподписанных ключами сообщений.
В 2007 году PayPal впервые применил этот подход и разработал в сотрудничестве с Yahoo, Google и Microsoft систему обмена данными между отправителем и получателем. Результат был чрезвычайно эффективным. Мошеннических email, предположительно полученных от PayPal, стало намного меньше.
Запомнить главное
DMARC — это политика, благодаря которой получатель письма понимает, можно ли доверять его отправителю. Позволяет бороться со спамом, фишингом и нежелательной почтой.
Чтобы настроить DMARC, зайдите в панель управления хостингом и внесите в настройки DNS-запись формата TXT. Распространённые примеры записей (в порядке нарастания строгости политики):
DMARC — ? На текущий момент некоторые почтовые провайдеры, такие как Mail.ru, Yahoo, AOL уже включили строгую политику DMARC p=reject для своих доменов.
Круто, что вы заботитесь о безопасности ваших рассылок. Если возникнут трудности — пишите в комментариях.
СВЕЖИЕ СТАТЬИ
Другие материалы из этой рубрики
Не пропускайте новые статьи
Подписывайтесь на соцсети
Делимся новостями и свежими статьями, рассказываем о новинках сервиса
«Честно» — авторская рассылка от редакции Unisender
Искренние письма о работе и жизни. Свежие статьи из блога. Эксклюзивные кейсы и интервью с экспертами диджитала.