DMARC для госдоменов: поэтапно включаем SPF, DKIM и отчеты

Задача простыми словами: как защитить госдомен от подмены

«Письма от нашего имени» - это не только сообщения, которые реально отправляет ваша почтовая система. Это любые письма, где в поле From стоит адрес вашего домена (например, @gov.kz), даже если их отправили мошенники со своих серверов. Получателю это выглядит правдоподобно: знакомый домен, «официальный» стиль, иногда даже подпись руководителя.

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

Защита строится на трех механизмах:

• SPF показывает, какие серверы имеют право отправлять почту от домена.
• DKIM добавляет криптографическую подпись, чтобы письмо нельзя было незаметно подменить.
• DMARC связывает проверки вместе и задает правила для получателей, что делать с «подозрительными» письмами.

Важно идти поэтапно. У госоргана почти всегда есть «скрытые» отправители: портал обращений, кадровая система, сервис рассылок, подрядчик, МФУ/сканеры, медицинская или образовательная платформа. Если сразу включить строгую политику, часть легитимных писем начнет отклоняться, и вы узнаете об этом от пользователей.

Успех измеряется простыми результатами: вы знаете все источники отправки, легитимная почта стабильно доходит, подделки помечаются или блокируются, а отчеты показывают новые источники и аномалии без сюрпризов постфактум. Идеальная цель - чтобы «от имени домена» могли отправлять только подтвержденные источники, а все остальное автоматически отсекалось.

Коротко про SPF, DKIM и DMARC без лишней теории

Держите в голове простую картину: SPF говорит, с каких серверов можно отправлять письма, DKIM доказывает, что письмо не подменили по пути, а DMARC задает правила для писем, которые не проходят проверки.

SPF проверяет IP-адрес отправляющего сервера и сравнивает его со списком, который вы публикуете в DNS. Но SPF не защищает видимое пользователю поле From и часто ломается на пересылках и некоторых рассылочных сервисах, где письмо выходит не напрямую от вашего сервера.

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

DMARC полезен тем, что связывает SPF и DKIM в единое правило и вводит понятие alignment (согласование доменов). Проверяется не только факт прохождения SPF/DKIM, но и то, совпадает ли домен проверки с доменом в видимом From. Это снижает шанс подмены отправителя.

У DMARC есть три режима политики: none (только наблюдаем), quarantine (подозрительное в спам), reject (жестко блокируем). Обычно начинают с none, чтобы собрать картину и не сломать легитимные отправки.

На уровне DNS обычно нужны:

• SPF: TXT запись в корне домена (или поддомене отправки).
• DKIM: TXT записи для селекторов вида selector._domainkey.
• DMARC: TXT запись _dmarc с политикой и адресами отчетов.

На практике участвуют минимум три роли: администратор почты (настройки отправителей и DKIM), владелец DNS-зоны (публикация записей) и ИБ (политики, контроль рисков и разбор отчетов).

Подготовка: инвентаризация «кто вообще шлет» от имени домена

Прежде чем включать SPF, DKIM и DMARC, нужно понять простую вещь: сколько разных систем реально отправляют письма с адресами вашего домена и кто за них отвечает. Без этого вы быстро упретесь в жалобы «письма перестали уходить» и начнете чинить все вслепую.

Соберите список легитимных источников отправки. В госорганах он почти всегда шире, чем «наш почтовый сервер»: письма могут уходить из разных подразделений, через подрядчиков и через старые устройства, о которых никто не вспоминает до первого сбоя.

Чаще всего в список попадают корпоративная почта и шлюзы, сервисы рассылок и уведомлений (сайты, порталы, колл-центр, СЭД), МФУ/сканеры с функцией «скан на почту», внешние подрядчики, а также тестовые среды и отдельные подсистемы, если они шлют наружу.

Дальше каждому источнику нужен «паспорт»: владелец (подразделение), технический контакт, кто может менять настройки и как быстро реагируют. При ужесточении DMARC вы будете просить правки не только у почтовиков, но и у владельцев бизнес-систем.

Отдельно разберитесь с управлением DNS. Запишите, у кого есть доступ, кто утверждает изменения и через какой процесс проходят правки. Согласуйте окна изменений (ночь, выходные, регламент) и заранее подготовьте план отката: что возвращаем, если внезапно перестают уходить письма из критичного сервиса.

Заведите отдельный ящик для агрегированных отчетов DMARC (RUA). Лучше, чтобы он не был личным и имел понятного владельца: отчеты будут приходить регулярно, и их нужно разбирать.

Шаг 1: настраиваем SPF аккуратно и без сюрпризов

SPF - это список отправителей, которым вы разрешаете слать письма от имени домена. Если SPF собран наугад, дальше отчеты и ужесточение политики будут давать ложные тревоги.

Сначала выберите модель. Если весь исходящий трафик контролируется одной почтовой платформой, часто хватает одной SPF записи на основном домене. Если письма уходят из разных систем (кадровые уведомления, сервис-деск, рассылки, порталы), проще разделить потоки: вынести часть отправки на отдельные поддомены и настраивать SPF там. Так меньше риск случайно сломать критичные письма.

Дальше соберите полный список разрешенных источников: ваши почтовые серверы, шлюзы, облачная почта, а также подрядчики, которые шлют от вашего имени. Обычно это комбинация IP-адресов (ip4/ip6) и include от сервисов.

Проверьте лимит SPF по DNS-запросам. Это частая причина сбоев: получатель делает проверки, упирается в лимит (10 запросов) и считает SPF недействительным. Если у вас много include, сокращайте цепочки или разделяйте отправку по поддоменам.

Вводите запись поэтапно: начните с ~all (мягкий режим), чтобы увидеть источники, которые не попали в список. После исправлений переходите на -all (строгий режим).

И ведите простую документацию: что добавили, кто владелец источника, для каких писем нужно и кто согласовал. Если подрядчик сменит платформу рассылок, эти заметки сильно экономят время.

Шаг 2: включаем DKIM и организуем управление ключами

DKIM добавляет к каждому исходящему письму криптографическую подпись. Получатель проверяет ее по публичному ключу в DNS и понимает: письмо действительно прошло через ваш домен и не было заметно изменено по пути. Без DKIM сложнее безопасно перейти к строгой политике.

Где ставить подпись

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

Обычно подпись включают на почтовом сервере, на почтовом шлюзе (как последний узел перед интернетом), у облачного провайдера почты, у сервиса рассылок или у прикладной системы, которая шлет письма напрямую (если иначе нельзя).

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

Выберите длину ключа (обычно 2048 бит) и заведите понятные селекторы (например, по году или по системе). Приватный ключ храните только там, где подписывают письма. Ограничьте доступ, назначьте ответственных и настройте контроль изменений.

Ротация и контроль

Ротация должна быть плановой, а не аварийной. Практичный минимум:

• назначить владельца ключей и резервного исполнителя;
• менять ключи по расписанию (например, раз в 6-12 месяцев);
• сначала публиковать новый ключ в DNS, потом переключать селектор подписи;
• держать старый ключ еще некоторое время, пока письма «догоняют» получателей.

Проверьте, не ломает ли подпись промежуточная обработка: добавление дисклеймеров, антивирусные шлюзы, пересылки через системы документооборота. Обычно помогает подпись ближе к последнему узлу и настройка каноникализации relaxed/relaxed. После включения отправьте тестовые письма из разных систем и убедитесь, что у получателей DKIM = pass.

Шаг 3: запускаем DMARC в режиме мониторинга и начинаем собирать данные

Когда SPF и DKIM уже настроены хотя бы для основных отправителей, можно включать DMARC так, чтобы ничего не сломать. Цель одна: увидеть реальную картину, кто и откуда отправляет письма от имени вашего домена, и какие потоки не проходят проверки.

Начните с политики наблюдения: p=none. Это означает, что письма не будут блокироваться из-за DMARC, но вы начнете получать отчеты.

Пример базовой записи DMARC (адаптируйте под свой домен и почтовый ящик для отчетов):

_dmarc.example.gov.kz TXT "v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=s; aspf=s; pct=100"

В этой записи практический смысл имеют:

• rua: адрес для агрегированных отчетов DMARC (RUA), их достаточно для старта;
• ruf: адрес для форензик-отчетов, если политика и правила вашей организации позволяют получать такие данные;
• adkim и aspf: режим выравнивания (alignment). Часто для госдомена разумно начинать со строгого, чтобы быстрее выявить «левые» потоки.

Агрегированные отчеты (RUA) приходят обычно раз в сутки в виде архивов XML. Сразу решите, где это хранится и кто имеет доступ. Практичный вариант: отдельный почтовый ящик для отчетов, автоматическая выгрузка в защищенное хранилище и простой инструмент разбора, чтобы фильтровать по источнику (IP/провайдеру), по сервису и по результатам SPF/DKIM.

Режим наблюдения обычно держат 2-4 недели. За это время всплывают нерегулярные рассылки: кадровые уведомления, старые принтеры, сервисы записи, «временные» подрядчики.

На этом этапе «не прошедшие» письма не нужно наказывать. Важно классифицировать причины: неверный SPF, нет DKIM, DKIM есть, но не выравнивается домен, или отправитель вообще не ваш.

Отдельно подумайте про поддомены. Если есть адреса вида service.department.gov.kz, задайте sp (политику для поддоменов) или оставьте ее такой же, как p, чтобы позже не получить неожиданные блокировки. В крупных организациях часто удобнее сначала поставить sp=none, а для критичных поддоменов сделать отдельные правила.

Если внутри нет команды, которая может разбирать отчеты и доводить отправителей до стандарта, системный интегратор обычно помогает выстроить процесс. Например, GSE.kz может закрыть организационную часть: от настройки сбора RUA до регулярного разбора источников и согласования изменений с подразделениями.

Разбор отчетов DMARC: как понять «кто шлет от нашего имени»

Агрегированные отчеты DMARC (RUA) приходят как сводка: кто отправлял письма с вашим доменом в поле From, с каких IP, и прошли ли проверки SPF и DKIM, включая alignment (совпадение домена в подписи/конверте с доменом в From). Это главный источник правды: он показывает реальную картину, а не то, что «должно быть» по регламентам.

Что в отчете самое полезное

Внутри отчета много служебных полей, но для работы обычно хватает нескольких:

• источник отправки: IP-адрес и иногда имя провайдера;
• объем: сколько писем пришло с этого источника;
• результат: pass/fail по SPF и DKIM;
• alignment: прошел ли DMARC именно как политика домена From;
• диапазон времени: за какие сутки собрана статистика.

Начинайте с объема: 1-2 источника часто дают 80% всего трафика. Затем смотрите тип нарушения: только SPF, только DKIM или провал alignment. Например, SPF может падать у легитимной системы из-за пересылки, а DKIM - из-за модификации тела письма.

Чтобы отличить реальную рассылку от подмены, ищите признаки: внезапные новые IP, маленькие «хвосты» по 1-5 писем в день, провайдеры, которые не совпадают с вашими подрядчиками, и сочетания типа «From ваш, но ни SPF, ни DKIM не проходят».

Полезно вести реестр источников и обновлять его по мере разбора отчетов:

• источник (IP или сервис) и назначение (какие письма шлет);
• владелец: подразделение или подрядчик;
• статус: подтвержден, на проверке, запрещен;
• что исправить: добавить в SPF, включить DKIM, поправить From;
• дедлайн и ответственный.

Криминалистические отчеты (RUF) подключайте точечно и на короткое время: они могут содержать фрагменты писем и часто ограничены политиками приватности у получателей. Для рутины обычно хватает RUA.

Пример сценария для госоргана: от хаоса к контролю

Представим домен министерства example.gov.kz. Письма от имени домена отправляют несколько легитимных источников: корпоративная почта, портал обращений граждан, подрядчик для массовых рассылок, а еще несколько МФУ и сканеров, которые шлют «сканы на почту».

В первые дни после включения DMARC в режиме мониторинга (p=none) почти всегда всплывает лишнее: старый сервис, тестовый сервер в подразделении, рассылка от подрядчика с чужими настройками или устройство, которое отправляет напрямую по SMTP без авторизации.

Что видно по отчетам в первые дни

Отчет показывает, кто именно шлет, с каких IP, проходит ли SPF и DKIM, и есть ли alignment (совпадение домена в From с доменом SPF и/или DKIM).

Типовая картина: корпоративная почта дает pass и alignment, портал обращений дает pass по SPF, но не подписывает DKIM, подрядчик подписывает DKIM, но домен в подписи не совпадает, а МФУ не проходят ничего.

Как принимать решения без остановки работы

Дальше каждую «ветку» приводят в порядок понятными действиями:

• Исправить настройки у источника: добавить нужный сервис в SPF, включить DKIM, настроить правильный домен подписи.
• Перевести отправку на поддомен (например, notice.example.gov.kz) и отдельно настроить для него SPF, DKIM и DMARC.
• Запретить источник, если он не нужен или неуправляем (особенно устройства и «самописные» отправители).
• Попросить подрядчика отправлять через утвержденный шлюз или подписывать письма вашим доменом.

Чтобы согласование не превратилось в бесконечную переписку, заранее закрепите владельцев: ИТ отвечает за DNS и почту, профильное подразделение - за портал и процессы, закупки или контракт-менеджер - за подрядчиков. Изменения вводят по очереди, с окном наблюдения 2-3 дня после каждого шага.

Прогресс измеряют цифрами из отчетов: растет доля pass по SPF и DKIM, и отдельно растет доля alignment. Когда «шум» ушел, можно переходить от none к quarantine и затем к reject.

Переход к строгой политике: quarantine и reject без потерь

Строгая политика DMARC нужна не ради галочки. Она снижает риск фишинга и подмены отправителя, но вводить ее стоит только после того, как вы понимаете, какие источники почты действительно легитимные. Для госорганов это критично: терять письма с уведомлениями гражданам или межведомственную переписку нельзя.

Как переходить на quarantine и выбирать pct

После периода p=none у вас уже есть отчеты и список реальных отправителей. Дальше безопаснее идти через p=quarantine с процентом.

Часто начинают с pct=10-25 и повышают раз в 1-2 недели, если нет инцидентов. Поднимайте pct после правок: добавили недостающий SPF, включили DKIM у сервиса, поправили выравнивание домена.

Проверяйте не только общий процент. Смотрите, какие именно системы попадают под карантин: МФУ, старые уведомлялки, подрядчики, региональные подразделения.

Когда можно включать reject

Переход на p=reject оправдан, когда «серых зон» почти не осталось. Контрольные точки простые:

• В отчетах нет новых неизвестных отправителей минимум 2-4 недели.
• Все важные сервисы проходят DMARC стабильно (SPF или DKIM с выравниванием).
• Есть понятный процесс: кто принимает заявки на добавление нового отправителя и кто вносит изменения.
• Настроены отдельные правила для поддоменов: рассылки, тесты, подрядчики.

Отдельно про пересылку и списки рассылки: там часто ломается SPF, а DKIM может быть переподписан. На практике помогают три подхода: опираться на DKIM у исходного отправителя, не ломать подписи на шлюзах, а для списков рассылки использовать отдельный домен/поддомен отправки с более гибкой политикой.

Чтобы политика не «сыпалась» через полгода, зафиксируйте регламент: роли (владелец домена, ИБ, почта, подрядчики), сроки реакции на новые источники и пересмотр настроек раз в квартал.

Частые ошибки и ловушки при внедрении SPF, DKIM и DMARC

Даже при включенных SPF, DKIM и DMARC почта может продолжать уходить в спам или блокироваться. Чаще всего причина не в «плохой записи», а в несостыковках между потоками отправки, доменами и тем, как письма меняются по дороге.

Типовые проблемы:

• SPF разрастается и упирается в лимит DNS-запросов (10 проверок). В итоге часть писем получает SPF permerror, и DMARC тоже ломается. Помогает сокращение include, уборка лишних источников и разделение по поддоменам.
• DKIM подписывает не все исходящие потоки: основная почта подписана, а уведомления из портала или другой системы уходят без подписи или с подписью другого домена.
• DKIM подпись «ломается» по пути: шлюз добавляет баннер, меняет переносы строк или переупаковывает MIME. Ищите место изменения письма и подписывайте ближе к последнему узлу перед интернетом.
• DMARC включен, но нет alignment: в From стоит ваш домен, а Return-Path (MAIL FROM) чужой, и SPF не выравнивается. Или DKIM подписывает d=поддомен, а вы ждете совпадения с основным доменом.
• Забытые сторонние сервисы: билетные системы, подрядчики, рассылки, сканеры, МФУ, веб-формы. Они шлют «от имени» домена, но технически не готовы к вашей политике.

Отдельная ловушка - включить reject слишком резко. Без периода наблюдения легко отрезать важные уведомления и узнать об этом через несколько дней.

Рабочая практика простая: начните с мониторинга, соберите данные, назначьте владельцев систем и держите план отката (например, временно снизить pct или вернуть p=none). Если нет единого владельца почтовых потоков, полезно подключить интегратора, который поможет собрать карту отправителей и довести настройки до единого стандарта.

Короткий чеклист и следующие шаги

SPF, DKIM и DMARC перестают быть «страшной почтовой темой», когда превращаются в понятный процесс контроля.

Проверьте базовую готовность:

• Источники отправки перечислены и подтверждены (почтовые серверы, сервис-деск, рассылки, кадровые системы, подрядчики). За каждый источник назначен ответственный.
• SPF настроен аккуратно: нет лишних записей, все нужные включены, лимиты DNS-запросов не превышены, и есть понятный порядок изменений при появлении нового сервиса.
• DKIM включен везде, где это возможно: подпись стабильно проходит, ключи под контролем, есть план ротации (например, раз в 6-12 месяцев) и процедура на случай компрометации.
• Отчеты DMARC собираются и разбираются: есть регулярный просмотр, реестр источников и отметки, что уже исправлено, а что в работе.
• Переход к quarantine/reject согласован: определены критерии готовности и окна изменений, чтобы не сорвать рассылки, уведомления и межведомственную переписку.

Критерии готовности к ужесточению тоже понятны: в отчетах видно, что почти весь легитимный поток проходит SPF и/или DKIM с выравниванием доменов, а неизвестные источники отключены или приведены к корректной подписи. После этого обычно идут по схеме: p=none -> p=quarantine (с небольшой долей) -> увеличение pct -> p=reject.

Дальше важно назначить владельца процесса (часто почта/ИБ) и закрепить регламент: кто добавляет новый сервис, кто проверяет отчеты, кто принимает риск. Если не хватает рук или опыта, можно привлечь системного интегратора. Например, GSE.kz (gse.kz) работает как производитель и интегратор в Казахстане и может помочь выстроить почтовую и инфраструктурную часть, включая организацию разборов DMARC-отчетов и поддержку эксплуатации.