Отчёты DMARC и внедрение политики: от p=none до reject

Внедрение DMARC - это три политики и доказательства между ними. Вы публикуете p=none с адресом rua, две-четыре недели собираете ежедневные агрегированные отчёты от крупных получателей, исправляете каждого легитимного отправителя, у которого не проходит выравнивание, затем переходите на p=quarantine и наконец на p=reject, читая отчёты на каждом шаге. Весь смысл - в отчётах. Это единственный способ увидеть, кто по всему интернету отправляет почту с вашим доменом в строке From:: ваши собственные серверы, сервисы, о которых вы забыли, пересылки и люди, выдающие себя за вас. Перейти сразу на p=reject, не читая их, - это способ узнать, что ваша система выставления счетов никогда не проходила аутентификацию, в тот самый день, когда клиенты перестают получать счета.

Статья предполагает, что вы знаете, что такое SPF, DKIM и DMARC; если нет, начните со статьи SPF, DKIM и DMARC простыми словами. Здесь речь об отчётах и поэтапном внедрении.

Запись по тегам - с прицелом на внедрение#

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1

Теги, которые важны во время внедрения:

fo=1 просит присылать отчёты о сбоях, когда не проходит любой из механизмов, а не только когда не проходят все. Это влияет лишь на отчёты ruf, которые большинство крупных получателей из соображений приватности не отправляет, так что вреда почти нет, а иногда бывает польза.

ri - это просьба. Получатели всё равно присылают отчёты раз в сутки, так что этот тег можно не указывать.

Что содержит агрегированный отчёт#

Агрегированные отчёты приходят вложениями в письмах - XML в gzip или zip, по одному от каждого получателя в сутки; присылают их Google, Microsoft, Yahoo и множество провайдеров поменьше. Каждый описывает почту, которую этот получатель видел от имени вашего домена, сгруппированную по IP отправителя и результату. В сокращённом до сути виде:

<feedback>  <report_metadata>    <org_name>google.com</org_name>    <date_range><begin>1791331200</begin><end>1791417599</end></date_range>  </report_metadata>  <policy_published>    <domain>example.com</domain><p>none</p><adkim>r</adkim><aspf>r</aspf>  </policy_published>  <record>    <row>      <source_ip>203.0.113.25</source_ip>      <count>412</count>      <policy_evaluated>        <disposition>none</disposition><dkim>pass</dkim><spf>pass</spf>      </policy_evaluated>    </row>    <identifiers><header_from>example.com</header_from></identifiers>    <auth_results>      <dkim><domain>example.com</domain><selector>s2026a</selector><result>pass</result></dkim>      <spf><domain>example.com</domain><result>pass</result></spf>    </auth_results>  </record></feedback>

Читайте каждый record как предложение: «С IP 203.0.113.25 пришло 412 писем с From: example.com; DKIM прошёл с выравниванием, SPF прошёл с выравниванием; мы ничего с ними не сделали, потому что политика - none». Блок policy_evaluated даёт выровненные вердикты DMARC. Блок auth_results даёт сырые результаты SPF и DKIM с доменом, для которого получен каждый из них, - так и видно, что SPF прошёл, но для bounces.provider.example, который не выровнен.

После первой недели никто не читает их глазами. Скармливайте их парсеру: parsedmarc - широко используемый open-source-парсер, который превращает отчёты в дашборд с поиском, а многие коммерческие сервисы делают то же самое с меньшими хлопотами по настройке. Некоторые почтовые серверы и сами обрабатывают входящие отчёты - свежие версии Stalwart умеют анализировать отчёты DMARC, доставленные на заданные вами адреса, и показывать их в веб-админке, - и для небольшого домена этого достаточно.

Заведите для отчётов отдельный адрес. Нагруженный домен получает их десятками в день, и в своём ящике человеку они ни к чему.

Разбор найденных отправителей#

Через две недели отчётов у вас будет список IP-источников. Каждый попадает в одну из четырёх групп, и для каждой своё действие.

1. Ваша собственная инфраструктура, с выравниванием. Ваш почтовый сервер, проходящий DKIM с вашим доменом. Делать ничего не нужно.
2. Легитимные сервисы без выравнивания. Платформа рассылок, CRM, хелпдеск, биллинг, сервис для найма - отправляют почту от имени вашего домена, но проходят SPF и DKIM только для своих доменов или не проходят вовсе. Вот где настоящая работа. Определите провайдера по обратному DNS IP или через поиск по IP, затем включите в его настройках DKIM с вашим доменом и, если предлагается, собственный домен return path.
3. Пересылки. Университетские алиасы, старые адреса с пересылкой в Gmail, списки рассылки. SPF не проходит, потому что IP пересылающего сервера не ваш; DKIM часто всё равно проходит, если письмо не изменялось. Исправить это вы не можете, а при проходящем DKIM и не нужно.
4. Подделыватели. IP, не имеющие к вам никакого отношения, проваливающие всё, часто из стран, откуда вы не отправляете почту. Именно против них и нужно принудительное применение DMARC. Отметьте их и идите дальше.

Расставить приоритеты помогает объём. Легитимный сервис, отправляющий без выравнивания 3000 писем в месяц, важен; пересылка, передавшая шесть писем, - нет.

Отправителя, который появляется раз в месяц, - зарплата, квартальные выписки, ежегодное уведомление о продлении - легко пропустить за двухнедельное окно. Прежде чем двигаться дальше, поспрашивайте коллег: бухгалтерия, отдел кадров, маркетинг и тот, кто отвечает за формы на сайте, - каждый знает об отправителях, о которых IT никогда не слышал.

Как опознать незнакомый IP

IP-адрес в отчёте полезен, только когда известно, чей он. Обычно вопрос решают три быстрые проверки:

# Reverse DNS often names the provider outright$ dig +short -x 198.51.100.77# Who holds the address block$ whois 198.51.100.77 | grep -iE 'orgname|org-name|netname|descr'

Затем посмотрите на domain и selector DKIM в той же строке отчёта: подпись с d=sendgrid.net или селектор вроде pm называет сервис, даже когда IP ничего не говорит. Если IP принадлежит крупному облачному провайдеру и ни одна подпись не называет сервис, спросите коллег, что там работает, прежде чем считать его враждебным.

Разбор на примере: отправители, которых никто не перечислил#

Небольшая компания с собственным почтовым сервером публикует p=none и направляет rua в ящик для отчётов. Через три недели разобранные отчёты показывают пять источников, отправляющих почту от имени example.com:

1. Собственный почтовый сервер, 6200 писем, DKIM и SPF выровнены. Всё в порядке.
2. Платформа хелпдеска, 900 писем, SPF проходит для домена возвратов платформы, DKIM подписан собственным доменом платформы. Ни то ни другое не выровнено - при p=reject каждый ответ на тикет отклонялся бы.
3. Бухгалтерская программа, 140 писем, все за последние два дня месяца, DKIM нет вовсе, SPF не проходит. В IT никто не знал, что она отправляет почту; бухгалтерия настроила её отправлять счета от accounts@example.com.
4. Университетский адрес с пересылкой, принадлежащий одному сотруднику, 30 писем, SPF не проходит, DKIM проходит. Делать ничего не нужно.
5. Двенадцать IP из трёх стран, 2000 писем, всё проваливается. Подделка.

Исправления занимают полдня. Хелпдеск предлагает DKIM с собственным доменом: две CNAME-записи, клик для подтверждения - и его подписи теперь несут d=example.com. Бухгалтерская программа подписывать не умеет, но может отправлять почту через SMTP-сервер, поэтому бухгалтерия направляет её на порт отправки собственного почтового сервера компании с отдельной учётной записью, и теперь счета подписывает Stalwart, как и всё остальное.

Через неделю отчёты показывают, что источники 1-3 выровнены. Компания переходит на p=quarantine, а ещё через месяц - на p=reject. Подделки из группы 5 продолжают появляться в отчётах - теперь с disposition reject против каждого письма. Эта последняя строка - и есть вся отдача от проделанной работы.

Выравнивание, если точно#

DMARC проходит, если проходит SPF или DKIM и домен, для которого он прошёл, выравнивается с доменом в From:.

• DKIM выравнивается, когда домен d= подписи совпадает с доменом в From:.
• SPF выравнивается, когда домен отправителя из конверта (MAIL FROM, показывается как Return-Path) совпадает с доменом в From:.

В мягком режиме (r, по умолчанию) «совпадает» означает один и тот же организационный домен: mail.example.com выравнивается с example.com, и оба выравниваются с news.example.com. Организационный домен определяется по Public Suffix List, поэтому example.co.uk работает правильно, а co.uk никогда не считается одной организацией. В строгом режиме (s) домены должны быть идентичны.

Оставьте оба в мягком режиме. Строгое выравнивание ломает собственные поддомены return path, благодаря которым SPF выравнивается у сторонних отправителей, и ничего существенного для большинства доменов не даёт.

Внедрение по шагам#

1. Опубликуйте `p=none` с `rua`. Подождите две-четыре недели. Захватите хотя бы один конец месяца, если ваша организация рассылает счета.
2. Исправьте каждого легитимного невыровненного отправителя, которого показывают отчёты. Через неделю после каждого исправления перепроверьте отчёты и убедитесь, что изменение сработало.
3. Перейдите на `p=quarantine`. Если волнуетесь, применяйте политику постепенно с помощью pct: pct=25 отправляет в спам четверть непрошедшей почты, а с остальной обращается как при none. Поднимите до pct=100 после недели-двух без жалоб.
4. Продержитесь на `quarantine` не меньше двух недель, пока ничего легитимного не проваливается.
5. Перейдите на `p=reject`. Непрошедшая почта теперь отклоняется ещё во время SMTP-диалога, так что неправильно настроенный отправитель получает возврат, а не тихо попадает в спам, - для диагностики это лучше, чем quarantine.
6. Сохраните адрес `rua`. Добавляются новые сервисы, кто-то меняет провайдера, ротация ключа идёт не так. Благодаря отчётам вы узнаете об этом за сутки, а не за месяц.

Тег pct всегда соблюдался непоследовательно - некоторые получатели фактически считают любое значение меньше 100 «политика не применяется». Новая редакция спецификации DMARC (её часто называют DMARCbis) отходит от него в пользу более простого флага тестирования. Используйте pct как мягкий разгон, если хотите, но не полагайтесь на него для тонкой настройки.

О поддоменах стоит подумать до шага 5. sp= задаёт политику для поддоменов, по умолчанию равную p самого домена. Если вы отправляете почту с поддоменов вроде news.example.com, проверяйте в отчётах и их. Если вы никогда не отправляете почту с поддоменов, sp=reject с самого начала перекрывает излюбленный приём подделки почти без риска.

Что ломается при p=reject#

Три вида почты могут не проходить и после аккуратного внедрения, и знать о них стоит до перехода к принудительной политике.

• Списки рассылки, изменяющие письма. Список, добавляющий префикс к теме или подпись внизу, ломает DKIM, а IP сервера списка не проходит SPF для вашего домена. Большинство современных программ для списков рассылки обходят DMARC, переписывая From: на собственный адрес списка для авторов с доменов с p=reject, а ARC (Authenticated Received Chain) позволяет спискам передавать исходный вердикт получателям, которые им доверяют. Старые списки могут по-прежнему возвращать сообщения ваших сотрудников.
• Пересылка, изменяющая письма. Простая пересылка обычно выживает благодаря DKIM. Пересылка через шлюз безопасности, переписывающий ссылки, - нет.
• Устройства и скрипты, отправляющие почту напрямую. Офисный сканер, отправляющий PDF по почте, NAS, присылающий оповещения, cron-задача на забытом сервере, рассылающая отчёт, - каждый из них отправляет почту от имени вашего домена прямо получателю, без подписи. Обычно они пишут на внутренние адреса, поэтому могут вообще не появиться в отчётах от Google или Microsoft и ломаются тихо. Направьте каждое из них на порт отправки собственного почтового сервера с отдельной учётной записью, чтобы их почта подписывалась так же, как у всех.

Ни один из них не повод навсегда остаться на p=none. Это повод продолжать читать отчёты после включения политики и знать, что сказать коллеге, чьё сообщение в старый список рассылки вернулось.

Зачем это всё: требования получателей#

С февраля 2024 года Google и Yahoo требуют от всех, кто отправляет их пользователям больше примерно 5000 писем в день, публиковать DMARC-запись (как минимум p=none), а SPF и DKIM должны проходить и выравниваться. В 2025 году Microsoft объявила похожие требования для массовых отправителей на адреса Outlook.com. К небольшим отправителям требования мягче, но домен совсем без DMARC всё чаще считается подозрительным. А домен на p=reject гораздо менее привлекателен для подделки, потому что поддельную почту отклоняет каждый крупный получатель. Статья почему письма попадают в спам ставит DMARC в контекст всего остального, что проверяют получатели.

DMARC на RE:NODE Mail Server#

На тарифе Mail Server Stalwart подписывает вашу исходящую почту DKIM-ключами, которые его веб-админка генерирует для каждого домена, так что выровненный DKIM с вашего собственного сервера у вас есть с первого дня. Саму DMARC-запись публикуете вы, вместе с MX, SPF и DKIM, там, где размещён ваш DNS, - редактора зон на нашей стороне нет. Ящик на том же сервере - естественный адресат rua для отчётов. Остальная работа - найти и исправить другие сервисы, отправляющие почту от имени вашего домена, - одинакова, где бы ни жила ваша почта. О стороне подписи - в статье DKIM-ключи и их ротация.

FAQ#

Сколько оставаться на p=none?

Как минимум две недели, лучше четыре, и достаточно долго, чтобы захватить любые ежемесячные отправки вроде счетов или выписок. Двигайтесь дальше, когда каждый легитимный отправитель в отчётах выровнен, а не когда так говорит календарь.

Почему мне не приходят отчёты DMARC?

Проверьте синтаксис rua (mailto: обязателен), проверьте, что запись находится на _dmarc.example.com, а если адрес в другом домене - что этот домен публикует запись-разрешение. Кроме того, отчёты начинают приходить через день-два, а домен, отправляющий мало почты, может получать их немного.

Почему мне никогда не приходят отчёты о сбоях ruf?

Большинство крупных получателей их не отправляет, потому что в них может быть содержимое писем и персональные данные. На деле вы будете получать агрегированные отчёты, и их достаточно.

Quarantine безопаснее, чем reject?

Он мягче к ошибкам, поскольку непрошедшая почта уходит в спам, а не возвращается. Но неправильно настроенного отправителя при quarantine труднее заметить, потому что никто не получает возврата. Считайте quarantine этапом, а не пунктом назначения.

Нужен ли DMARC на доменах, которые никогда не отправляют почту?

Да, и сразу с p=reject, вместе с v=spf1 -all и нулевым MX. Ломать там нечего, а припаркованные домены - любимая мишень подделок.