Содержание11
DMARC — запись в DNS, в которой домен сообщает получателям писем, что делать с сообщениями «от его имени», не прошедшими проверку SPF и DKIM: доставить, пометить как спам или отклонить. Вторая половина DMARC — отчёты: получатели присылают владельцу домена сводки о том, кто и как отправлял почту с этого домена. Именно DMARC связывает проверки SPF и DKIM с адресом в поле «От кого», который видит человек.
Что такое DMARC?
DMARC расшифровывается как Domain-based Message Authentication, Reporting, and Conformance. По RFC 7489 это масштабируемый механизм, с помощью которого организация-отправитель выражает политики и предпочтения домена по проверке, обработке и отчётности для писем. Сам стандарт имеет статус информационного документа, но его поддерживают крупные почтовые сервисы.
Важно, чего DMARC не делает. Он ничего не подписывает и не перечисляет серверы: для этого есть DKIM и SPF. DMARC берёт их результаты и добавляет две вещи: требование, чтобы проверенный домен совпадал с адресом в поле «От кого», и просьбу к получателю, как поступить с письмами, которые проверку не прошли.
Google в справке Workspace формулирует так: DMARC сообщает принимающим серверам, какие действия предпринять с письмами домена, не прошедшими аутентификацию SPF или DKIM. Из этого же следует, что без SPF или DKIM DMARC работать не будет.
Как DMARC проверяет письмо?
Проверка идёт по домену из видимого поля «От кого» (From). Сервер получателя смотрит, прошло ли письмо SPF или DKIM и совпадает ли проверенный домен с этим доменом. Такое совпадение называется выравниванием.
По RFC 7489 письмо удовлетворяет DMARC, если хотя бы один из механизмов даёт результат pass и этот результат получен для выровненного идентификатора. Достаточно одного: либо SPF, либо DKIM.
Выравнивание нужно потому, что просто верная подпись ничего не доказывает. RFC 7489 объясняет: письмо может нести верную подпись любого домена, даже плохого актёра, поэтому одного факта верной подписи недостаточно для вывода о подлинности домена автора. Мошенник подпишет письмо своим ключом и напишет в поле «От кого» ваш домен. DKIM пройдёт, но домен подписи не совпадёт с From, и DMARC провалится.
Выравнивание бывает двух видов. В свободном режиме (relaxed, значение по умолчанию) допускается частичное совпадение, например поддомена, а в строгом (strict) домены должны совпадать точно. Режимы задаются тегами adkim и aspf.
Факт. По RFC 7489 DMARC проверяет только DNS-домен: он не аутентифицирует локальную часть адреса и не проверяет, правдиво ли содержание письма.
Три политики DMARC: none, quarantine, reject
Политика — тег p в записи. Он говорит получателю, как поступать с письмом, которое не прошло проверку DMARC. Это просьба, окончательное решение остаётся за получающим сервером.
| Политика | Что просит у получателя | Когда ставить |
|---|---|---|
| none | Не предпринимать особых действий, доставлять как обычно, но присылать отчёты | Начало внедрения, сбор данных |
| quarantine | Считать письма подозрительными, обычно отправлять в «Спам» | Когда отчёты чистые, но остался риск |
| reject | Отклонять письма на этапе SMTP | Когда проверено, что все легальные отправители проходят DMARC |
По справке Google, при политике quarantine сообщения помечаются как спам и попадают в папку «Спам» получателя, а при reject принимающий сервер обычно отправляет отправляющему сообщение об ошибке. Политика none не защищает от подделки: письма доставляются, но вы получаете отчёты.
Рекомендация для самого частого случая, когда у компании почта в облачном сервисе плюс CRM и рассылка: начинайте с none и переходите к quarantine, когда отчёты покажут, что все ваши сервисы проходят проверку. Reject оставьте на потом или на домены, которые вообще не отправляют почту. Если вы отправляете только из одного сервиса и в отчётах нет посторонних, переход можно сделать быстрее.
Из чего состоит запись DMARC
Запись — одна TXT-строка из тегов вида «тег=значение», разделённых точкой с запятой. По RFC 7489 её публикуют в поддомене _dmarc: для домена site.ru это имя _dmarc.site.ru.
| Тег | Обязателен | Что задаёт |
|---|---|---|
| v | да | версия, всегда DMARC1, должен идти первым |
| p | да | политика: none, quarantine или reject |
| rua | нет | куда присылать сводные отчёты, формат mailto:адрес |
| sp | нет | политика для поддоменов, без него действует p |
| pct | нет | доля писем, к которым применяют политику, от 1 до 100 |
| adkim, aspf | нет | строгость выравнивания для DKIM и SPF |
Справка Google уточняет порядок: теги v и p должны быть указаны первыми, остальные идут в любом порядке. Тег rua необязателен, но Google рекомендует включать его всегда: без него вы не получите отчётов.
Пример записи для начала внедрения:
_dmarc.site.ru. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@site.ru"
Эта строка говорит: политика none, сводные отчёты присылать на адрес dmarc-reports@site.ru. Позже p=none заменяют на p=quarantine, а при необходимости добавляют pct.
Тег ruf, который просит присылать отчёты о каждом сбое, Gmail не поддерживает. Не рассчитывайте на него как на источник данных.
Отчёты DMARC: что в них и куда их слать
Отчёты — главная причина начинать с none. Получатели присылают сводки о письмах, которые заявляли ваш домен в поле From: с каких IP они пришли, прошли ли SPF и DKIM, что с ними сделали. По RFC 7489 реализации DMARC обязаны уметь присылать ежедневные отчёты. Данные приходят XML-файлом, который по RFC 7489 рекомендуется сжимать gzip.
Адрес для отчётов задаёт тег rua. Он должен содержать префикс mailto:, а несколько адресов разделяют запятыми. Google советует не использовать личный адрес: количество отчётов зависит от объёма рассылки и числа получающих доменов, а крупные организации получают сотни и даже тысячи отчётов в день. Заведите для них отдельный ящик или группу.
Сырые XML-отчёты читать неудобно, поэтому для разбора используют бесплатные и платные сервисы, которые принимают rua-ящик и показывают, какие источники отправляют от вашего домена. Что искать в отчётах:
- Неизвестные IP-адреса — кто-то отправляет почту от вашего имени. Это либо забытый сервис, либо подделка.
- Легальные сервисы без pass — CRM, рассылка или форма на сайте шлют письма без SPF или DKIM, выровненных с вашим доменом.
- Рост подделок — количество писем с провалом проверки растёт: повод ускорить переход на quarantine.
Как внедрять DMARC без потери писем?
Главный риск DMARC — ужесточить политику раньше, чем все легальные отправители настроены. По справке Google, если не настроить SPF или DKIM до включения DMARC, письма домена, вероятно, получат проблемы с доставкой. Поэтому порядок такой:
Тег pct по справке Google принимает целое от 1 до 100. Если его нет, политика применяется ко всем письмам.
Мнение. Если вы не готовы читать отчёты, DMARC с p=none не принесёт защиты: это только запись, которая собирает данные. Либо назначьте человека или сервис, который разбирает отчёты, либо отложите внедрение: политика, которую не проверяют, бесполезна.
Как добавить запись DMARC в DNS?
DMARC настраивают там, где управляют DNS домена. Для Google Workspace справка прямо говорит: в консоли администратора для настройки DMARC ничего делать не нужно, запись создают в панели хостинга домена. Для Яндекс 360 и других сервисов принцип тот же: по RFC 7489 DMARC публикуется как обычная TXT-запись в зоне домена.
Порядок:
nslookup -type=txt _dmarc.site.ru
- Проверьте на реальном письме. Отправьте письмо на ящик Gmail и откройте оригинал: в заголовке Authentication-Results ищите dmarc=pass.
Для поддоменов отдельная запись обычно не нужна: по справке Google, без тега sp поддомены наследуют политику родительского домена.
Частые ошибки при настройке DMARC
Большинство проблем связано с поспешным ужесточением и с отчётами.
- 01 Сразу p=reject
Письма сервисов, которых вы забыли настроить, отклоняются получателями, а вы узнаёте об этом от клиентов.
- 02 Ни одного отчёта
Тег rua не указан или стоит без mailto:, и данных для решений нет.
- 03 Отчёты на личную почту
Ящик быстро переполняется, а нужные письма теряются среди сотен сводок.
- 04 Две записи DMARC
При нескольких записях DMARC к письмам не применяется вовсе, и политика не действует.
- 05 Теги в неверном порядке
V и p должны идти первыми, иначе запись может быть проигнорирована.
- 06 Паника из-за пересланных писем
Списки рассылки и пересылка ломают проверку или выравнивание, и RFC 7489 прямо называет это ограничением. Единичные провалы из чужой инфраструктуры нормальны.
С чего начать
Составьте список сервисов, которые отправляют почту с вашего домена, и проверьте, что у каждого настроены SPF или DKIM. Затем опубликуйте запись с p=none и адресом отчётов, а через неделю-две откройте первые данные. Для переезда сайта вместе с почтой пригодится чек-лист переноса на другой хостинг. Если домен куплен через нас, DNS-записи для почты мы добавим: это часть регистрации домена.
Источники
- Настройте DMARC — Справка Google Workspace
- Требования к отправителям электронной почты — Справка Google Workspace
- RFC 7489. Domain-based Message Authentication, Reporting, and Conformance (DMARC) — IETF
